The miserable programmer paradox

Oy, another "good programmer, bad programmer" post.

A smart accountant once told me that the answer to "How much money did you make?" is always, "Who wants to know?" If it's an investor, the answer is "A lot." If it's a customer, the answer is "A little." If it's the IRS, the answer is "None."

Same thing here. The answer to "Who is a good programmer?" is always, "Who wants to know?"

To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer.

To a customer, the programmer who solves their problem quickest is a good programmer.

To a business owner, the programmer who makes them the most money is a good programmer.

To a PHB, the programmer who makes them look the best is a good programmer.

To a journalist, the programmer who tells the best stories is a good programmer.

To a junior programmer, the best mentor is the good programmer.

To another programmer, the programmer they are most likely to want to go into battle with is a good programmer.

To a blogger, the programmer who best fits the profile of the point he is trying to make is a good programmer.

In practice, it doesn't seem quite as bad as the article makes it out to be. I've found that by now, I spend the vast majority of my workday learning things, and the limiting factor in my productivity is how fast my brain can learn. Typing speed ceased to be a bottleneck in high school when I got up around 90 WPM. Thinking speed ceased to be a bottleneck a couple years after I started programming professionally, once I became fluent enough with the syntax and basic libraries of the languages I typically use that I don't have to reach for the docs all the time. The bottleneck is now learning libraries, data sources, requirements, and algorithms that I don't typically use. And while this can be a little annoying - it's mentally exhausting and not great for the ego that my productivity is limited by intrinsic problems with my brain - getting paid to learn things all day is a pretty nice state of affairs.

His argument isn't about good or bad programmers, it's an observation about programming: the annoying stuff can't be automated. Good programmers automate whenever they can. Therefore, the author believes, annoying stuff will eventually dominate their whole day.

Maybe your Ruby on Rails, or Scala on Snowshoes, or whatever, framework makes it trivial to create a functional site from twelve keystrokes. That just means most of your day is spent in customer meetings, gathering specs, and fixing obscure bugs.

There's some truth to this, but I also enjoy designing and communicating, which are also non-automatable. Perhaps the author doesn't like that stuff, but if so, that's sad.

And there are always ways to automate more and more; you may have to leap to a different paradigm to capture the essence of truly thorny problems, but this should be fun for a good programmer.

I was at a party with a dear friend of mine, Pat Davis, who is an expert PCB layout engineer at Millennium Design (www.millenniumdes.com). When I was healthier, I used to do some occasional PCB and automation work for his company. While the two of us were talking with another mutual friend, I said, "Working with me can be, ummm, interesting. I have zero patience for poorly built machines and programs." And then I asked Pat for affirmation from his own experience working with me.

Pat replied, "Sure, you can be tough to work with, but there is a real upside to it; if I never want to do something manually again, I just make Jon do it three times. He'll lose his patience and automate the living snot out of it."

As much as I hate to admit it, his answer was completely truthful.

A good programmer just wants the thing to work and will use whatever is best for the task.

The solution is for programmers to learn more technologies and stop being so fanboish with his favorite. Rise above the language/tool. They're nothing to do with real programming, which is solving real world problems.

Good programmers don't think about problems in a specific language, they don't read code in a specific language. It's all just code. Languages are just a crappy way for humans to write machine code. That's all.

I had a conversation with the salespeople in my organization that got me thinking about it too; as a developer, I was always talking about what was wrong or missing in my product, not what was right about it.

If you're the kind of programmer that the "buck stops with" you'll always be frustrated with what you've got because your whole job is to make it better.

On the other side you could argue that a good programmer would be able to abstract away a proportional amount of miserable work to a bad programmer, thus leaving them equally miserable.

In the end its your attitude as a person that decides if a task makes you miserable. If your attitude makes everything you do into a job — some piece of tedious labour you do at someone elses whim — then no wonder you are miserable.

The author said they can't extract a good moral, but the moral is really self-evident. Don't distract programmers!

The best mechanics I've known ended up working in jobs where they like the cars they maintain (Honda, Porsche, classic car restoration). The less skillful ones seem "trapped" working with cheap parts or cobbling things together and not doing a great job of it. They tend to have excuses about why the cars or parts are engineered poorly. I've also known very skillful mechanics that are proud of their ability to keep beat up old cars running inexpensively regardless of the brand and making their own tools rather than buying fancy ones.

