Programming Is Awesome, But Programmers Suck

I was re-reading the fantastic piece by Peter Welch called Programming Sucks, which is a classic despite it being only two years old. In the piece, Mr. Welch repeatedly demonstrates why programming (and the atmosphere surrounding it), well, sucks, which results in simultaneously hilarious and sobering paragraphs such as this one:

"You discover that one day [while debugging a program], some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for "Infinity" when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn't, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn't going to tell anyone that this was an error, because he's a dick, and now all your snowflakes are urine and you can't even find the cat."

You'll have to read the whole piece to have that last sentence make sense. Go on, I'll wait.

That post got me thinking: why exactly does programming suck? Most of the piece details that the work itself actually doesn't suck; rather, the people involved in it do. It got me thinking: exactly why can programming be so frustrating, so annoying, so terrible? And I've come up with a theory.

In short: programming doesn't suck, programmers suck. Yes, including me. Here's why:

We think "I can do better than that." Every damn time. It doesn't matter if we've spent five seconds perusing a new codebase or a couple minutes watching a senior developer explain what his application does, we can always do better than that idiot. Until we actually try to do it better, and after a few hours of "this can't be that hard" and "why won't you work, stupid code" and "I know I'm better than this" we're more likely to silently give up than concede that we got Dunning-Krugered once again. Why admit defeat when you can just delete?

But while we will do better than that, nobody else can. Everyone else's applications are steaming piles of dog crap next to our own beautifully-crafted, complete, artful pieces of shit code. And we don't even have enough sense to realize that what we've written is crap, as it always has been and always will be; since it's our crap we assume that it must be good. After all, we're good at programming, therefore what we write must be good. I mean, obviously.

A programmer, sitting on a couch with a computer on his lap, captioned

In our own little insular world, we are gods, and we get treated as such. Have you ever fixed a family member's computer after they did something to it? You'd think they just saw water turned into wine. What was a few minutes of googling and an hour of random button-pressing while trying to get a different error becomes a work of utter genius in the eyes of the non-techie. To them, we are not so much technicians as magicians, and we can't even deny it because "oh, you're just being modest." To the non-programmer, we are miracle-workers. And, if we're being really honest with ourselves, we love it. We crave that praise, that acknowledgement; it's something we don't often get in the real world because code, on the whole, is supposed to be invisible. It's a truly addictive feeling, that of doing something no one else can do.

We believe that management hates us because we "tell it like it is" (which invariably means "how we want it to be"), but in reality they hate us because we don't bother explaining ourselves clearly. We say "there's a problem" and then launch into some long and indecipherable technobabble rant about why the proposed solution won't work, when in reality we're just stalling, saying it won't work because we don't have the time or energy to research and understand the proposed solution.

Worse, if we do bother to attempt to explain why it won't work, we'll probably only do that once, because when we invariably fail to make them understand how smart we are and how dumb they must be, we just won't bother explaining anything to them because it's a waste of time. They didn't understand before, so they won't understand now. It's an endless loop, one we perpetuate because it makes us feel smart, feel needed, when in reality it just pisses off our managers.

In short, we are whiny, selfish, dense little buggers who just want to feel smart.

Programming, to be clear, is awesome. We programmers are fortunate. We get to solve problems using code that only a few people understand, that are difficult to conceptualize, that, if we're lucky, can actually make a difference in someone's day-to-day life. The feeling of doing good work is up there with good sex and good food: it feels amazing. Even better, we get paid to do this, and in many cases paid quite well compared to other professions. Yet we can't seem to remember any of that because we're too busy puffing our chests and destroying code.

Programming doesn't suck, programmers suck. All of us, including me. This is one of the reasons I believe that a core part of being a programmer is being a good communicator. Maybe the time we spend perfecting our code would be better spent explaining it, understanding others' code, or just chilling out. We're not gods, we can't always do better, and most of all we are people just like everyone else. Spend your time learning how to communicate, analyze, and teach; what you'll find is that these are all more important skills than knowing how to code.

