Leadership optimize

10 ways to increase the productivity of your programmers

Developer time doesn't come cheap -- yet in some shops, maintaining developer productivity can be a struggle. Justin James discusses a number of ways to remove the obstacles that may be keeping your developers from working at full capacity.

Developer time doesn't come cheap -- yet in some shops, maintaining developer productivity can be a struggle. Justin James discusses a number of ways to remove the obstacles that may be keeping your developers from working at full capacity.


Programmers are expensive employees to hire and employ. They make better-than-average salaries compared to other office workers with similar experience and education levels, and they are hard to find in many parts of the country. Needless to say, with the cost of developer time being what it is, it makes sense to take steps to improve the efficiency and productivity of your development staff. Here are 10 tips to help you do just that.

Note: This information is also available as a PDF download.

#1: Minimize distractions

Most managers are aware that programming is a job that requires long periods of intense concentration. What they don't realize is that they are not doing a very good job at letting their team focus on their work. Distractions can take all sorts of forms: instant messaging, e-mails, requests for status reports, goofing off... the list is endless. What can a manager do?

One thing that can help is to change the way you communicate; start using face-to-face and phone conversations for time-critical items, and ask that your team keep e-mail and IM closed for much of the day. If possible, locate your team members in private offices so that the things happening around them do not distract them. And try to not request so many status reports!

#2: Maximize working time

There are eight hours in a workday, and it's up to you to get the most out of your team over the course of those eight hours. Many managers think that the key to higher productivity is to work more than eight hours. In reality, you will see that much of an eight-hour workday is wasted time. Meetings, for example, require not just the time for the meeting, but the time preparing for the meeting, getting to and from the meeting, arriving early to the meeting, and so on. A meeting that is scheduled for 30 minutes can easily consume 60 minutes' worth of time. Talk with your team and find out where they are "losing" a lot of time and try to eliminate those wasted hours wherever possible. Believe me, your team would rather work to be more effective in eight hours than learn to love 10-hour days.

#3: Encourage physical and mental health

Sound physical and mental health are essential to effective workers. Put simply, it is impossible to be of much use at the job when you are stressed out. And poor physical health makes it harder to stay alert and comfortable in an office environment. You can't force the people on your team to go to the gym or to start handling stress well. But you can take steps to encourage healthy lifestyles. For example, request that the vending machines be stocked with some healthy alternatives to the usual 20 oz. bottles of corn syrup and caffeine.Look for the signs of stress or burnout within your team and find a way to help alleviate it.

#4: Stop hammering nails with a screwdriver

There is something about the world of software development that leads many managers to think that all of the tools are free. Maybe it's the abundance of some really good open source and freeware tools out there. But insisting that they make do with whatever they can find for free online will kill the efficiency of your team.

If they need the full version of a tool, buy it. Many of the tools that can help your team are not open source or freeware, for better or for worse. There are few tools on the market that cost more than a week's salary for a programmer, but there are many times when using the wrong tools or no tools wastes much more than a week. That means that you will need to occasionally purchase software for them to help them do their jobs. Get used to it, and try to make the process as easy as possible. It also means that instead of your team members trying to trick evaluation copies of software into functioning beyond the time period, they can get to work.

#5: Stick to programming

A few years ago, I needed to book a flight to attend a training session. I spent about 10 minutes searching and found a flight at a price that seemed reasonable. My boss did not like the price and told me to find a better one. I spent the next day-and-a-half looking for flights. I ended up saving $50 compared to the original flight I found. Losing 12 hours of billable hours alone was more than the cost of the flight. The moral of the story? Let your programmers program. Anything outside of their job description is, by definition, a waste of their time. They are not doing what they were hired to do. Have the office administrator book flights and order office supplies; that's what they're there for.

#6: Get clear project specs

Every development project begins with a specification of one kind or another. Poor specifications lead to work being thrown out or time being wasted as the development team keeps asking for further clarification. Talk to your team and find out if the requests they receive are well written and convey the information that is necessary to minimize lost and wasted time. Chances are, your project definition process could be improved, and by doing so, you will save a ton of time on development.

#7: Make sure the environment is safe and comfortable

