Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an elephant in the room if you will.  Most Development Managers weren't good developers.  Many will admit it, if asked in the right context.  There's something I did once, and I hear about it done a lot:  Many developers are encouraged to be managers in order to get them out of development.  The challenge is that, in even the best case, a development manager is going to managing people who are smarter than him.

Let's warm everyone up here with a fact.  Managing people is hard.  It is seriously hard.  It's like politics.  In large part it's about understanding people, reading things they're not saying, preempting their surprises for you, and even with all that there's still luck involved.  So managers tend to be valued highly for these skills which are not just a matter of mastering, but a day to day constant struggle to keep up with.  A good manager is almost limited to not having a personality of his own.  He has to skirt that perfect feared/loved balance with every individual each with his or her own unique personality.

It gets more complicated when we include another essential skill of managers.  Managers must understand the product they're managing.  This means, by default, a Development Manager is going to have to be able to develop.  They may not need to understand a regex joke, but they are going to have to have some understanding of the development process, preferably having worked in a developer's role in the past (for long enough to understand it!).  The problem here is, in it's current state, learning to code is not something everyone knows.  It's the type of thing that is associated (rightfully) with nerds in a dark basement.  This means that most developers will not make good managers.  We're not known for social skills which are, as mentioned, a vital part of the management process.

Then we consider that, if development managers are valued more than developers, and a developer moves to a management role because he was a bad developer, he might perceive himself as a good developer, or at least a good manager.  He's getting paid more after all.  This is probably the worst bit of the cycle that I see, but it's not really helpful to the new person except to know that it exists and be prepared for it.  If you're in this role, you'll definitely benefit from the book I'm suggesting in this post.

So how do you, the new guy fresh out of college, manage these developers.  You probably majored in business management, and maybe took a few CS courses.  I'm going to assume you have a C average, because someone who has a 4.0 is probably not reading this (not because they're better than you, believe me).  My first disclaimer now is: I'm not a Development Manager.  I'm a developer.  So this is from the trenches, not from the perspective of the tallest hill.

My advice, and this is second hand from another developer, is to read the book How to Win Friends and Influence People.  In fact, I should clarify.  Don't just read it.  Too many people say "I've read that" with things that they never really absorbed.  Take this book, and live it.  I don't care what you think makes you unique, and neither do the developers you're managing.  They want you to be like this book.  Be it.  It will teach you how to play that careful balance.  It dances around each person's personalities and teaches you how to get people to do things they just don't want to do.

The second bit of advice is from my experience and advice from other developers.  You are the shield between the developers and the users.  It is explicitly your job to make sure that the nerd doesn't get bothered in his basement.  If someone he doesn't know or care about starts asking him questions he's going to get pissed off, or nervous, or confused, and he's not going to do what you want him to.  One way or another, he's going to start making mistakes and start writing bad code.  If you have ever seen what happens to an unprotected developer you will understand this.  This can be very scary stuff.

The third bit of advice: You're never going to know everything your developers are thinking.  So you need to trust them.  They need to trust you or their not going to keep you informed, but more than that, you need to trust them so that their advice comes with value.  There will be times when the CFO decides that this reporting software is going to save the company and you ask a developer and he tells you it's a bad idea.  Trust him.  After 3 years and $200,000 or more, you'll either have a barely working product that everyone hates, or you'll have abandoned the project.

Finally, and I can't stress this enough.  If your developers are any good at all, they want to code.  They may get frustrated over maintenance or whine about documentation, but they come to work every day and they do the work that you assign them, even when they're smarter than you because they like it.  Trust this fact.  They love what they do.  If you make their work environment a place that they want to be, then their love of coding will take care of the rest.  You don't have to make the work exciting, it already is.  You just need to make sure that they're not working on outdated hardware, not trying to code with 1 hand tied behind their back because of some lame decision, and not trying to do something that they're not ready for.