Tutorial: how to manage developers

This post is not so much for developers as it is for the managers and bosses from those developers. As you probably know by now, managing software engineers (or programmers) is not an easy task. They just don’t like to play by the rules you always took for granted. Why is that? Why are those pesky programmers too hard to handle? Why is it so hard to sit down, write code and shut up??

The software managers “joel test”

Ok, so I don’t like to call it a “joel-test”, since I’m nowhere near Spolky’s capabilities or experience. However, the purpose of this test is the same as the original joel-test. Every question must be answered either by a yes or a no (no but’s…). At the end of the test, you get 1 point for each yes.

1. Do you work with lenient working hours?

Enforcing a 9 to 5 working day is fine when you are running a factory. But at 5 o’clock, a programmer doesn’t stop thinking about the problems and tasks at hand. It doesn’t start at 9 o’clock in the morning either. Their minds keeps spinning and thinks about better solutions to the problems they face every day at a rate of 24 hours a day..  And just like anybody who are in the writing-business they do get writer’s block. I sometimes cannot do anything useful for a whole day, while the next day I keep on going and going. My finest hours are most definitely not during business hours but more likely in the evening. First of all, I have a very long wake-up-routine in the morning, which makes me unconcentrated during the first few hours of the day. It is a fact.. I don’t do important migrations at 7 o’clock in the morning right after a night sleep, but I do not mind them at 2 o’clock after a whole day of work..  My mind is clearer, there are less errors that I make and problems are resolved quicker.

Now, I do not say that developers should be able to walk in the door whenever they feel like, but merely that if a programmer wants to continue until late that evening, they should be able to do it and be compensated for it, most probably by time off.  They don’t work like that because they want to, they work like that because their mind is filling up and they need to type it down before it’s gone. It’s important to stimulate this way of working.

Teleworking is also a great way for programmers to manage their time. When things are getting slow, I tend to walk to the supermarktet and get the groceries I normally pick up after work. This means that I can continue until 6 o’clock when I’m actually getting something done. Of course, not all programmers are able to cope with such freedoms, but most are..

2. Do you give enough time for unit testing?

You have to choose: Do you like to spend an extra 8 hours on unit testing before deployment, or do you like to spend 12 hours fixing bugs afterwards, while your customer is complaining about the bad website and you are in a constant fight about who picks up the bill for the extra hours? Unit testing will reduce the number of bugs massively and it is part of the programming cycle just as compiling/interpreting, deploying and writing specifications are. Off course, deadlines are always lurking around, but they should not affect QA time. Do not fall for thinking it will save you time.. It really doesn’t..

3. Do you give enough time for planning?

After a project is sold, it has to be created, and created quickly. The more time you spend on it, less profit you will get. I can understand that. Everybody probably can. But it is important to think about what you will build before you actually start building. More often than not I had to start on a project without knowing what’s going on just because there weren’t any specifications. Merely some vague idea’s and some screenshots or wire frames. Try to think of it this way: You need to build a house, but you don’t know if it’s going to be a small-sized apartment or a sky-scraper… Now, your task is to start building the concrete foundations.. Are YOU able to do that?

Spending a few extra hours or days, thinking about the project, splitting it up into small tasks of maximum a few hours will achieve at least 2 things: first, you have a good discussion about the project and have figured out a lot of bottlenecks even before typing on letter on your computer, and secondly, you get a pretty accurate hour planning. You know which tasks will become a risk, and which won’t and make planning the project a lot easier…

4. Do you give your programmers the tools they need?

This is NOT about giving everybody a license for Zend Studio or a copy of the latests “ultimate PHP IDE Deluxe enterprise edition limited 2011”. It’s about getting a programmer the tools he or she wants to use. For instance, you are using SVN for your central code repository (you ARE using version control, right?). What about the programmers who like to use GIT and use a GIT2SVN bridge to commit to SVN. In effect, it does the same thing for you, but your programmers can work while they are on the train, on the plane or any other place where they don’t have access to the central repository. And it gets easier for them to share code with others without doing intermediate meaningless check-ins in your repository. Point being: if the end result is the thing you want, don’t deny programmers the tools that make their live easier and more efficient. This example off course, is just one out of many. If programmers use tools (and they cost money), check them out and be willing to pay for them.. programmers know their tools best..

5. Do you let your programmers choose their own IDE?

The great thing about having an IDE that everybody uses is that you probably get a discount on the license costs. I cannot really think of any other reason. First of all, forcing using an IDE will restrict programmers who are used to other IDE’s. Sure, when I work in Zend Studio for a week, I can fly through it, but I’d rather use a PHPStorm or even vim for my daily work. I sincerely do not mind coding large fragments in textmate or notepad. I think most managers will think “Oh, after 2 weeks they are used to it”, which might be true, but then again: most programmers do some programming OUTSIDE your company. Open source projects, things for fun, you name it. And those projects are done in the IDE that I like. I probably are more effective and quicker in my VIM environment than any other user on their zend studio. If your programmers think an IDE is good, they will use it.

Off course, this doesn’t stop you for advising a certain IDE to (junior) programmers. If they lack the experience, this is a great way to learn using an IDE since a lot of other users in your company can answer the questions they have and set everything up and running for them. But for the more experienced (senior) programmers, enforcing is a great way to get rid of programmers..

6. Are you and others respecting “The Zone”?

