Abject Rancor

Writing the most valuable code for your team and customers is a lot less fun than most people think it is. So we find ways to make it more fun. The human brain really likes doing this and hates doing this, so one of the ways we make coding more fun is devising ways to give ourselves an “I’m objectively correct” dopamine hit, or a “I made everything uniform and uniformity pleases lizard brainstem that doesn’t like rough scales that need to be shed” when we check in a change.

However, we don’t like admitting that we just changed the nature of the work we’re doing to make it more fun–we don’t like admitting that to ourselves, or to others. So we retcon several layers of “best practices” and “thou shalt"s onto a set of behaviors that were initially proposed for very good reasons, transforming “in certain cases your code may not be good, so consider trying strategy-X and see if that feels better. If not, try something else."-type guidelines into Absolute Truths handed down from misogynists on high.

And that is how Design Principles are born.

In other words, most people who think they are writing the most valuable code for the team/customers are actually engaging in some amount self-gratification. Doing what is actually needful is much less like a dopamine hit and much more like … well, work. For that work, people receive extremely substantial remuneration, which one would hope would provide dopamine enough.

The goal isn’t zero self-gratifying changes (morale is important, and an appropriate amount of principle-applying and dogma is healthy for a codebase); rather, the goal is to adopt a posture of extreme honesty about why work to apply standards/patterns to code is being done:

• Because the standards/patterns being applied are actually valuable (good);
• Because applying them is gratifying for non-customer-beneficial reasons (bad, do less of this); or
• Because the end state is beneficial to code maintainers, and is falsely attributed to the standards/patterns applied themselves (also bad).

If your reaction to the above is to say “that’s just a fancy way of justifying unmaintainable cowboy coding that will create nightmares for future maintainers, I just know that fully applying SOLID principles will be better/the right way”, consider that you may have made your job too fun–into the metaphorical equivalent of eating nothing but dessert for dinner while saying that it’s healthy.

You’ll know when something is actually unmaintainable. Writing it will cause post-traumatic stress. You’ll remember specific times that bad patterns caused production issues, late nights, heartburn

If you don’t have that feeling, it’s probably just fine to maintain. It’s just not fun, and that’s OK. We’re professionals, not kids in a playground.