Your office environment plays a role in how well your team performs -- and I'm not talking about the office recycling policy. Are you purchasing high quality, comfortable chairs and desks for people that allow them to work without pain? Or are you buying junk from the local college's surplus store? Are your programmers battling the eye strain from bright overhead fluorescent lights glaring on their monitors or do they have full spectrum task lights available? Is your office at a ridiculous temperature? A good environment is not just about "creature comforts," it's about providing people with a space to work with minimal risk of injury and pain. You will also see that the people on your team will have a better attitude and will be able to work better with a friendlier office environment.

#8: Pay attention to your attitude

My experience has been that the attitude of a group leader quickly affects the entire team, for better or for worse. When the leader of a group has a good attitude, that group works harder and better and helps each other out. When the leader of a group has a bad attitude, the group underperforms and fights among itself. How is your attitude affecting your team?

#9: Don't overlook mentors, training, and education

One of the most common complaints I hear from other developers is that their employers invest little-to-no money or time into their continued growth. Developers are expected to learn new techniques and skills on their own time on their own dime. Many good programmers simply do not have the time, money, or desire to do this. As a result, they often lag in terms of learning new skills or improving existing ones. If you want to have better programmers on your team, take a look at having the more knowledgeable people on your team mentor the less experienced members. You also want to look at training opportunities. Even if training is not possible due to budgetary constraints, it is wholly possible to conduct internal training sessions or to allow employees to spend a portion of their time on self-education. As your developers get better at their jobs, they will be more productive.

#10: Code reviews

When does not writing code help you write code faster and better? When you are performing a code review. Schedule regular times to have code reviews performed. One of the best types of code reviews is when you have a good programmer who is only loosely familiar with the project looking at the code. When authors need to explain details, they learn their code better, and sometimes an outsider will see problems that the insiders all missed. Code reviews cost nothing but time, and often save much more time than they take to conduct.

About

Justin James is the Lead Architect for Conigent.

17 comments
highlander718
highlander718

Of course, they are all good advises ... if you want to manage a horde of lemmings. Yes you provide comfortable work environment, minimize distractions, maximize work and efficiency, stick to programmig, encourage physical and mental health (this alone sounds very good but in the context sound a little bit like nazi propaganda :-)). What I get from here, is that you forget about personal life, family, problems, events. Nooo man, while you're at work, 8 hours sharp you cannot even think of your loved ones, do not look a sec. to your family picture ...etc. Work, work, work ... will make you free, no ? All right, I'm sure you guys didn't mean it like this, just my 2c on how it might sound for some :-)

Jaqui
Jaqui

A good team [ since nothing is really a one person job any more ] should be kept together. The better you know those you are working closely with, the easier it is to break a project into tasks for the team members, and the easier it is for team members to see when someone is hitting a wall and needs to talk through the problem. Don't push ssomeone into areas of responsibility they don't want. Just because that person has the skill set needed for the position does not mean they want to be doing that. You will kill morale by having promotion policies take people away from the job they want and love/hate. [ after all, how many programmers don't have a love / hate relationship with programming? ;) ]

Tony Hopkinson
Tony Hopkinson

Programmers like reasons, directing them down a path they percieve as illogical, will make them nervous and reluctant. They don't usually care about the provenance of the reason, they just aren't comfortable with things that either don't make sense and or are contradictory. Programmers almost by definition despise doing repetitive tasks. Provide resources so they can 'tool up'. You will see the benefits, as long as the goal is realistic and clearly established.

etkinsd
etkinsd

use the Activity Vector Analysis (AVA) and a trained professional with AVA as a condition of employment. Only hire those candidates that meet the AVA criteria for software engineers/programmers. The AVA along with their education, experience, and training will ensure you hire the best candidates. Never hire someone that does not meet the AVA criteria for a software engineer/programmer to fill a software engineering/programmer position regardless of their education, previous experience, training, etc.

Justin James
Justin James

These are just 10 tips, but there are dozens more out there. We'd love to hear them! J.Ja

Justin James
Justin James

Jaqui - Those are both really good ones. You are especially right about unwanted responsibility. Some people are cut out for it, some people aren't, but forcing it is never a good idea. J.Ja

TonytheTiger
TonytheTiger

[i]directing them down a path they percieve as illogical, will make them nervous and reluctant.[/i] and it doesn't just apply to programming... :)

Justin James
Justin James

Those are good points. One trap though on giving them reasons, is that you are now setting yourself up for debate on the reasons. Sometimes, "because I said so, that's why" needs to suffice. On the flip side, a smart programmer with a good manager will eventually see that the manager makes good decisions in general, and therefore not need every decision to be justified. My favorite tool for eliminating repitition is Excel, particularly for generating SQL statements. Yes, I have also written software to write software. :) J.Ja

