Worth Striving For

A few days ago I was talking to the CEO of my company about why I love this job so much.  I found it hard to put into words ... the best I could come up with was that I had finally found a job where I was allowed—even encouraged—to fix things.  At my last job (and at many of the companies I’ve worked for, both as employee and contractor), if you wanted to fix something that was broken or ugly, you had to have meetings about it, and you had to present business cases for it, and you had to prove to someone that it was going to make money (or save money) in some way.  At the new job, if something’s broken (or ugly), we just say: fix it.  And no one tells you how to fix it.  They just trust that you will do it the best way you know how.

Trust, you may recall, is one of the three cornerstones of what employees want, according to the Barefoot Philosophy.  So that’s a big part of the attraction, certainly.  But this is a bigger issue, touching on the concept of craftmanship that I brought up before, but only scratched the surface of.  I’ve also made a business case for why crap needs to be fixed, but this is a different side of that coin.  And I wanted to expand on this topic, partially because it would be nice to tie all those disparate thoughts together, but mainly because I was frustrated by my inability to capture the gestalt of this idea in that extemporaneous discussion with my chief executive.  But of course I’m not good at speaking off the cuff.

Then again, that’s why I have a blog.

Perhaps the easiest way to explain it is with an extended analogy.  Imagine software developement as being like building a house.  Now, there are different aspects of home construction.  Obviously the most important aspect is functionality: you need working plumbing, a sound electrical system, structural integrity, and so forth.  But never discount æsthetics.  Nobody wants to live in an ugly-ass house.

Of course, the vast majority of the coding that we programmers do is not building a new house—it’s renovating.  The house is already there when we show up; the owner just needs some repairs, or perhaps a new bathroom, or maybe even a whole new wing added on one side.  It’s often said (even by programmers) that programmers prefer writing new code to maintaining old code.  There’s some truth to that, of course.  But not as much as it seems on the surface.  There’s nothing wrong with working to maintain a beautifully built, solidly constructed old house.  Sure, you can’t go crazy and go all Frank Lloyd Wright or John Lautner on it.  The basic layout is there, and there’s only so much you can do to it.  But the popularity of home improvement shows—from modern reality TV shows like Extreme Makeover: Home Edition to the public television classic This Old House, which is still on the air after 35 years—shows us that fixing up an existing structure can be interesting, challenging, intellectually stimulating ... all the things you could ask of a construction project.  I’ve worked on a few old codebases that were still a lot of fun and gave me plenty of opportunity to exercise my creativity and leave my mark, including the one I’m working on now.

But most of them aren’t like that.  Most of them are a kind of horror show train wreck.  Which is something we all end up slowing down to watch, with a guilty sort of fascination, but it’s quite another thing to be inside it while it’s happening.  Is it any wonder that most of us are desperately trying to rewrite parts of—if not the entirety of—our old codebases?  And the reason most of them are so awful is because of this very issue that I’m trying to explain.

See, working at my last job (and, as I say, for many of my previous employers) was a bit like doing a renovation for a homeowner who tells you “Just make sure the toilets flush, and the lights come on when you hit the switch, and the walls don’t fall over.  We don’t really care if it looks pretty or not.”  Which doesn’t sound so bad until you start getting into the details of it.  “Just patch the pipes with duct tape,” they tell you.  “Yeah, we know it’s not waterproof, but a few little puddles here and there are no big deal, and actually replacing the bad plumbing would take too long and be too expensive.”  And then they say, “You know what? just leave those exposed wires there.  We’ll put up some signs warning people not to touch them.  Actually patching the drywall is too much trouble, and we’ve got other stuff for you to work on.”  And then it gets to the point where they’re trying to convince you to prop up the walls with old two-by-fours from the backyard that still have rusty nails sticking out of them.  You can probably imagine how scary it is to walk into a job like this.  But what many people forget about is how utterly depressing it is to be the guy who let things get this bad.  Not by choice, of course.  But, if no one will let you fix anything ...

Part of the reason this is so frustrating is that some of this shit is actually dangerous.  Show me a programmer who hasn’t been told to ignore a bug that they knew was screwing over customers and I’ll show you a programmer at the start of their career.  Every business makes that choice, and I will even admit that it’s not always the wrong choice.  A bug that only affects a few customers but will cost many engineer-weeks to fix is not a sane thing to tackle.  But it’s one thing to make that call one time, and quite another to make it over and over again.  And let’s not dismiss the soul-crushing anguish of the raw ugliness of it all: you’re embarrassed to admit you were a part of the crew, and you’re constantly apologizing for your part in the mess.  Hell, it doesn’t even stop when you quit: at my most recent conference, I was still apologizing to employees that had been hired by my ex-employer after I left.  “We tried to make it better,” I would say, eyes downcast.  “But we just didn’t have the political capital.”  That’s a polite way of saying “our bosses wouldn’t let us fix anything.”

So it may sound a little weak to say “I really love my job because they let me fix things,” but try to understand it from the opposite point of view: I really hate a job where they won’t let me fix things.  It’s depressing to have to work in that environment day after day.  And, if there are any businesspeople out there reading this, let me try to put this into terms you can appreciate: this is a question of retention.  When you refuse to let people fix things, you make them miserable.  Oh, I can tell you that there are direct fiduciary benefits to a culture of improvement (and that’s true, although they’re notoriously hard to measure), but the real gain is that you keep your best, most productive employees happy, and you make it easier to hire more of the same, and if you can’t see how that is going to help your bottom line, then there’s nothing more I can say.  Here’s a great quote attributed to Hosea Ballou:

No one has a greater asset for his business than a man’s pride in his work.

I suspect this is how my CEO views it.  I don’t know for sure, because he hasn’t told me, but I’m guessing that he thinks to himself, well, my tech team always delivers when I ask them to, and sometimes even when I don’t, so if they want to go off and fix things I didn’t ask them to, and that makes them happy, then, more power to ’em.  As long as we keep doing the things that make him happy, and make the company money, he’s happy enough to let us take a little pride in our work.

And that’s what it comes down to, in the end.  I consider myself a craftsman, as I said—perhaps I should go even farther, as did web designer Richard Glover, and call myself an artisan.  I take great pride in what I produce, and I need to be producing things I can be proud of.  Give me a job that allows that—nay, encourages it—and I’m all yours.