"We have to make sure that no one can do it wrong."
This sentence, or variations of it, is something I have heard a lot since I have become a programmer. And it is something I wholeheartedly believed in myself for a long time.
"Doing it wrong", in this case, refers to implementation patterns in a codebase or software system.
At the core lies a belief that if we just "lock something down enough" or "make it foolproof", programmers will be forced to follow the "correct" pattern.
I think of this as the cookie-cutter approach: You give developers a few cookie-cutters, and you always end up with the right solution, right? "Developers won't have to think about doing the right thing" is another one of those phrases often tossed around in those conversations.
Since when do we not want developers to think?!
Please don't misunderstand me. I see great value in having uniform approaches within a code-base or software system.
Uniformity does reduce mental load and increases trust in the system. But in my experience, trying to take it too far will backfire for a few reasons.
Firstly, people will find a way to navigate around the desired pattern. Unfortunately, general-purpose languages are so, well, general-purpose that it is nearly impossible to ultimately dictate a pattern without any possibility of modifying or circumventing it. This is something I have experienced myself many times when onboarding a new team member. They only needed a few days to "break" a pattern, intentionally or unintentionally. So you will still have to explain the pattern, its dos and don'ts, and why it exists in the first place.
Secondly, you will run into situations where there are very legitimate reasons to break a pattern. If your design or language of choice does not allow for that, then you will find yourself either stuck or needing to make ugly workarounds.
It ends up being an endless battle of finding ways to enforce the patterns while trying to keep the enforcement flexible enough to allow for untypical situations to be handled gracefully.
Thirdly, forcing people to apply patterns and making them believe that, if they do, nothing can go wrong will often lead to them switching off their minds. And while I, as already stated, do believe in uniform approaches to reduce mental load, I don't want anyone to switch off their mind while they are programming.
"I like giving people sharp knives and teaching them how to use 'em" - Toby Clemson, fellow programmer
Toby once said the above to me when we were working on a project together, and it has stayed with me since then.
I like thinking of my team members as people I can trust, people I can give sharp knives which they want to wield with care and attention. And if they don't know how to do something, they will want to learn and ask for help. The idea of making sure that they can't do anything wrong now leaves a bad taste of not trusting team members.
And if you don't trust your team members, you have way more significant problems than the correct application of code patterns.
I don't want to work with dulled-out people using cookie cutters. I want to work with sharp people using sharp knives.
Top comments (0)