Attribution Some rights reserved by Seattle Municipal Archives
I’ve seen some discussions recently on squeezing productivity from programmers. Generally this has the feel of, how can I get the workers in my sweat shop to grind out more.
I was a programmer, and I have a very particular philosophy of managing my programmers, so I tend to look with disdain on these attitiudes. The root of this attitude is that programmers are a commodity, and not an essential element of a company’s vision. That’s a major error for a number of reasons, that we’ll get into, but first, what are the productivity issues with programmers, and how can they be solved?
Programmers can be expensive. Depending on where you are, and what languages you want someone to write in, as well as a few other factors, finding programmers can be quite difficult. Difficult in recruiting is a way of saying expensive. Theoretically you can be firm on what you’ll pay and just look indefinitely, but you’re really denying basic economics. If the supply is low and your requirements are inflexible, you need to modify the compensation. So you may be paying a considerable amount for programmers. This can be a difficult situation if you don’t regard your developers are core members of your team and only seem them as executing ideas from the rest of the team.
Should they be seen as core members of the team? Certainly they shouldn’t just be treated like something comparable to office copiers, where you put paper in and get something out. Living in the code you should turn to them for ideas and feedback. What’s feasible? What’s possible? Don’t rely on people who don’t live in code to make all functionality decisions. Programmers can give you ideas you may never have considered.
An important thing to keep in mind is the huge range in productivity amongst programmers. Articles have been out on this for a while, and you can delve into all sorts of discussions and conflicts on them. Here’s a good starting point. The underlying premise of the debate is really good programmers aren’t marginally better, they’re orders of magnitude better. From my experience in being a programmer and managing programmers this is as much a clear and obvious fact as the sun rises each day in the east. Even with a rigid system in place to guide programmers, individual differences in the ways they’re able to figure out problems and choose the best ways to work through things makes a huge difference.
You can’t hold everyone to the same expectations for productivity or subject everyone to the same rules in an effort to force some progress. No matter what you do, some people will know more, have more experience, and be more clever in finding solutions to coding situations. Programming is not a commodity. Thinking it is will spell your ruin.
Beyond basic productivity there are also personality issues that can have a huge impact on how well developers work. I’ve worked with developers from all over the world, and some developers, and some cultures lean this way, too, tend to agree to whatever is asked, the will not push back, and they’ll do whatever is necessary to deliver. If you have any sense at all, you do not want this. On the surface it sounds great. But it’s not a simple matter of them putting in 110%, and working the extra hours. I don’t ever want someone working for me who isn’t smarter than I am. When I bring on a developer, I want someone who can figure things out, who will make decisions, who will ask questions, interact with clients, and most of all, tell me when I’ve asked for something ridiculous. Don’t make the mistake of thinking all your ideas are brilliant, and all employees should be blindly obedient. Programmers who agree to anything will cut corners and produce sloppy, unmaintainable code. You want programmers who follow the rules, who follow best practices and guidelines, who use version control. They need to do these things first, and tell you when things are impossible because they’re not willing to do things the wrong way. And you want programmers who figure these rules out themselves, not that they require you to supply all the rules.
You don’t want developers who give you exactly what you ask for. You want developers who give you what you really wanted, and who help you understand that.
Remember that programmers are humans. They are not motivated exclusively by money. Create an oppressive work environment and they won’t want to be there. Listen and make an environment that suits their needs, and you’ll attract people. You can’t always compete on compensation, and most likely you don’t want to. Most people wouldn’t dream of trying to pay developers what they’re worth. But luckily, a lot of developers will accept lower pay in exchange for some comforts. Don’t make people work in an office all the time. If they want to work from home, or wherever else, let them. What do you need them there for anyway? For the culture? So you can monitor them? Developers need insulation from annoyances. They might like to be distracted by music or movies or whatever while they work, but generally that serves to drown out other distractions and let them focus on their work. They need to be able to concentrate.
Having you hover over them constantly asking questions or trying to gauge their progress, or having other employees pass through and bother them will kill their productivity. With the exception of occasional questions that developers might ask other employees or clients directly, the only person that should interact with them to give them work, explain things or check on their status is a technical project manager. Their role is to translate tasks into tickets, assign tickets, and handle any low level work that they can, particularly work that would annoy or bog down the developers.
Some clarification on tickets. Tickets are individual tasks in a ticketing system that can easily be assigned, tracked, commented on, scheduled and marked as ready for review. This is definitely the way to work with developers. A lot of non technical people can’t get their heads around tickets, ignore the ticketing system and make long Word docs, “punch lists”, spreadsheets and emails. The technical project managers job is to take these and make them into tickets, as they should have been in the first place. If you’re concerned with programmer productivity, work in a way that most easily allows programmers to be productive. Your confusing list that management likes the look of is least efficient. Don’t do it. If you feel the need to do such things work with the technical project manager to get a report that collects certain groups of tickets. Trying to handle numerous, complex tasks in email or one long document is horrible. No, it’s not clear and easy and all in one place. Use the ticketing system. If you don’t have one, get one. If you don’t have any idea what this is about, get a technical project manager.
You don’t need developers onsite for meetings, either. Because in all likelihood, you don’t need meetings. Meetings get developers out of their zone and take a long time to tell them what they need to know, and often bring in a lot of information they don’t need to know. You’ll need them there for some problem solving and brain storming type sessions, but don’t bog them down with useless meetings.
If the prospect of modifying the way you work, finding really great programmers, and finding how to work with them seems daunting, consider working with us at InteractiveQA. Josh McCormack has gone out of his way to find brilliant programmers, make them happy and figure out exactly what they like to work on. He works with clients to figure out their needs, strategize, propose solutions and translate everything into tickets that his team (and frequently members of clients teams) work through to reach goals. Getting an effective team assembled and working can take a very long time. InteractiveQA has been developing web sites for over 7 years. We’re a tight crew that has worked together through many projects, and we know how to effectively and efficiently deliver. Josh will even come and work with you onsite if you’d like, so you have someone to lead sessions to develop requirements and specs to pass along to the developers.