etkinsd
etkinsd

solve puzzles and analyze things. writing code is all about problem solving, solving puzzles, troubleshooting, etc. if you aren't the inquisitive type, like to fix things, solve problems, analyze, and stay with something until it's put to bed and completed. maybe writing code is not for you. become a manager or supervisor, you can get paid more ;)

Tony Hopkinson
Tony Hopkinson

How many organisations have the luxury of appointing someone who only does software engineering. Most of us do some of analysis, mentoring, leadership, management, training even selling... I just took this one http://www.eggheadcafe.com/articles/mb/default.asp and it gave ENTJ. It was certainly accurate in some respects. I loved won't be led by those they feel are less competent.... So according to it I should be a systems analyst, well I am, I simply follow through with an implementation to make sure my analysis was correct. I have a learned response against being too introverted, and I think this skewed the result. There's a very simple test to see whether someone is capable of being a programmer. Ask them to dig two holes side by side. If they put the soil from the first where the second is going to be, they aren't.

john.a.wills
john.a.wills

For many kinds of project it is sensible to make fairly large printouts with cross-reference etc. Ensure that programmers have work areas big enough for comfortable reading of such printouts.

Jaqui
Jaqui

I got from an earlier article / discusion here on TR, not my own idea. seems a member had seen someone pushed out of programming because company policy said he couldn't be given a raise without being promoted, and promotions all meant changing job description / duties.

Tony Hopkinson
Tony Hopkinson

The tool is not important, but if you want to condition/convert some data or meta data, before you start work, and may need a few iterations. Cut and paste & search and replace, you always tend to 'forget' a little bit the second time round. One of my colleagues did a test generator and batch tester, with all sorts of test points in it. Turned out to be so useful we had him beef it up build it into the product with a compiler directive. Now we all use it, spread the wealth. Reasons, I don't have to agree with them, in fact I often don't. One of the most annoying things about developing corporate software is technically daft reasons are often very good business ones, at least in the short term. The real challenge in IT, is trying to make the technically sound appeal to business heads more than quick, cheap, nasty and now.

Tony Hopkinson
Tony Hopkinson

after all I only made the choice in 1976, barely an eyeblink for admitting I made a mistake, given I'm really management material.....

Justin James
Justin James

You are absolutely right, large tables are needed to spread work out, and they are dirt cheap. Sometimes, the physical layout can help you spot things quickly that you would otherwise miss. Ever notice in old NASA videos, how the engineers are constantly running around to big tables and working collaboratively? :) J.Ja

Jaqui
Jaqui

that you described the situation perfectly. I'm a strong supporter of promoting existing staff rather than hiring new for higher positions, where you have staff that can handle the position and are willing to take it. I actually was given a promotion within 2 weeks of starting one position. [ new business location, all staff were new hires, all hired a week earlier than me. ] I watched everyone else get shot down for stepping up to take the position for a week before I did, and I wasn't shot down for it. The Management knew who they wanted for the position and waited to see if I would step up and take the team leader post. A very good method of not pushing someone into a position they don't want, even if they have the skills... the drawback is the damage to morale by shooting people down for trying to take it until the one you want does. I did ask why they picked me for it later on, when there wasn't any other staff around. " Coming in a week behind everyone else, catching up on missed material in 2 days and consistently being top in demonstrating knowledge of the material [ written tests ] as well as a grasp of the business logic." ~chuckle~ I actually walked away from work for a week without notice, when they said they couldn't function without me. I had to prove them wrong, since I had specifically made sure everyone I worked with knew how to do my job so that they didn't have to rely on one person who could screw them over. I might have been better at the tasks, but I had trained everyone in what and how things needed to be done. Actually, I had made sure everyone knew how to handle every job, and had implimented as flat a management structure as practicle to allow for practice in doing everything, thereby increasing the capabilities of the entire team. Yup, it was in a restaurant kitchen, but the principles work in every industry.

Justin James
Justin James

... with a really strict salary band system. There are pros and cons to that kind of system. The pro is that it ensures that no one is getting really under or over paid compared to their peers. The con is that is does not allow extraodrinary people to be compensated extraordinarily. It is an especially big problem when during times of high salaries, someone comes in and is hired at the top of the band, and there is just no place for them to go in terms of raises without promotions. J.Ja