Likewise, a good programmer will know the limits of the systems they are working in and will strive to not do quick fixes that cause problems later. They may also make their own tools and libraries...and they will move to companies with better politics or projects when opportunities arise.

Then, it becomes a profession. Suddenly, even if you're doing the same things, it's now something you _have_ to do. All of a sudden it's not that much fun any more.

I use python professionnally, but there are a lot of ruby openings to, some scala and clojure now, and even C# is really far from being a bad language.

I do hate to program in Java, but there is plenty of room in the tech world to let me not program any line of Java, and let that to people who like it, or simply don't mind.

So my question is i guess, if you are indeed a good programmer, and hate your tools, what stops you from learning one of the "bearable" languages that are plenty used in the industry today, and find a job where you can use it ?

There is a type of programmer who could be great, but is merely good because they refuse to use or deal with annoying techs. Sometimes, you just have no choice, and brute forcing past the annoying is by far the most efficient solution.

You all know this type. They are the kind of guy that exclusively used the Next (or Amiga), and ran windows in VM Ware on a bleeding edge Debian install in 2000 -- When the software they were being paid to develop was compiled in Visual Studio!

That's the thing. I hate MSFT. I hate Windows. I'll avoid using it. But... if the task requires that a regular PC GUI app be written, I'll use Visual Studio. Although I have been known to ask less PC phobic employees to handle this part of the job :-)

Of course, I also decided for an entire series of Playstation 2 games to forego doing the normal thing (using C/C++) and wrote my own Scheme compiler/debugger/environment. And of course, this quickly spiraled into several man years of work (on my part). It did come out pretty well. We did four games, and they sold tens of millions of copies -- dozens of programmers used the system and it was pretty cool. But boy was it stressful. I really should have figured out a way of solving my problems that didn't require so much custom programming to solve a sub-problem of my task.

My main task was: Program an absolutely fantastic 3D action game in 2-3 years.

I got sidetracked by the theory that "C/C++ sucks for writing highly customized game code" and that the compile/link/run cycle of 10+ minutes made iterative testing (which is the mother of all good gameplay) slow. This is all true, but it's a less focused problem than making a great game.

Avoiding this or that technology, or using this or that more fun one is not the same as getting the job done.

That being said, programming in Lisp, or Ruby feels like walking on water compared to C/C++'s being wrapped in chains and pushed off the boat. You just don't want to stroll off toward Australia when your gig is in Japan.

I have experienced coworkers who didn't do this. They figured out how to do certain tasks and keep repeating it into eternity, without giving a thought to how they could work more efficiently.

Most programmers above entry-level try to automate away tedious pieces. However, there's an easier explanation for the miserable programmer paradox: most programmers get good at the pieces they enjoy; thus, those pieces take less time. We tend not to get as good at technologies we dislike (Pure human nature -- if you don't like it, you're not going to play around with it as much). Thus, they take longer.

I find myselft often doing stuff that I know that my editor can do faster. Scrolling is one, but there are other examples. This not only doesn't interrupt my train of though, but it also works as "time to think".

If nagios were written in ruby/python/javascript I'd be a lot less miserable right now.

I demand executable, object oriented configuration files! It is my basic right as part of the pursuit of human happiness, as the OP has now shown conclusively.

That said, to me, a great programmer can be measured by how much fun he is having when programming. Not by how much he hate particular tasks.

Programming requires constant act of learning, that gets old real fast if you don't love what you do.

I admire programmers who can take shitty tools that he hates, cleverly hack it, and make something cool with it.

Programmers need to grow up.

If you program just to program, or "solve problems" as so many put it, then of course, you will be miserable when your pure programming is disrupted.

But work on something bigger - something you believe in - which gives you a big-picture outlook, you'll look at programming as the means to your end. And you will suffer a lot less. Even with no technical change. Because the pleasure you experience will be mostly to do with achieving your bigger goal, rather than (just) crafting the most beautiful line of code.

So many of the programmers I know set themselves up to be used as tools by people with ideas, because they claim they only care about "solving problems." So they get themselves hired by people with "interesting problems." And then, because they end up miserable, they quit in short order (1 year, 2 years, or less)... and repeat the cycle again.

It's not that jobs are inherently terrible, but that the way certain groups of very smart and capable people LOOK at jobs.

Granted, lots of people who want to "do a startup" do the same thing. They look for an interesting problem, not a bigger thing they want to achieve in the world. Their work is all about "the problem," and so they get stuck... and work on it for 1 year or 2, before they quit and look for another, more interesting problem.