How to manage developers

I’ve just read this article and I’ll report some parts of it with my comments

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. […]. Their minds keeps spinning and thinks about better solutions to the problems they face every day at a rate of 24 hours a day”.. [..]I sometimes cannot do anything useful for a whole day, while the next day I keep on going and going. […]. 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.. […]. 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.”

Very true. Developing is often challenging and elaborate, and cannot be done at any time. Forcing our mind to develop a central component when we are not fully concentrated will probably make us waste time only to completely redesign it later after some other dependent components have been made.
Often we have brilliant solutions to an 8 hour task that allows us to code a perfect solution for the problem in less then 30 minutes. Developers – who learn, try new solutions all the time, think widely and keep improving –  are often able to do tasks much faster than other developers. That’s not normally true for other jobs.

Do you give enough time for unit testing?
“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. “

That’s something really hard to understand for someone who is not involved directly with developing. If well used, TDD reduces the time taken to  code the solution.

Do you give enough time for planning?
“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?”

I agree with that. I like explaining the problems of a project  to non-technical people using a skyscraper as an example. If I don’t have time to plan carefully I can build some floors but if later I’m asked to build other 100 floors, I’m afraid I’ll have to destroy everything, build better basements and start over. If I’m only given cardboard to build walls, and if you ask me to make windows I’ll then have to (again) destroy everything and make new walls with the right materials.

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, 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.”

That’s right. And it has nothing to do with the ability to keep concentrated. If I’m asked to help, I have to interrupt my mental process and it will take time to restart (sometimes a lot when thinking about complex solutions). Most of the answers to our technical questions are on google, so … RTFM 😀

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. “

When two skilled developers speak, they understand each other in a few seconds whereas a communication between technical and non-technical people require much more time. It’s important to have analysts / project managers with a technical background.

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. [..] 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.”

I think that’s a good idea. We have nothing like that where I’m working now but I remember when I was working freelance I had lots of brilliant ideas when relaxing for a few minutes on the garden or walking around.

Do you give back to the opensource community?
“ 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. […] 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.”

Some companies’ policies do not allow to re-distribute the code outside with any licence whilst they make money using open source tools. Where is the trick? Altruistic companies do the job and selfish companies make money? I don’t think so.

Do you let your programmers do research?
“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.”

That’s EXTREMELY important ! A company could think that investing in training is a waste of time in case developers leave the company. Wrong! Differently from all the other jobs, development must include daily training / learning (blogs – especially phpntips 😀 – and articles, books, PHP conferences and meetings, and reading /understanding already written CODE) that gives immediate results and improvements.