The Dogmatic Developer

Recently I've been reading Robert C. Martin's seminal 2008 book Clean Code. Outdated references and semi-frequent moments of cringe aside (I'd be genuinely surprised if any of the editors of this book were born after the 1960s), one thing that stood out was the overly-dogmatic way that solutions are presented. Even the most seemingly inconsequential things quickly turn into vehement debates—many of which culminate in the insistence that failure to follow the practices presented directly reflects on the competency of a developer.

This doesn't mean the arguments presented are inherently wrong; the book still sets up a framework of great practices for newer developers (and I'm not here to debate its value as a teaching device). Clean Code has a reputation that precedes itself and few, if any, books are rewarded for their inaccuracy. What it does do, however, is set a dangerous precedent that there's no room to stray from the path—"best practices" are absolutes, and anyone who refuses to follow along is writing bad code. Robert Martin delivers his arguments as if he lives in the hilliest region on Earth, and he's prepared to die on every single one of them.

That's not to say these sorts of ideologies are necessarily a detriment to software development as a whole. Dogmas in development usually exist for a reason; to ascribe the fervency of software ideologues as a symptom of the paradigmatic nature of the industry would be disingenuous at best. The problem is not with the practices themselves, but an unwillingness and reluctance by the engineers employing them to look at them as anything except de jure standards. Make no mistake, this isn't an argument against the fundamental principles of software development (otherwise I'd have taken the opportunity to use the clickbait title "It's Time To Drop DRY").

So what? There are clearly worse outcomes than everyone following an objectively good set of best practices. Where this dogmatism truly becomes dangerous is when close-mindedness begins to shut down legitimate criticism. I worked at a company with an engineer so caught up in his own method of doing things that other engineers were warned not to dispute him on code reviews. He had been with the company for twelve years, his tenure eclipsing nearly everyone in the department by more than a few trips around the sun. Try to contextualize just how long twelve years is; for most of us that was the entire length of time we spent across both primary & secondary school.

Because of his tenure, this developer was left mostly unchecked as he spiraled our codebase into a wasteland of over-engineered entropy. Instead of accepting criticism for his work, he instead opted to hide it behind inaccessible abstractions. He had a habit of developing his code in isolation and installing it in the main codebase as modules through our internal package registry, making it:

Impossible to review the code
Impossible to maintain the code
Incredibly frustrating to debug the code

His behaviour was emblematic of a larger issue: the frameworks for discussion we've created around software patterns, languages, and toolings. At the least harmful end of the spectrum, it's an impassioned conversation thread on a StackOverflow post. At the extreme, it's an ideological hegemony silencing actual genuine criticisms. In this developer's case, he avoided feedback entirely by refusing to engage in constructive conversation with his peers. This can happen for several reasons, but more often than not I've found this kind of behaviour to be driven almost entirely by ego.

This is something I have been guilty of participating in. I started using React in 2015, and for the first couple of years, I dismissed other UI libraries as being inferior without taking the time to understand the challenges they were trying to solve. I was good at React, and if that was suddenly taken away from me I felt like I would have less value as a developer. In order to protect my ego, I would defend the library zealously, despite knowing these were solutions being created to address real and honest shortcomings. The thing is, familiarity is an entirely valid reason to choose a solution (but just as it's important to understand the tool, it is equally as important to understand its limitations).

So what can we do to help curb the issue? The most important thing is to have the willingness to be open and challenged on your opinions. This doesn't mean you need to accept every piece of criticism as a hard requirement to change your thinking—if genuine reflection on feedback brings you to the same decision you started with, all the power to you! There are times when you'll be right, and times when you'll be wrong. Stay pragmatic in your approach; keeping an open mind to different perspectives will make you more well-rounded than if you close yourself off to any criticism whatsoever.

At the end of the day, we're all working towards a shared goal, and it's going to be a lot easier to get there if we treat each other with respect.