SJS's Journal: On Miserable Programmers

There's an article on GarlicSim that caught my attention . . . http://blog.garlicsim.org/post/2840398276/the-miserable-programmer-paradox

And it just doesn't make much sense. Perhaps it's just an oversimplification of how things actually work, or it's a sign of a programmer with limited experience, or maybe I've been lucky. More likely, my metrics are different.

So... what makes a programmer happy? For me, and most of the good programmers that I've worked with, what makes a programmer happy is accomplishments. The code compiles, then passes unit tests, then integrates with everyone else's code, then passes integration, functional, and acceptance tests, demonstrates well, and makes the customer happy. Good programmers also take pride in their work, so there are internal metrics that bring them happiness as well -- the code is well-documented, well-structured, organized, readable, maintainable, garners admiration from fellow coworkers, and/or is adopted by coworkers and associates; junior programmers become respected senior programmers under one's mentoring, bad programmers depart in shame, etc.

Contrariwise, miserable programmers have few events that make them happy. It's really a flux thing -- if you measure happiness-events per day, you're going to be a happy programmer; if you measure days, weeks, or months between happiness-events, you're going to be a miserable programmer.

So what's the crux of the argument on GarlicSim?

Interrupting the train of thought is bad. Not interrupting the train of thought is good.

This is not a measure of happiness or miserableness. This is a measure of OCD, or possibly Vingean Focus.

So the GarlicSim article isn't *entirely* wrong... it's just missed the basic mechanism. Interruptions slow down work, which slows the rate of happiness-event, which increases misery. Using bad tools means that more of the programmer's time is spent fighting the tools instead of getting those incremental rewards, which means when you find programmers that put up with crappy tools, they tend to be unhappy programmers. (A programmer who has a tool that's too clever will be happy, but might make a lot of other programmers unhappy. Who cares if you've figured out how to make emacs use eliza to 'help' you write documentation?)

Somewhere in this division of labor between "good technologies" and "bad technologies", "work" has been lost. Solving the problem, expressing the solution, and demonstrating the result is the work that the technologies facilitate or hinder. To put things like "go to a specific line number" in the "good technologies" and everything else in "bad technology" seems to miss the point -- work still needs to be done, and since there's no way to reduce that part to a shortcut, 'work' ends up in the 'bad technologies' slice of the pie.

Whoops.

And yet there are people who think that programming would be a lot more fun if it wasn't for those pesky requirements.

Computers should eliminate the tedious, the boring, and the error-prone tasks. Finding the right tradeoff is a matter of personal preference, the problem at hand, the environment you're working in, and the constraints you're working under. And, of course, being the kind of person who enjoys telling computers what to do.