Life of a Code Monkey

It happens at every party. I'm chatting with someone I just met, and he asks me what I do for a living. (It's always a he, women don't talk to me at parties.) I tell him I'm a computer programmer, and his eyes glaze over. For however long I decide to talk about my profession, he'll nod at the right times, and make the occasional "mmm" of interest, but he's checked out, judging at what point it would no longer be rude to talk to someone else.

This doesn't bother me, because if you're not part of the club, software development is a boring jumble of jargon and acronyms. Also, as essential as computers are, no one wants to know how they work. They're like cars: as long as they get us where we're going, we don't give a shit about what's under the hood.

But I've decided to explain the life of a code monkey, and you might just find it interesting if you come along for the ride. This will be no party patter full of vague pleasantries, this will be the straight dope. So just step right this way.

The most important thing I have to say about the software industry is that I love the former and hate the latter. Software can be exhilarating. It can even be artful, if you're not afraid to look under the hood. But just like any art form, it must be translated into a monetary value if you plan to eat. That means art becomes a business, and business is the domain of businessmen. For businessmen, there is no art, just products and profits. Welcome to the industry.

But for a moment, let's hold the beasts at bay and live in a code monkey utopia. For someone who really cares about software, how you build something is just as important and what you build. For the end user, it can be very hard to tell how well a piece of software is constructed. Certainly, if a program doesn't work properly and is filled with bugs, it's easy to measure its quality. But two developers could produce two programs that, in the user's eye, are identical. Yet one of them may be a masterwork crafted by a talented artisan, while the other is held together by duct tape and is just sufficient enough to earn a paycheck.

In a short period, this difference may not matter to the user, but if he has to live with an evolving piece of software over time, the difference will become apparent. Every change that is made will lead to many problems in poor software. In good software, the changes have much less effect and are much quicker to implement. When another code monkey comes along to maintain a product, he will curse the paycheck collector and praise the artisan. (Briefly, before complaining how much better it could have been done. More on that in a second.)

So for a software artisan, there is a passion to deliver what a user needs, and lay the groundwork for what will be one day needed. This will be done in as simple a manner as possible, but no simpler. It will be fairly easy to understand (compared to other code, at least) and it will be elegant. It will feature the latest ideas and patterns from the thriving community of other passionate programmers. For the layman, it will just be a piece of software that will be cursed when it doesn't do things as well as expected, and taken for granted otherwise. For a code monkey, it will be art.

Chasing this grail of great code is an intoxicating process. When I'm in the zone with no distractions, time disappears. The world fades away, and there's only the code emerging before me and the endless battle of making the computer concede to my whims. Suddenly I'll realize that the day is almost done and I haven't even had lunch yet. Anyone who has thrown himself into art of any sort will know this experience.

I wanted us to stay in my little code monkey utopia for a while. I was hoping the visit would last until the inevitable arrival of the suits. I could keep talking about the joy of making great software, the rush of struggling with a problem for hours to finally solve it, or the glorious feeling when a fellow code monkey looks at your work with awe. But the clouds have come, and the rain is starting to fall.

The price of chasing the software grail is the never-ending need for scholarship. The fundamentals of development evolve constantly, and how to apply them changes even more rapidly. Best practices and patterns have to be followed on an almost daily basis to stay current. Imagine being a writer and having to buy a new dictionary every few years because the current one just doesn't apply anymore. Imagine awaking from a ten-year coma to find you can't even read your favorite author's latest work. Such is the life of a code monkey.

Another problem is that even before we have to submit our creations to the product machine, we code monkeys have to co-exist. To keep the contrast going with writing, imagine writing a novel with ten other people. How far would you get before things would end so very badly. Even if you agreed to an over-arching plot and who would write which chapters, the fact is that disparate parts have to make sense as a whole. That means a lot of communication and compromise. And code monkeys, like any artists, have plenty of pride and ego.

Throw in a few writers who are just there for the sweet writer paycheck (okay, the analogy breaks down here, but let's move on), and suddenly you may feel like Cormac McCarthy writing the conclusion of a story that Dan Brown began and features a middle section contributed by Stephanie Meyer. (And if you're a fan of either writer, I'm very sorry, on many levels.) Even worse, imagine you have to add content between those writers. On a good day, you'll think you put Cormac's prose to shame, and on a bad one, you'll feels as if you abuse the English language even worse than Dan and Stephanie combined.

Despite these challenges, software can still come together in greatness, and despite all the brotherly fights amongst code monkeys, there's still mutual respect. If the only challenge was to deliver great software, developers could work together well enough to achieve that goal.

But software has to be sold. Which means it has to be done before someone else does the same thing. And even if you finish first, if someone else makes it cheaper or better later, you have to react or be put out of business.

There's the b word. Let's begin our descent into darkness.

I mentioned that, on a superficial level, code of vastly different quality can look the same. Better quality takes time, and time is money. That means that the quicker software is built, the happier the businessmen are. While poor code will be more expensive in the long run, and will potentially alienate users (now called "clients" in business parlance), to many profit-driven minds, the equation is simply that money now is better than money later.

Before I paint too bleak a picture, I can't say that every sales-oriented person in the software industry is short-sighted and greedy. There are many people who "get it" and understand the big picture. Some even respect the art of software.

But software has to be sold for software to be made. Someone has to sell it. That means the good guys have to compete with the slimiest, most dishonest jerk at the sleaziest company that ever managed to stay in business long enough to shit out some software (or at least promise to one day shit out software.)

Thus, the life of a code monkey is building something in the time frame that was promised in order to make a sale. To go back to the writing analogy one more time, imagine getting a call from your agent that you have to write a 500 page teenage vampire novel in four weeks. (Insert your own Stephanie Meyer joke here.)

So in that situation, what does a code monkey do? That's the hard reality of being a software developer. We care. We want to make art, but we also have to make a product. So we do our jobs the best we can, balancing what was sold with what we yearn to make. We deliver a book that's half the expected length in twice the promised time. We stick to the theme, but do our best to make it a meaningful, worthwhile creation. The client grumbles about the disparity between promise and product, but is satisfied in the end.

The result may be flawed, but damn it, it is art.