Oh Damn, I Think I Need To Manage!
July 12, 2007

I've been reading Joel on Software recently (the book of the website, rather than the website itself), and whilst I think he's a bit of a keen self-publicist and not always right, on the whole he talks a lot of sense.

The main thing that I get from this book, as with a few similar ones I've read over recent years, is a sense of reassurance that there are other people out there who think the same way.

This is pleasing and frustrating in equal measure - the former because it's nice to feel that you're not completely barking mad, the latter because of course it confirms what I already knew, namely that management is the main problem and that there are no magic bullets.

Increasingly over the last few years I've started to realise that I get more frustrated by bad working practices or silly decisions, and my inability to change them, than I do about almost anything else. I think I'd probably prefer to work the "right" way on something innately boring, rather than the "wrong" way on something sexy (of course, really I want to have my cake and eat it too).

I still love programming, but there's a limit to what you can do on your own and I've spent much of the last 19 years of my working life searching for the perfect manager who is technically savvy enough to know when I'm right (and correct me when I'm wrong), and politically savvy enough to protect me whilst I get on with doing things the right way. I'm now increasingly of the opinion that I probably need to give up on the search, and instead attempt to become that person for a new generation of coders. Either that or set up on my own as an indie developer, and accept that whilst there's a limit to what you can do on your own, you can still do a lot (I am sorely tempted, except that I like working in a team). I think I came to this realisation at Sony actually, but it somehow has taken quite a while to filter properly through my brain.

Apart from anything else, the argument for moving into management is a case of just keeping the blood pressure down. It is amazing just how soul destroying it is to have to put up again and again with the minor niggles that result from systemic things being wrong. To come in every day and find that the source control system still doesn't work, or to watch colleagues make the same mistakes, for the same bad reasons, again and again. Not that I don't work with some smart people, but sometimes things are just wrong. And when you know what's wrong, you know how to put it right, and you even know that it would make more sense and save the company more time and money for you to put it right yourself that to wait for the person who's job it is to do it, yet something is conspiring to prevent you, it's torture.

When you're young, you tend to either be oblivious to this stuff, or just have the time and energy to steam-roller through it (the build scripts don't work properly? No problem, I'll just work through the weekend and get them knocked into shape. Dave won't let me refactor that file system, fine - I'll just do it at home and prove to him that my way will be better). The older I get though, the more I find myself wondering why the hell I should have to put up with it. More to the point, why should Caroline have to put up with me slaving away in my spare time trying to do someone else's job as well as my own? Life is too short.

Of course working in a team is all about compromise, and I know that. I can't get my way all of the time, there are commercial realities anyway, and I can live with all sorts of rubbish practices if I feel that they are a necessary short-term evil which will be addressed once our current deadline is over. I've written more than my share of crap this-stinks-but-it-will-do-for-now code to ship things. If you have any pride in your work though, you do that sort of thing under protest, on the basis that you will get the time to go back and clean things up later.

And even under tight pressure, I'm firmly of the opinion that if you see a problem you fix it. You don't leave it for a while, until it's a really really bad problem. If you can hear it ticking, you definitely don't leave it until it blows up in your face.

Yet mysteriously that "clean things up later" bit never quite seems to happen. There's always something else with a higher priority. It seems to me that the only way to make it happen is to be the one setting the priorities, even if that does mean more time in meetings, and little or no time spent in front of a compiler.

Damn! I wonder if I can convince anyone that I'm right?