Despotic development
Despotic development
Why do so many devs have trust issues?
One of the more common experiences I’ve had over the past decades working in programming and web development has been frustration at other devs who seem to go out of their way to restrict my freedom to code as I see fit. And often in the most patronizing and arrogant manner possible.
I certainly have strong opinions about the best way to write code, and I have no qualms about sharing those opinions frankly and openly. But I never act to block others from doing what they wish to do with their own code.
Sadly, that distinction is virtually unknown in the industry. And a remarkably large number of developers appear to take great glee in exercising—or attempting to exercise—arbitrary and dictatorial control over what other devs can do.
Enough rope to hang themselves
I first encountered this attitude and behavior decades ago in an online discussion about certain language features. Many devs complained that these features did not prevent devs from doing stupid shit. They operative phrase was, “we’re giving them just enough rope to hang themselves”.
And the complaint was: we shouldn’t. We should act as nannies to our users, and restrict their options for their own good. It simply shouldn’t be possible to do stupid things with our programming language, library, framework, what-have-you.
We are the adults in the room, naturally, and our users are infants incapable of making adult decisions.
Of course, we’re not talking about preventing programmers from building new weapons of mass destruction, or creating instruments of torture, or helping to undermine liberty and privacy by perfecting the global surveillance state.
Aw, hell no! All of those are perfectly fine, and who are we to interfere?
No, it’s never about what we code, but about how we code. Funny that.
Boots stamping on faces… forever
Recently, I wrote an essay about the totalitarian nature of many devs when it comes to such things as code formatting—something that should always be left up to the coder. Let’s just say I find this condescending crap despicable.
But it goes way beyond Deno folks deciding to try to control how I use semicolons in my personal code: the very structure of many programming concepts assumes that programmers can’t be trusted.
Consider, for example, encapsulation or information hiding. What the hell is that about? You may say, well, we need to hide that stuff so developers won’t use it. But if devs shouldn’t use it, why would they? There is no escaping that those doing the hiding think that devs can’t be trusted and that it’s on them to restrict developer choice.
We can always come up with examples where this doesn’t really matter much, but that’s missing the point. It’s not about individual instances, it is about the underlying ideology: the ideology that makes some people “parents” and others “children” who have to be disciplined “for their own good”.
Over-parenting creates infantilism
The problem with this—and we see this in all walks of life, not just programming—is that when you make decisions for others “for their own good”, you remove their agency. And when you remove agency, you remove the ability to make mistakes, and, more importantly, to learn from them.
In short, when you refuse to trust people, they never learn to be trustworthy. When you treat people as infants, they remain infants.
To grow, learn, and mature, we all need to be free to explore, to make mistakes, and learn from them.
Oh, but it gets worse
It is not just maturity that suffers when we rob people of agency. If we do too much for our children, they never learn to do for themselves. The same is true for programming.
I wrote my first website in Notepad. There were HTML files, CSS stylesheets, and JavaScript scripts. It was simple. A text editor. No syntax highlighting. No code completion. Not even spell check.
There was no linter to test my code and point out the errors. No debugger. Chrome didn’t exist and neither did Firefox. It was Netscape 3 and IE 3. There were no formatters to clean up my mess.
So I learned to code carefully. I paid strict attention to style, indentation, etc. I read my code line by line—often from back to front—looking for mistakes.
Syntax highlighting, which I discovered around 1998, was an eye-opener. I would never want to go back, but that’s because it makes reading the code easier, which makes spotting the mistakes easier. It doesn’t “fix” anything. It reduces cognitive load.
I do use a linter, but I correct my own mistakes. That way I learn. And I do use a formatter (Dprint), but I’m so used to typing my code carefully, that when I save the file (format-on-save enabled), rarely does anything change.
Personally, I’d rather the formatter just marked poorly formatted code and made me change it manually. That way I develop good habits.
So our insistence on making things easier for ourselves weakens us. I was reading recently how many young people no longer understand taxonomies and categorization because everything now is just tags and searching. Maybe it’s just me, but I think it is important to know both.
Creeping totalitarianism
If you’re a programmer or developer, then coding is not just something you do for a living and sometimes for fun. It is an activity in which you spend the majority of your waking hours.
The things we do change us.
I’ve spent a lot of time learning new things, and I’ve developed over the decades a methodology for learning (and another for teaching). One of the methods I advocate for learning I call Practice Makes Permanent.
The point is that learning any skill is all about practice and muscle memory. But your brain can’t tell when you’re practicing and when you’re just messing around. So, essentially, everything becomes practice.
If I’m teaching coding, I explain this thus: Every time you write a line of code, you are teaching yourself how to write code. If you write shitty, poorly formatted code, then you are practicing writing bad code. You may think that you can suck it up when it counts and write good code, but no, no you can’t.
This advice—write every line of code as if it counts, because it does—applies to everything, not just coding. If you build crap products all day, don’t kid yourself that you can build something great if you need to. You won’t have developed the skill.
Syntax highlighting, formatting, code completion, linting, etc. can help us to teach ourselves to be better programmers, or these applications can do the work for us. Who, then, is the programmer? Us? Or the machine?
We live in a world filled with infants. Look around. And our solution appears to be more rules and more enforcement instead of more trust and more understanding and leading by example.
Coding is a microcosm of that world, and the same totalitarian tendencies we see everywhere these days are equally evident in the programming world. Pretty ironic, given how many programmers see themselves as rugged individualists, winners in a meritocracy, and libertarians.