<section data-section-id='8600c17f-3f9f-4415-966a-bb8737d94562'><p><span style="white-space: pre-wrap;">Nothing gets me riled up more than saying it's always better to help than not.</span></p><p><br></p><p><span style="white-space: pre-wrap;">No, it's not always better to help! There's nuance to this. Sometimes it's better to let everyone feel the pain. Let it fester so we can justify spending the time and resources to properly address the underlying issue.</span></p><p><br></p><p><span style="white-space: pre-wrap;">In any organization, we're limited by what we can justify allocating headcount to in any moment. And it's always easier to justify allocating people to the things that are on fire and hurting outcomes.</span></p><p><br></p></section> <section data-section-id='2ad34192-2f75-43c4-b3d0-a6cbca214e07'><p><span style="white-space: pre-wrap;">The issue is that if we patch everything constantly - meaning we do just the bare minimum we need to surface-level fix the issue - it can obfuscate deeper structural issues. And in my experience, these patches have a bad habit of becoming the long-term solution.</span></p><p><br></p><p><span style="white-space: pre-wrap;">Having too many patches accrue creates a house of cards, where adding one more card to the heap can cause the whole thing to collapse. It can also mean that you're firefighting all the time, which harms outcomes, burns the team out, and prevents long-term building.</span></p><p><br></p><p><span style="white-space: pre-wrap;">Now, when I talk to engineers about engineering things, this makes sense to them, especially to folks who've been on larger teams and can understand that we can't work on everything. They understand there's nuance to deciding when to patch and when not to.</span></p><p><br></p><p><span style="white-space: pre-wrap;">What really gets me riled up is when we apply the same thing to society, particularly government programs, these same engineers just don't get it.</span></p><p><br></p><p><span style="white-space: pre-wrap;">Isn't it better to help, do something, than to not?</span></p><p><br></p><p><span style="white-space: pre-wrap;">No!! It's the same thing, just applied to something else. If we intervene with half-baked ideas (aka a patch), we can end up obfuscating the deeper structural issues and delay (sometimes indefinitely) the proper fixes.</span></p><p><br></p></section> <section data-section-id='3ffda520-4019-4a09-9f97-a4681e365aa4'><p><span style="white-space: pre-wrap;">Don't get me wrong, I totally understand. The proper fixes could take years to come, so why not help now?</span></p><p><br></p><p><span style="white-space: pre-wrap;">And sometimes the answer is yes, we should help now, but the whole point is there's nuance. And my opinion is that unless you're really in it, developing deeper expertise on the problem, understanding when a patch is worth it and when it's not is super tough.</span></p><p><br></p></section> <section data-section-id='246b5f4f-48b9-4bf9-939b-af130d11d71e'><p><u><span style="white-space: pre-wrap;">Further reading</span></u></p><ul><li value="1"><b><strong style="white-space: pre-wrap;">Engineering ethics, from the source:</strong></b><span style="white-space: pre-wrap;"> the ACM/IEEE Software Engineering Code of Ethics puts the public interest first and treats maintenance work with the same care as new builds.</span><web-citation data-url="https://www.acm.org/code-of-ethics/software-engineering-code" data-title="Software Engineering Code of Ethics (ACM/IEEE)"></web-citation></li><li value="2"><b><strong style="white-space: pre-wrap;">The cobra effect:</strong></b><span style="white-space: pre-wrap;"> a classic on how well-meant fixes can backfire and grow the very problem they set out to solve.</span><web-citation data-url="https://scienceinsights.org/what-is-the-cobra-effect-when-incentives-backfire/" data-title="What Is the Cobra Effect? When Incentives Backfire"></web-citation></li><li value="3"><b><strong style="white-space: pre-wrap;">Fixes that fail:</strong></b><span style="white-space: pre-wrap;"> a systems thinking staple on quick fixes that soothe the symptom while the deeper issue keeps building.</span><web-citation data-url="https://thesystemsthinker.com/fixes-that-fail-oiling-the-squeaky-wheel-again-and-again/" data-title="Fixes That Fail: Oiling the Squeaky Wheel (The Systems Thinker)"></web-citation></li><li value="4"><b><strong style="white-space: pre-wrap;">Technical debt, explained well:</strong></b><span style="white-space: pre-wrap;"> how small shortcuts pile up over time, and how good teams pay them down with intention.</span><web-citation data-url="https://review.firstround.com/glossary/technical-debt/" data-title="Technical Debt (First Round Review)"></web-citation></li></ul></section>