We used to have a unwritten rule in a company I used to work for:  if the headset is on, do not disturb unless there is a fire. “The zone” is when programmers are so mentally focused that they run on 110% efficiency. Getting into the zone is difficult, getting pulled out of one is way too easy. As soon as I’m in the zone and somebody comes up to me to ask if in_array() is haystack/needle or needle/haystack I’m out of the zone instantly. First of all, I don’t know the answer myself so I have to look it up on php.net, just like they would need to do. So a 10 second interruption, means that getting back in the zone will take hours, if it’s possible at all.

At my current job, the zone is something that is not respected. Off course, it’s hard to tell wether or not somebody is in the zone. Neither we nor managers are mindreaders but you can spot them quite easily if you are willing to… Do not send emails and expect them to be answered immediately, or worse: walk straight to the programmer after sending the email and ask if they can read the email.. You kill productivity more than you think. Most programmers (not me though) will restrain themselve for yelling right back in your face, but they hate you at that moment.. they really do..

7. Are your programmers in the loop?

This is somewhat similar to the “planning” question. Do your programmers know what’s going on and are they consulted before closing a deal on a big project? True story: at one time we deployed a final version of a website to production when we found out that website was part of a national campaign. Of course, this “small” detail was not known by the development team. The server we deployed our website to was a single-server shared-hosting environment with a lot of other sites running on it already. If a programmer, or systemadmin for that matter had been brought into the loop earlier, they would have detected those problems right from the start.  Not you nor the customer wants to have a inaccesable server at the same time there are commercials airing on national televion. They make you look bad and you blame your programmers, while in fairness, YOU were the problem all along.

Programmers can give a much better estimate on wether or not something is possible or how long it will take. Don’t promise anything to customers when you have no clue on what it will take to actually deliver.

8. Do you minimize meetings?

Meetings are a great way of getting programmers out of the zone. First of all, most meetings are NOT interesting for programmers. Meetings tend to drift away into area’s that most programmers do not care about anyway. Discussions about planning,  customer troubles, feature requests or removals which programmers need to defend over and over again… it’s frustrating because programmers loose that battle 9 out of 10 times and by the time the meeting is over, our minds are completely blank again which means the zone cannot be further away.. Don’t plan meetings in the middle of the day (although, some will disagree with this), so it gives your programmers large enough blocks of “time” to actually do some work (and get into the zone).

9. Do you have enough distraction for programmers?

At my first software company I worked for, we used to have a big couch in the middle of the hallway. That was A-MA-ZING.. You could relax, actually take a nap and nobody would bother you. We used to roam through the hallways or staring outside the windows looking like we did do nothing while in fact, quite the opposite was true. Your mind gets fragmented and you need to clear things up, pull your mind back and see the bigger picture again after spending hours on the details. I need those periods a few times a day and most of the time a few minutes is more than enough. Don’t think programmers are doing nothing just because you don’t hear clickety-click all the time.

Buy a Wii, buy a fussball set, beter yet, buy both. Or a dartboard. Or anything that can get the mind of a programmer to relax. Just make sure you place everything away from other programmers so you don’t disturb the ones that are in the zone.

10. Do you give back to the opensource community?

Now, this question does not matter if you are using for a full 100% closed source software. In that case, you bought it, you don’t owe anybody anything. But my guess is that you aren’t 100% closed source. Do you have a serverpark with Linux? Do you use Firefox, or thunderbird? Those software is publically available and you are using it without any charge. I think it is only polite to say “thank you” when you get something for free. Let your programmers work on an opensource project once in a while. Do some bugfixing for Zend framework or PHP, work on a opensource project on github, or even deploy tools you have developped internaly to the outside world as open source and let others help you improving the code.

First off all, that is the biggest thankyou you can give to the opensource community. Secondly, you get a lot of respect as a company. Third: your programmers will see other people code, learn from it, and see how it is to work in large projects, which will benefit them, you and the company they work in. And finally: it will attract better programmers to your company as well..  how can this not be a great deal?

11. Do you let your programmers do research?

Managers tend to forget that an R&D department consists not only of development, but also of research. Suppose you use a framework and don’t let your programmers look around for other (maybe better) frameworks? How about the fact that you can’t implement new techniques just because you don’t have the knowledge or you are not even able to see their potential just because nobody around in your company can spend even 5 minutes to take a look at it?  Research is important. Programmers will gain knowledge which they can pass through to the products your company develops.

12. Do you let your programmers speak or go to conferences?

Nothing give a programmer more insight into new techniques and developments than attending conferences. They aren’t that expensive and you don’t have to send your complete development-division to a conference for a whole week. But let your developers attend them and let them pick the ones that are interessting. On those conferences they will hear a lot of other talk about the things they work with every day, discuss with other developers and bring back new idea’s and insights. Let your programmers submit papers and let them speak on those conferences. It will be a great way to attract (good) programmers to your company while giving a lot back at the same time..

The score

• 0-4 points )
  Oh dear. Developers will flee away from you as soon as they get the chance. Don’t expect any loyality, because you aren’t giving them either.
• **4-7 points ) **
  At least you have given your programmers some slack. But are you getting the kind of developers you need or just the ones that don’t argue with you and take everything for granted?
• **7-10 points ) **
  You are on the right track. Fix the missing flaws and programmers all over the country are willing to work for you. You Sir, are on the edge of becoming a good manager..
• 11 points )
  You are Chuck Norris.
• 12 points )
  You are Cal Evans.

Caution: do not take this test too seriously. But on the other hand, please do..