Posts tagged as: managing

Hiring and retaining high quality programmers

I recently had to chastise one of the local startup guys here in Boston for mishandling the hiring of an old programmer of mine for some contract work. The exact details aren't important, but it reminded me how much difficulty most people have trying to hire and retain good coders. During the Nineties I managed to keep almost every programmer I hired in one of the craziest job markets for programmers we'll ever see. Out of a final team of about 20 people, I never had to fire any of them, and only had one quit over 6 years, and that was because his wife became ill. It wasn't that I paid the highest salaries. I paid well, but we were about 20% below the area's top salaries. It looks like we're moving into another programmer shortage as so many new startups get funding and try to fill out their staffs, so I thought it would be helpful to review some of the lessons I learned in Web 1.0. Some of the programming techniques and business models may have changed, but programmer psychology is still the same. These rules apply equally well to hiring consultants and full time staff, although I've usually had better results with full time employees. The pressures on consultants to juggle the maximum number of projects doesn't always allow them to focus enough on each job.

• Professional Student. The first mistake employers make is insisting on a programmer who is an expert on exactly the type of application they are being hired to write. While experience is obviously important, the best programmers are professional students. They move freely between different programming languages and application types. In many cases the hot new technology is really much easier to pick up than you think, so it isn't necessary to hire an Ajax "expert" even if you know Ajax will be used in the job. More importantly, there will always be a hot new language or technique, so I'd rather hire someone who can teach themselves new tools as they appear. Because of this I make sure during the interview to stress the need to keep learning on the job. I want someone who gets excited when they hear this. I'm also biased towards self-taught programmers. A computer science degree is useful, but it's what they have learned on their own since graduating that really matters. Speaking of graduating, I haven't found any difference between someone who drops out of college and someone who finishes. In fact, it's usually the ones who quit school because they were impatient to build things that have worked out best for me.
• Front or back end. One thing that is important to discover is whether a programmer prefers working on the user interface or internal engine of an app. This distinction seems to be fairly strong, and it's hard for most people to work equally well in both areas. User interface programming doesn't necessarily mean graphic design, which is another set of skills, but it does require focusing on lots of annoying details, none of which are particularly hard in isolation, but when combined they can be a nightmare. Engine programming, on the other hand, requires an ability to conceptualize a complex algorithm and break it down into a simple and elegant solution. Instead of asking this question directly, you can ask a potential hire to describe some of the most rewarding projects he or she has completed. These will generally be gathered in either the front or back end of an application.
• Let programmers pick their colleages. It's essential to have the other programmers meet all potential hires, both individually and in groups, and to have a say in whether they are hired. I want everyone to be able to work together, and to count on each other for different skills and areas of expertise. It takes a while to build this type of ego-less team structure, but once it's in place, they will look for people who can complement the team's skills. I learned the hard way to adopt a firm "no assholes" policy. No matter how badly I wanted someone who seemed to know exactly how to solve the problem they were being hired for, I refused to hire anyone if I and the others felt we couldn't be comfortable hanging out with them.
• Programmers don't work by the hour. The biggest mistake you can make in hiring a programmer is to think in terms of the amount of hours they will be working on a specific task. There is no way to know when someone is actually coding, even if they are sitting in front of you. The other variable is the wide range of productivity between coders. In my experience, it can be as much as 100 to 1, and 10 to 1 differences are common. The only way to measure the amount of work a programmer is doing is to set clear goals and then see how long it takes to accomplish them. Within that time period, I couldn't care less how many hours were actually spent coding. I also don't believe in holding programmers to 9 to 5 schedules. As long as the work gets done quickly and with a high level of quality, they can be as flexible with their hours as they choose. All of this is dependent on you or the person who manages the programmers actually knowing what they want to get done, and being able to tell when it is completed successfully. It's the managers who don't have a clue about what software actually is that depend on hours and timeclocks.
• Let them own it. Once a programmer completes a task, they should own it, and the rest of the team should know this. I don't mean legally, but within the structure of the development staff. Pride of authorship is the best way to get high quality work and to keep code free of bugs. When something breaks, everyone should be able to turn to the person who wrote it. Over time people will develop their own areas of expertise within the team, and others will know they can trust that person to handle a specific type of task when it comes up. This allows them to self-organize when a new project comes along that requires multiple skill sets. Eventually the number of modules or applications that a coder "owns" will grow, and you have to make sure to leave them time to take on new tasks as well. Nobody wants to be stuck doing nothing but maintenance, at least nobody you would want working for you. If there are too many maintenance jobs, then it is time to hire another programmer to take over some of this code. This new programmer should be allowed to rewrite the code he takes over if he wants. It seems like a waste of time, but you generally get new features that pay for the extra work. The important thing is to make sure the new owner also feels pride of authorship.
• Keep them learning new things. It's important to allow programmers time to experiment with new languages and tools. Sometimes the best new ideas come up when "playing" with a piece of code that has nothing to do with the normal team's work. You should be willing to pay for programming classes in the evening, and budget a certain amount for trips to developers conferences. One trick I adopted was to always have a bookcase full of the latest O'Reilly books. Programmers were encouraged to take these home and keep them. If they could get one good idea from a $30 book, it was money well spent.
• Keep the lines of command clear. Programmers have to know who is allowed to assign them tasks. The worst thing is when the VP of Sales and the CEO think they can wander up to any coder and start asking them for features. There should definitely be a way for the entire company to make suggestions for future development, but getting switched from one task to another by every executive who walks into a coder's office is terribly confusing. What coders need more than anything else is big blocks of time to work on a single task. They can have multiple projects going at the same time, but they need to manage their own time. If every angry call from a customer to sales results in a new rush project, their long-term productivity drops dramatically. There must be a buffer between sales and development to make sure these "emergencies" get prioritized and consolidated into the total work flow.
• Never cancel projects. The most important rule of managing programmers is to never, ever cancel a project. There is nothing that breaks a coder's heart like having several months or even years of work thrown away. This means that before you assign a task, you must be sure you will actually see it through to completion. That doesn't mean that requirements won't change and code won't get thrown away. Throwing away a first attempt at an application is fine, as long as the coder makes that decision, and it is a way of starting fresh once the parameters of the job are better understood. That is different from deciding that you didn't actually need that application after all, and all the work on it was a total waste of time.

Managers who think of coders as if they were hourly factory workers who put in their time and don't care what happens to the results of their work will end up with exactly that. If you give a programmer the chance to learn the skills needed, the time to build the code right, and then aknowledge their ownership, you'll get the best productivity and people who will work all night and over the weekend on their own if that is what is needed to get the job done.