I was recently asked the question: what is the best way to get the most work out of my programmers?
I've thought about this for a while. In some ways, it's the story of my career – every manager I've ever had has wrestled with this question. I've worked with enough teams and individuals that I think I have a good understanding of what programmers can and can't do, and how work gets done. And how work doesn't get done, for that matter. I believe I have an answer, although certainly not the answer.
The first thing to do is to look at the assumptions behind the way the question is phrased. The assumption here is that there are veins of untapped work, hidden inside of programmers somewhere. And the manager's job is to extract it. I think that this is the wrong place to start from. I believe that most people would rather do a good job than a bad one, and will do the best work they can do given what they have to work with. (Software Creativity 2.0, p22.) The best way to phrase this question would be: "What can I do to help an individual programmer be most productive?"
So, let's construct a hypothetical employee. What is known to create productivity? Let's start from the simplest level and work up.
Morale
An employee who feels safe and secure in his position and his ability to raise issues will do more work. You can argue whether this is the cause or the effect, but it's well recognized that morale is extraordinarily important. Someone who believes in the team, the company and the work he is doing is likely to do more of it. I believe motivation and morale are equivalent, but morale feels like a better word to me.
Sleep
An employee who has slept 8 hours a day will be more productive than one who has slept 5 hours. I have yet to hear anyone argue with this in principle. Studies have been done that compare the effects of sleep deprivation to alcohol intoxication. The outcome: a programmer awake for 21 hours is effectively too drunk to drive. Think about that. There is a second stage of incapacitation, which is exhaustion AKA burnout. Exhausted employees are, by definition, not productive.
Focus
An employee who knows what he is supposed to be working on will be more productive than one who is not sure which programming task takes priority. An employee who knows that he can complete the work he is doing without having his priorities changed will be more productive than one who does not know what's coming next. Programmers dislike surprises as much as anyone else. But this also covers the programmer's inherent self-discipline. Given a gap in work, will the programmer ask what he should be working on, or will he create his own scripting language?
Background
An employee who knows the domain, the history and the subtle interplay of forces at work in the codebase will be more productive than a programmer who has no previous background in the work assigned. This factor is often overlooked, but domain expertise is an incredibly valuable asset for a programmer, and anecdotally speaking I'd say it makes an order of magnitude difference in time and quality.</p>
Experience
An experienced programmer – a veteran – is more productive than an inexperienced one. An experienced programmer will understand that this project needs two weeks just to be deployed, that there's a particular tool that's perfectly suited to refactoring the database, and when it's worth building extra flexibility into an area of the system because the business team will almost certainly want customized logic in the next release.
Talent
Some people are just good programmers. It's not simply intelligence, or interest; I've known very smart people who don't make good programmers, and some of the most interested programmers often did the worst work. A talented programmer may do work that may be simply beyond other programmers, no matter how much experience or background they have.
Hours Worked
A programmer who works 40 hours a week will do more work than one who works 20 hours a week. And a programmer who works no hours a week, will do no work. But I think everyone will agree that a programmer who works 168 hours in a week will not produce 168 hours of work. In fact, I feel fairly safe in saying that a programmer who works 168 hours will produce less usable work than the programmer who works 40 hours, because the programmer's ability to work will be degraded by lack of sleep long before they stop working. </
Conclusion
I don't think anyone will argue that the above factors matter. If any one of these goes to zero, your programmers will be effectively useless.
Obviously, these factors are interconnected. Someone with no experience will typically lack background. Someone with no sleep will he low morale very shortly, and will even lose talent. So let's see what we can do to increase these variables.
Comments