The Dangers of Heroes and Martyrs

harrisj@nimblecode.com (Jacob Harris) — Wed, 08 Feb 2006 20:02:00 -0800

In my last posting, I riffed at dubious length about how taking responsibility for your code (from testing and maintenance through fighting fires in extreme situations) was a lot like cleaning up after your dog—a frankly unpleasant task, but one that you owe to your colleagues and customers. More importantly, I feel you owe this obligation especially to your fellow software developers of all stripes, as we are all hurt by the cynicism that results from crappy code being left in the world.

Maybe it’s the fact that I was out yesterday for an extremely rare sick day, but I’m feeling philosophical again today about a related yet opposite problem that also strikes software developers: the hero complex. And since I’m in this frame of metaphor, it’s time to return to dog poop to explain the craziness of the hero complex. When I’m at the dog run with Bella, I always clean up her mess. And occasionally I will go and clean up someone else’s if I’m feeling charitable. But what if I were to scour the dog run for all messes and clean them up, even if other owners there should be watching after their own dogs? What if I were to regularly go to the dog run at 3am in the odd chance that there might be some more poop I could clean up? What if I strutted around all proud because of my poop scoopery? What if I were to do all this because I was magically hoping for a commendation from the Parks Department? You’d think I was nuts, and yet this is exactly the kind of thinking that motivates the heroes and martyrs of software development.

Scott Berkun’s excellent book The Art of Project Management is the only project management I’ve seen so far that talks about the dangers of this hero complex to software development. The problem with hero developers is that they derive their self esteem solely from their rescue efforts, and this can create some real problems for the software. It might encourage code to be released recklessly with little or no testing, because the developer feels he can fix all problems that occur. If the hero is really good, it might mask serious problems in the organization (a horrible testing process, other bad developers who really need to be replaced). Worst of all, the hero complex might lock the organization into a constant fire fighting mode, where all resources are allocated in reaction to things breaking on a regular basis, leading to poor strategic vision, a lack of energy for new projects, and ultimately complete burnout.

The hero complex is ultimately a problem of self esteem. In a few cases, the hero has a huge ego, which leads himself to think he really can single-handedly tackle any grand challenges that come his way (hopefully he doesn’t take down the company in the process). This is usually what most people think of as the hero complex problem, where a charismatic cocksure loner takes everybody down with him. But for most developers, the hero complex emerges in a different fashion out of low self-esteem. We have no real idea what value we’re contributing to the company, because we only get feedback when things go wrong (negative and angry), and any positive feedback usually comes at most once a year in the form of a performance review. And so, many developers easily find themselves seeking out the positive acclaim through the hero complex. But many more find themselves sacrificing more and more of their selves to curry favor with their bosses; I call this the martyr complex. For instance, you might find yourself volunteering to clean up and cover for other people’s messes, because you’re worried you’re not enough of a “team player.” You head into the office very early and work late, grab more things to be responsible for without any additional pay or help, get added to pager duty for evenings and weekends, even stagger in with a high fever from the flu –- all of this is considered worth it for getting your boss’ notice and praise. Which is crazy, because your boss most likely doesn’t care (or you work for a soulless tyrant who thinks you should put him before your own family). No offense, but you usually don’t matter as much to the company as you think you do. You need to redefine your self-esteem.

But isn’t the alternative just nihilism? No, you instead need to develop a true sense of what you contribute to the company and how the company in turn contributes to your career path. I hope to delve into my own experiences and my own dabbling in martyrdom. But that’s a subject for another time…

If You Can't Scoop The Poop, You Shouldn't Own A Dog

harrisj@nimblecode.com (Jacob Harris) — Thu, 02 Feb 2006 15:59:00 -0800

If you own a dog in New York, you’re probably very familiar with the sentiment of the title. New York has “pooper scooper laws” that require all dog walkers to clean up after their dogs. It’s not really pleasant to clean up after my dog, but it’s something I accept as part of owning her. It’s simply being considerate to my fellow person, but especially to my fellow dog owner; when someone doesn’t clean up, it makes all of us look bad.

Perhaps it’s a result of fatigue from having stayed up late the night before fixing an urgent bug, but the next morning at the dog run with Bella this seemed like a remarkably good aphorism about taking responsibility as as a programmer.

I can’t really give details, but I was up the night before fixing an extremely critical bug. I was fixing the bug because it was my fault. And I was fixing it that night because it was vitally important it not inconvenience customers any further (it had already affected them for a few days). And the bug was completely my fault, not the code’s, not the operating system’s, not my coworkers’ or the QA testers’, all mine. And this is what I told my boss and my coworkers, and this is what I think was also told to the customers.

This may sound like I am only pointing out what’s natural (like tooting my horn about how my heart is able to speed up when I exercise). But from my experience, software developers are horrible at handling failure. We blame it on the language we write in, the overwhelming complexity of our tasks, those testers we expect to find all our bugs for us or those project managers we expect to manage all our time for us. When we fall behind on deliverables, most of us keep silent and vainly hope we can catch up before the next milestone (a mistake so common it’s earned the euphemism hope creep among project managers). And when we mess up technically in front of the customer, we mask it in euphemisms like a technical error has occurred whose passive voice make the customer wonder if they’re being blamed and if errors just magically fall from the sky like rain.

To be fair, taking responsibility hurts. It damages your pride, makes you look bad for the moment, and might almost feel like a career-limiting move. But as Chad Fowler puts it in My Job Went To India, you must learn how to fail. Your managers might be pissed at the moment but I think honesty as well as concrete plan for fixing things and taking action will impress them. Your customers might be annoyed but will appreciate your forthrightness instead of fuzziness when explaining what broke and will love it if you can make things right as soon as possible instead of a few months. It’s good for your fellow developers because it fights the cynicism and despair that result from too much unapologetically bad software already. And it’s good for your character. You will actually turn out the stronger for having taken your lumps and emerging from it.

So, the next time something breaks (and there will be a next time), embrace it. And if that’s too hard for you to do, get a different career; and don’t get a dog.

Nimble Code: Tag responsibility

The Dangers of Heroes and Martyrs

If You Can't Scoop The Poop, You Shouldn't Own A Dog