Posted by Jacob Harris
Thu, 09 Feb 2006 04:02:00 GMT
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…
Posted in Career | Tags career, job, responsibility | 1 comment
Posted by Jacob Harris
Thu, 02 Feb 2006 23:59:00 GMT
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.
Posted in Programming, Career | Tags bugs, career, responsibility | 1 comment
Posted by Jacob Harris
Fri, 30 Sep 2005 08:55:00 GMT
A pleasant surprise was waiting for me when I got home today. A copy of Chad Fowler’s excellent book My Job Went To India was waiting for me in the mail. I’m not sure that I can give an objective review (for reasons I’ll go into here), but if you are serious about making a career in programming, you should buy this book.
What Mr. Fowler does here is to take a fair and interesting look at how outsourcing has affected the field of software development. If you want a breathy ode to a flat world where we’re all information works or a hysterical screed against them foreigners taking jobs, this is not a book for you. But if you’re a programmer like me who likes to develop, but also wants to know how to control his career, this book has the pragmatic information you need.
The problem is, most software devlopers really don’t deserve their jobs more than a given developer in India or somewhere else (don’t fault them for their zeal and definitely do not underestimate their smarts). We usually fail in several ways:
- Skills. Have you learned any new technologies in the last year? How much do you control how you design and implement things, or do you just mindlessly code specs given from on high?
- Business. Any developer can see the technical dimensions of a problem, but very few are able to grasp the business side of their jobs. Do you know your business domain? Do you understand how the bottom line at your company works?
- Communication. The stereotype of the developer as a lone wolf working strange hours and sitting sullenly in a dark office is often all too true. This needs to change. If the CEO of your company doesn’t understand what you do, why exactly would he think it couldn’t be done better in India?
- Marketing. There is a world outside of your company. Should you lose your job, what sort of network do you have to draw on? And what exactly would convince an employer to hire you?
- Passion. Finally, are you sure you even want to be a developer in the first place? Is this a career you fell into, or one you want to fight for?
As I was noting earlier, self promotion is one of biggest failings of geeks these days. I realized this was my biggest problem last year, but I’m glad to see such an authoritative and well-crafted examination of the problem in Chad’s book.
Which brings me to why I must concede I can’t give an entirely objective review to this book. Around six months ago, I decided to get more involved in the online community. I started blogging, and I started reading blogs of alpha geeks whose judgements I respected. This included people in the Ruby on Rails community, and Chad’s blog was one of them. A short time later, Chad asked for test readers for his draft manuscript, and I offered to help. He accepted me as a test editor, and i enjoyed the experience immensely. It was a great way to test the strength of his book and correct weaknesses, and I have to commend Chad for it. And I’m proud I could help out and become more involved with my career in the process. It’s a good book. Buy it. It’s worth it.
Posted in Books | Tags business, career, marketing | no comments
Posted by harrisj
Fri, 08 Apr 2005 05:17:00 GMT
Okay, blogging has been around for a while to be sure. During all these years, I have been steadfast in my disdain and apathy towards blogging, deeming it little more than a way for overly extroverted people to drone on about their lives to what they imagine is a vast and enthralled audience. Which is probably still true, but why am I blogging?
Good question. In my haste to sneer at the writing crowd, I forgot that the appeal of blogging is that it is a simple and democratic communication mechanism, and this is the kicker: communication is both essential for any career and it is often the one thing most holding back software developers like myself from succeeding. Tim Bray of course says it better than me in his post Blogging Is Good (a response to the many Blogging Will Get You Fired stories recently).
Most relevant in his top 10 list to me are
No matter how great you are, your career depends on communicating. The way to get better at anything, including communication, is by practicing. Blogging is good practice.
and
Networking is good for your career. Blogging is a good way to meet people.
Well put. Having recently understood the importance of networking and communication for career success (as important if not more so than technical skill), I feel it is time for me to recant my ways and give this a shot. Who knows, I may actually enjoy it...
Posted in Meta | Tags blogs, career | no comments
