UPDATE 2016-12-25: This post has an important follow-up.

At some point in every software developer’s career, we work with someone who does negative work. The notion of negative work may sound a little strange. Someone can do no work by just… not working. How does negative work happen?

One example of this is an awful developer that was once at the same company as me. He made 2 changes to the code base over his 6-month tenure there. These changes just flat out did not work and broke other features in the product. His third code change was to undo the previous changes he had made.

Sounds like he just did zero work. Except that multiple people also encountered his errors. They had to track down whether the bugs they were seeing were the result of their work or someone else’s. They had to discuss fixing the issue with him. They had to help determine that none of the code changes were worth fixing and that the team was better off deleting those changes.

The end result was a few dozen hours wasted across the entire team. This developer did zero work AND reduced the productivity of others.

There are many other examples of this.

I’ve encountered many developers who can write code that works… but it ends up being so convoluted that other developers had to spend a significant amount of time trying to understand it. Granted, trying to understand code that someone else wrote is always a little time consuming. But the degree of how difficult something is to understand matters.

Here’s some quick math to help visualize how this can work:

Bad Developer spends 5 hours writing convoluted code. Other 4 developers on the team each spend 10 hours each trying to figure out how it works.

Net loss: (4 * 10) + 5 = 40 + 5 = 45 hours spent

Good Developer spends 10 hours writing easier to understand code. Other 4 developers on the team spend 1 hour each trying to figure out how it works.

Net loss: (4 * 1) + 10 = 4 + 10 = 14 hours spent

Difference: 45 - 14 = 31 hours

These numbers also rise exponentially. I’ve seen code so bad that it took a good developer 2 weeks to complete a task that objectively should have been 2 hours if the code was written better. The 2 hours is also being generous. That task could have taken 30 minutes if good software design was used originally.

An even more egregious form of negative work is a developer who is stuck using out of date programming practices AND has a large amount of influence at a company. These developers hate learning new things and having their workflow be different. They abuse their influence to keep processes at their companies the same so that they don’t have to learn new things. As a consequence, other developers on the team are negatively affected.

I once worked at a company where we were investigating a new way to integrate the work different developers had completed. The method we were using was taking us hours every time we needed to do it. At the time we did this twice a week. We were convinced the new method would have brought it down to minutes. However, one influential developer didn’t like any kind of change and they were allowed to veto any forward progress. It took 6 months to finally go through with it at which point that developer had to be largely ignored.

4 hours * 2 times a week * 26 weeks = 208 hours wasted over 6 months

Ouch. That is 5 weeks worth of working hours for a single person.

Can you imagine if you just did nothing for 5 weeks? If those weeks were just a waste of your life?

Fortunately those 208 hours were distributed among more than a dozen people, but it is still a terrible situation. This was also only one example at that company. The attitude that prevented progress in this one area also prevented progress in many other areas. A lot more time was wasted in other out of date practices.

That leads into the human cost of developers who do negative work. Most people want to feel a sense of accomplishment when going to work. They want to feel like their time was spent on something worthwhile. For developers that means delivering software that brings value. Wasted time prevents that.

Most of us also want to work with talented people. Working with someone who is a burden on the team is an emotional drain. They act as an obstacle to our success. They can also make us feel less value in the work we do.

The job market for developers makes it very easy for developers to solve this problem: finding another job. This is obviously an undesired outcome for a company.

So if the cost of a developer who does negative work is so high, how do they get hired? Part of it can be explained by an interview process that needs improvement, but a less talked about part is the temptation to lower hiring standards.

Sometimes a company is in a situation where a lot of work needs to be done very quickly. If there are not enough developers in the company to accomplish that goal, then more developers need to be hired. Since developers have the advantage in the job market today, it can take quite a bit of time to make a good hire. That is when the temptation to lower hiring standards appears. When the amount of work is overwhelming, some people hire in a panic. They think having more bodies in the office can only contribute to more work getting done.

That is far from the truth. Not all developers will bring positive value to your team. I understand the pressure of tight timelines, but hiring in desperation won’t solve that problem. It’ll make it worse. Bad developers will not only slow you down, but they can cause your great developers to leave your company. You will be even further behind on your project than if you hadn’t hired anyone.

I would love to hear from you if you have experiences with bad developers that you would like to share!

UPDATE 2016-12-25: This post has an important follow-up.