Popularity Breeds Haters (or Why You CAN Be A Good .NET Developer)

A most interesting blog post was written a couple of days ago, and while I understand the author's frustration, I do not agree with his conclusion.

The developer in question is Rob Ashton, who wrote a post attempting to figure out why people seem to leave the .NET development world in droves. I can't argue that I haven't seen that occur, because I have, but I think he arrives at entirely the wrong conclusion from reductive logic. He declares that:

"The reason why people "leave" .NET is because it is impossible to be a good .NET developer. To work in a development shop with a team is to continually cater for the lowest common denominator of that team and the vast majority of software shops using .NET have a whole lot of lowest common denominator to choose their bad development decisions for."

Responding to a tweet, he argues that it isn't self-loathing that causes these developers to leave, it is something rather different:

"It isn't self loathing [that causes .NET devs to leave], it's self preservation and an eventual realisation that you can't actually progress so long as you're being held back by bad decisions made to cater for the slow and the stupid."

I kinda see where Rob's coming from. Lots of orgs make bad decisions, and many times the people who leave the company due to these bad decisions make their experiences known and disseminated. Where my agreement with the post stops is at the idea that these poor experiences by some .NET developers represent a reason for other devs to leave that space.

The issue I take with Rob's post is that this is true for any popular thing ever, and .NET is extremely popular.

When you talk about popularity, you inherently assign a threshold at which something is "popular" however that is defined. Once a programming framework (or book, or song, or whatever) meets or exceeds that threshold, you will invariably have people who dislike it (aka "haters"). The more popular a thing becomes, the more haters it has; eventually, you might have a lot of haters, enough that it seems like they're a sizable portion of the total population.


(Let me be clear about something: I am not calling Rob a hater, I've never met the guy, never talked with him, anything. I am simply expressing my opinion of his post. Separate the opinions from the person, dear readers, and let's be civil about this.)

The problem is that the haters tend to be vocal in their dislike of something, whereas the people who enjoy the framework are too busy enjoying it to worry about the haters. After all, generally things get popular for a reason, even if you don't like the reason.

Because the haters are vocal, and are actively expressing their opinions wherever they might be heard, those who have not formed such an opinion yet (or have a slightly-negative opinion of the popular thing) are more likely to hear the haters' criticisms and believe that they represent the majority of the population. In my experience this is almost always wrong.

If you go looking for the bad things, you will inevitably find them. There certainly are organizations our there which run their devs into the ground, don't understand their chosen frameworks' strengths and weaknesses, don't really care if development has the tools they need to do their job well. These sorts of organizations give all the good ones a bad reputation, one which is all too easy to categorize: "well, if Organization A sucks and it uses X framework, then everybody who uses X framework must also suck." What's infuriating about this logic is that this thought process is itself a form of pandering to the lowest common denominator, something which Rob is saying is the reason why .NET devs leave that environment. A uses B, A sucks, so B must suck. It's reductive logic in its purest form.

All that said, I understand the frustration that Rob's post implies, and it doesn't stem just from incompetent .NET-using organizations making poor decisions; even Microsoft is not immune. .NET Core recently made a major change (moving from the fantastic project.json file back to MSBuild) that, frankly, pissed me and a lot of other people off. I build websites, the project.json file makes configuring those sites much easier than it has been in the past, but now you're yanking the rug out from under me by discontinuing it? What the hell, Microsoft? Why promise me Disneyland and take me to McDonald's?

I get why Rob's frustrated; I'm frustrated too. I've worked for my share of poor companies. But to go from "some orgs which use .NET make bad decisions" to ".NET devs leave that framework because it's impossible to be a good .NET developer" is a mental leap of ludicrous proportions.

.NET is popular; with popularity comes users, and with users come haters. Don't let the haters control how you view an entire slice of the development population; the vast majority of any popular thing's supporters are silent, content to do their work and go home. The vocal minority does not represent the silent majority, and we must remember that the loudest voice is not always the most popular opinion.