So here's how I think you get the most work out of programmers. This is a follow on from part 1.
Morale
Programmers have good morale when they are treated well, and they are given a problem that they know they can solve. Thank programmers whenever they do something. Let them know you not only know how much they work, but that you care. Keep track of morale through weekly one on ones with each and every programmer. Keep track of commitments you make to your programmers (including the verbal ones) and follow through on them. Make it clear that you are looking out for their interests. (Creating a Software Engineering Culture, Chapter 3.)
Money and stock options only have a limited effect on morale, and may have a negative effect (Agile Development, p63). Most often, a gift of money or stock options is a substitute. (Rapid Development, p262). Morale events can be fun, but don't actually raise morale – they just allow for a different kind of interaction with people. (How to avoid Lame Morale Events).
And there are all kinds of things that can hurt morale. I think the major one is the Broken Window Theory (Pragmatic Programmer, p4). Under the Broken Window Theory, any neglect or rot in a system that is not directly addressed and countered is a drag on morale. People wonder why it is that they have to write good code and do things right, when they're not allowed to fix the crappy code. Management assertions that "we don't have time right now" or "we'll do it later" start to sound empty and hollow as project after project goes by, and the crappy code festers and rots as hack after hack is piled on top of it.
The Psychology of Computer Programming, Chapter 10 deals specifically with Morale and Motivation. Rapid Development, Chapter 11 goes into typical developer motivations. They are both very much worth reading.
Sleep
You can't make people sleep, and you can't do much about sleeping arrangements. But you can tell them that you want them to get 8 hours of sleep a night, and you can bring up lack of sleep as an issue. Anyone who looks sleep deprived needs help; either they have been trying to sneak in work late at night, or they're suffering in other ways. Give them all the help you can. The number of work hours will be an issue there. And if someone loads up on caffeine and junk food late at night… well, I'd point out that there may be a connection (How to Sleep Better).
Exhausted employees are easy to spot. They're the people who frighten small children and spouses. They are not fit for work. They barely even know they are at work. They should be sent home until they know what they're doing. Just that simple act of humanity will raise morale.
Focus
The best way to ensure focus is to ensure transparency and feedback. If programmers have a public, physical way to see what needs to be done at a granular level, whether in a todo list on a whiteboard or a series of 3x5 cards on the wall, they can see at a glance what they will be working on not just today, but next week as well. (Agile Development, p97) This works very well for helping out programmers who have a large list, or determining the priorities – you can only have one task on the top of the list, so what you are supposed to do is never in doubt. This is a technique that is used in several agile methodologies, and is known as an information radiator. (Crystal Clear, p32)
Don't confuse your programmers, or worse, try to multitask them. If you give them two jobs to do at the same time with the same priority, you're putting them in a situation where they cannot win; no matter what they do, they'll be working on the wrong thing. And if they try to do them in parallel, they'll do both jobs more slowly than they would if they did them sequentially. (Joel on Software) (The Multitasking Myth) (Quality Software Management)
Keep the number of goals small in a project. Pick one objective and make it clear that it's the most important one. (Rapid Development, p257)
But the best thing you can do for programmers is to let them work. Don't interrupt them. Don't spring meetings or interviews on them with no warning. Don't change what they're working on. Don't spring last minute high priority projects on them. Don't file marketing requests to change the font size as priority one critical bugs. Don't come up and ask when a bug is going to be fixed. Don't ask them for status updates every five minutes. I've seen constant change requests happen at company after company and I can tell you from experience what happens… the programmers roll their eyes, and they stop taking priority changes seriously. Because they know that in an hour's time, it won't be a priority any more. (Rapid Development, p259)
If you let your programmers work uninterrupted, something wonderful will happen. There's a psychological state called flow that has been documented by Mihaly Csikszentmihalyi. In this state, programmers are able to be "in the zone" and become focused to a great extent. Programmers in flow can produce far more code than they would be able to ordinarily. There is a catch though; it takes the average person at least 15 minutes of uninterrupted work to enter flow. If they are interrupted, or even expect to be interrupted, then they're less lightly to enter flow. (Rapid Development, p506) Some teams implement a policy called "focus time" (Crystal Clear, p33) or the "cone of silence" (Alistair Cockburn) where meetings and interruptions are banned for a portion of the day. Other teams use a red bandanna (Peopleware) or a sign to indicate that they are not to be interrupted, or other methods.
Background
The best way to have programmers with the best background in the problem domain is to cultivate them. I've been surprised in the past how little programmers know what the business does. I've often thought it would be a useful exercise to have new programmers spend some time with each member of the business team to understand their concerns and priorities. Failing that, it can be a good idea to have documentation (business process management or six sigma documentation) that can bring new programmers up to speed on the organization as a whole. Of course, this only works so far in that it doesn't track the history of the organization. Legacy code is nettlesome to new programmers, because typically they reflect legacy business processes and legacy business decisions. But ultimately, it comes with time.
Business specific domains, by nature, share little common ground with each other. There are only a couple of books I can recommend here. Domain Driven Design is the single best book I have read about how to effectively model and discuss domains. It is a similar book to Design Patterns, as it not only talks about implementation and common patterns, but it talks about domains as a common language. And Working Effectively with Legacy Code does an excellent job of pointing out useful ways to desnarl and refactor code that is no longer up to snuff.
Experience
Experience comes with work. It doesn't always come with time. To quote Weinburg, experience is the best teacher, but it doesn't necessarily teach anything. Experience can be passed on by proxy, through education and mentoring: some of the best experiences I've learned from have been the ones other people have had. If you want books that give experience, then Code Complete 2 and Refactoring are the best bets. If you want to read about experience, then Software Craftsmanship and Software Creativity are the best books. But if you want to make gathering experience, then make it available to your programmers. Set aside an education budget. Encourage your employees to attend conferences and seminars. Join a software engineering book club and have programmers pick out reference books for an in-house library. Have regular brown bag sessions and encourage your team to pass techniques around the company. Do this, and you will not only raise the general experience level of your team, but you will raise morale as well. (Rapid Development p257) (Software Craftsmanship, Chapter 19) (Building a Software Engineering Culture, Chapter 4).
Talent
You can hire talented programmers, but I think that's as much as can be done. I think that talent is not a static quality. I believe talent is a series of mental habits, and that new habits can be learned, just as old habits can be put aside. I believe that some useful habits are solid grasp of systems theory, along with an ability to ask the "right" question. But that's another essay. And there is another problem: talented people get bored doing things that don't stretch their capabilities. If you have work that doesn't require PhDs, you may be better off not hiring them.
Hours Worked
According to decades of economists and management experts: 40 hours. Contrary to popular belief, the standard work week was not invented by the government or the unions. It was pioneered by Henry Ford in 1926. More than 40 hours a week, and the factories didn't produce as much money; the temporary increase in productivity was more than offset by industrial accidents and mistakes, and after two weeks there was less productivity. (Why Crunch Mode Doesn't Work) (Can People Really Program 80 Hours a Week?) (When Should You Start Project Overtime?)
This is counter-intuitive, so I'll say it again: studies prove overtime provides a temporary benefit for a maximum of two weeks, and is worse than useless thereafter. James Shore provides a recent example.
I believe this, not just from the studies, but from my own experience with extended overtime. Programmers will not only do less work, they'll make mistakes in the work that they do. Then they'll get irritable and suffer from low morale. Then they'll burn out completely. I believe (but do not have the studies to prove) that after even after normal work hours are restored, there is a convalescent effect; people will produce less work following the overtime, producing the same amount of work overall. So after the project goes live, they'll need a long convalescent period before they're up to snuff, or even worse, they'll look up from their monitors, take a good hard look at the results of their labor and their (usually meager) rewards, and quit, producing a huge opportunity cost for the company in terms of hiring, maintenance, and reputation. (It's Not Just Abusive, It's Stupid)
For every complex problem, there is a solution which is simple, obvious, and wrong. Extended overtime is that solution.
Pressure
Fine; hours worked have no effect. What about directly applied pressure? What happens if we keep the hours, and if we tell the programmers to work harder and produce more work during those 8 hours?
Surprisingly, nothing. Programmers produce work using their brains; the amount of thoughts a programmer can have is fairly constant. Tom DeMarco and Tim Lister researched this and formulated Lister's Law: People under time pressure don't think faster. (Slack, p50) They might be more stressed, but that doesn't help people think faster; stress impedes complex thought, and pushes the brain to a "flight or flight" response. If you're stressing your programmers, they'll be at their desks more. But they're not going to write any more code.
Conclusion
This advice is all simple and straightforward. I don't see anything in here that comes as a shock, and even my mother said "Well, that's obvious, isn't it? It's like being a farmer and taking care of your cows. If you want your cows producing the most milk, you make sure they're treated like cows should be treated."
So treat your programmers well. Keep track of morale through weekly one on ones. Make it clear you care about the health and welfare of your programmers. Make sure programmers know what they should be working on at all times. Don't change out work that the programmers are doing or abuse the bug tracking system. Keep interruptions to a minimum to allow for flow. Establish a training and education budget, and establish mentoring and brown bag sessions to transfer experience. Keep to 40 hour work weeks, and forgo direct pressure.
Do all of these things, and you'll get more work out of your programmers. And you'll probably have programmers beating down your door to work for you.
EDIT: Also see this LinkedIn question that provides some useful advice. Larger monitors have been mentioned in several studies, but I don't have the references to hand.
Comments