There’s been a recent kerfuffle online about tools, web developers, and who gets to call themselves a “developer” again. I’ve written about this sort of thing before. The players are a bit different this time around, but again, the argument is the same: “you don’t understand the same things I do, so you’re inferior and shouldn’t be called a developer.” Or so the claim goes.
This is frustrating. It’s divisive, it’s cold, and it’s unwelcoming. When the Web is built on common knowledge and camaraderie, it’s hard to watch newcomers being derided and chided for doing things differently or not learning things “the right way”. Spoiler alert: there is no “right way” to learn something. There may be “better” ways to learn something, “better” being subjectively defined. But there seems to be a frequent tendency among developers to see these things in such stark, binary ways.
Yea, But Does It Work?
When it comes to software quality, we’re talking about a spectrum, not a boolean state. The only truly poor program is one that doesn’t function properly. If the code runs, then by the most starkest of pragmatic definitions, it’s a success. It may have been “written” by a person copying and pasting something off StackOverflow. It might be poorly structured and unnecessarily reliant on some framework. But it works.
Now, Does it Work Well?
Part of the problem is that for many developers (and often beginners in particular), they stop at “it works”. Why? Usually because of time. It took them way longer than they thought just to get the code to work. They need to move on. We who truly love development, we take the next step and dig into why it works. Could we make it work better, simpler, more elegantly?
But not everyone has that mindset. Many developers today didn’t grow up writing code, they didn’t dream of being a developer. They’re just doing this as a job, not as a lifestyle.* If all their boss cares about is whether the code works, then that’s all they’re going to care about too.
And yet we hear from long time developers, leaders in the field: “If you can’t do this the right way, my way, you shouldn’t be doing this at all.” That’s not healthy, and it’s not persuasive. Instead, we should be trying to say “Great, glad to see your code works. Did you know it could be better? Here’s how and more importantly, why…”
The Framework That Broke the Camel’s back
See, here’s the real reason I decided to sit down and write out this diatribe. I agree with the argument that lit this particular flame war: I do think there’s too many tools out there. It feels like what everyone wants to do is keep redesigning the hammer instead of building houses.
But if you just go around telling all these people who are super excited about the hammer they just designed to shut up and go back to building houses…well, that’s just going to make them upset. Or worse, you’re now yelling at people who don’t really know how to build houses yet but they saw this cool new hammer and that got them excited about the possibilities, so they’re here to try some stuff out…and here you are telling them they’re illegitimate because they don’t know how to build a house.
They’re not going to listen to you. None of them are. And you’re still going to wish there were more people making houses.
Nothing is solved. Things don’t move forward. Everyone just gets further cemented where they are.
…but maybe that’s how all debates go these days.
*: If you have a problem with that, then we need to have a completely different conversation about how industries grow and change. You probably won’t like it.