Listen to this post: You can download the MP3 file or subscribe in iTunes. You can read Peter Welch’s essay here: Programming Sucks. Welch starts by responding to criticisms of friends who work in manual labor fields and assume that a programmer’s life consists of sitting calmly at a desk, playing on a computer all day. Welch’s main argument is that programming can be just as hellish as the worst manual labor job, but the hell isn’t in the physical exhaustion as much as the mental insanity you have to endure. More than anything, Welch’s tone is playful and full of images, turns of phrases, and the raw, blunt honesty that tends to define programming culture. Here’s a passage: Websites that are glorified shopping carts with maybe three dynamic pages are maintained by teams of people around the clock, because the truth is everything is breaking all the time, everywhere, for everyone. Right now someone who works for Facebook is getting tens of thousands of error messages and frantically trying to find the problem before the whole charade collapses. There’s a team at a Google office that hasn’t slept in three days. Somewhere there’s a database programmer surrounded by empty Mountain Dew bottles whose husband thinks she’s dead. And if these people stop, the world burns. Most people don’t even know what sysadmins do, but trust me, if they all took a lunch break at the same time they wouldn’t make it to the deli before you ran out of bullets protecting your canned goods from roving bands of mutants. If you followed my previous blog post, Thoughts on “Documentation Avoidance for Programmers”, this article makes a nice juxtaposition. Why is programming such a hellscape to navigate? Well it doesn’t take a genius to put two and two together: When no one documents anything, you end up with a lot of code that no one understands, and hell’s bells start ringing. Welch explains that despite one’s expertise, no programmer fully understands how even his or her own computer works, and only has a modicum of expertise around a small fraction of the technology he or she needs to know: You are an expert in all these technologies, and that’s a good thing, because that expertise let you spend only six hours figuring out what went wrong, as opposed to losing your job. You now have one extra little fact to tuck away in the millions of little facts you have to memorize because so many of the programs you depend on are written by dicks and idiots. And that’s just in your own chosen field, which represents such a tiny fraction of all the things there are to know in computer science you might as well never have learned anything at all. Not a single living person knows how everything in your five-year-old MacBook actually works. Why do we tell you to turn it off and on again? Because we don’t have the slightest clue what’s wrong with it…. Would good documentation solve the problems that Welch describes in “Programming Sucks”? Only partially. It’s not just that code is undocumented, but that the approaches programmers have to take to solve problems don’t follow straightforward logic. Instead of a precise and principled engineer who writes clear, logical, easy-to-follow code that follows best practices and techniques, programmers are forced into all kinds of crazy scenarios where they have to detour away from good practices to satisfy nutty business requirements. They have to merge disparate systems and tools in new, innovative/insane ways. They have to hack together makeshift, often temporary solutions where none exist because software is due for release and project managers demand working code despite the unworkability of the coding language for the scenario. In short, programming isn’t a clear and logical exercise. It’s an art where someone jerry-rigs a solution that miraculously works though it’s built on a bit of mystery and good luck – until it breaks, and then the programmer moves into all-night