A colleague asked me which Prettier configuration to use so I told him to use the one from that we have used elsewhere and invented the following principle right on the spot:

The Principle of Minimization of Small Differences

(with a hat tip to Narcissism of Small Differences)

What programmer has not been through the discussions on use of parenthesis, brackets, tabs vs spaces, camelCase vs PascalCase, file naming vs type naming, and so on and on and on. Over time we got somewhat wiser so we started introducing formatters with the languages themselves or using opinionated formatters like Prettier. But Prettier is not opinionated enough - it can be configured - and so we are back at square one and somebody has to set up the standard way to format the code on the project. But then you create another project and for a little bit you go through “should we do things a bit differently this time?” (the default answer in the wild is “YES OF COURSE!” whereas it should be “happy to talk about it but hell no is the default”)

I believe that we generally underestimate how much time it’s lost in the friction generated by the small differences of different code formatting and other things. “You can pick up library Y in one hour!” in order to replace some library X. Well, if that is really true then I wonder how much value it brings. If it’s so shallow, let’s go and migrate the library X to Y in all the components that are in active maintenance. If not, we will end up with two different ways of doing the same thing in different places which increases the cognitive load on a team that is (usually) fixed in size. If it is so then you are just increasing complexity to the fixed IQ of all team mates (though growth in experience does offset some of that)

I once worked on a project where somebody, prior to my engagement, decided to ignore the complete and significant API protocol that already existed and introduced another protocol, in the monolith mind you, without any plans for migration. It was “easier”. Talk about local optimization going against global optimization. Team kept talking and wringing hands about it for years afterwards but there was no good solution short of throwing it away and there was never time to throw it away. I’m not saying there aren’t times when you may reasonably decide to locally optimize and globally de-optimize (aka accumulate technical debt) but to do so on the interface of the system and with such levity, that requires massive amounts of shortsightedness.

While on the subject of technical debt, the accumulation of it is a natural product of working within an envelope of business needs. Especially in startups, where planning horizon is limited by both market opportunity and financial constraints, it is often necessary to accumulate technical debt for the survival of the project and even business. You have to adapt your design to the team and time and opportunity you have - this seems very obvious to me. And so all I ever try to do re the accumulation of technical debt is to do it with our eyes open and avoiding obvious unenforced errors. After that, there is a lot of judgment involved where tech debt is acceptable (e.g. works slower/more expensive than optimal) and where it is not (e.g. our data is getting corrupted).

Another time I was leading the development of a new, very complex feature in an already “mature” system (the system itself was mature in the worst way: arthritic rather than strong, but that’s a tale for another day). I was leading a small team that was going to be working with the main team, as an internal customer, and directly contributing to the source tree of the system. My one ask was the coding standard so that my team could follow it and so that our code would look exactly like the rest of the code. What I could see of the “dominant standard” was not to my personal liking but what I cared was seamless code for everybody, all the teams, and not if it was close or not to my esthetic sensibilities. The lead of the main team thanked me for being “gracious” but failed to provide an actual standard and just let everybody do their own thing. But I wasn’t being gracious at all - all I was trying to minimize small differences that unnecessarily slow down writing, reviews and later reading of the code. In retrospect, the use of “gracious” really betrayed him: he had the best of intentions but was far, far too lax with engineers. But I say never leave engineering to engineers

Last modified on 2025-03-04