BrainsToBytes

How to destroy the productivity of a software developer (I)

Measuring productivity in software development is a complicated task.

Very important activities (like refactoring and testing) don't seem to add much immediate value to the company and therefore don't get much recognition from management. At the same time, estimating tasks is an extremely difficult thing to do well. This usually results in a big mismatch between a developer's real productivity and perceived productivity.

At the same time, there have been some terribly bad ideas in the industry (like measuring lines of code written per week) that have done much more harm than good. The thing is, productivity is hard to measure, but it's a very important aspect of any job.

Proper estimation of tasks and performance measurement is still a challenge, but that doesn't mean we can't take action to make things easier for developers. There are well-known productivity blunders that still (surprisingly) affect lots of people in the technology industry. In this article, we will discuss some of the most common ones.

Perhaps you are a software developer frustrated by the way things are at work, or maybe you are a manager with the power to change things for the better. I hope reading this will motivate you to discuss the issues and try to find solutions to these problems. In an ideal world, an article like this should not exist, but we are still working towards that goal.

Give me the tools I need to do my job

Unsurprisingly, some companies try to save money by lowering the number of resources they spend on tools for software developers.

Instead of buying a good laptop and spending money on a good IDE and other tools, they offer you subpar equipment and leave the tooling up to you. I don't know if this is obvious, but this approach is actually much more expensive for the company than buying good things from the start.

In software projects, the most expensive part (by far) is the engineer-hours. Giving your employees substandard tools just means the work will take longer, and any hope of saving any money by doing this will be reversed in a month or two.

I'm not saying you need to buy the most expensive workstation on the market and buy a super extensive set of licenses for every developer. It's about providing developers with good tools and the licenses they need to get their job done. They will be much happier and efficient if their laptops are not fighting them all the time and their IDEs have the proper support.

Fortunately, these problems seem to be extremely rare. Nowadays, most companies understand that the few hundred dollars you save at the beginning are not really worth it. Seriously, a good laptop and great tools go a long way in ensuring we can do a good job.

Keeping the troll around

Some colleagues are... hard to work with.

Let them go, without fear or hesitation, let them go. No matter how technically proficient they are, keeping them around is guaranteed to hurt your team in the long run. Not only do they demoralize and lower the productivity of the rest of the team, but they will also eventually leave you.

What you will be left with is a demoralized team that doesn't trust you to make the right choice at the right time.

A happy developer who enjoys working with people around them is productive. A developer who dreads having to go to work and deal with other person's BS is unhappy, and unhappy developers are not productive.

Strong suits influence on tech matters

Business aspects and needs will always guide the development of new technologies. It's a known fact that the non-technical management of your company and lots of other non-techies will have a heavy impact on the goals of the development team.

The issue starts when non-technical people start to have a lot to say on purely technical decisions or (god forbid), someone without a technical background gets in charge of this type of choice. One day you will enter the office and receive the following greeting:

We will start developing a new project <PROJECT_NAME> which uses technology <INSERT_HYPE>.
You: Oh, ok, why do we need that project and why that technology?
Oh <INSERT_HYPE> is the future and I believe it's going to do a lot of good for the organization.
You: Yeah ok, but what problem are we trying to solve?
Yeah I think we need to be ahead of the competition and everyone is adopting <INSERT_HYPE>, so we should do it too.
You: Oh ok, I might need to update my cv.

A technical decision is best left to technical people. This doesn't mean that there must be a natural antagonism between techies and suits, it's just that we are good at different things. Business people understand business needs, and they can help us decide which things need to get build. Technical people should be the only ones choosing how things get built and with which tools.

Unrealistic deadlines

Nothing demoralizes a team like good old unrealistic deadlines.

No one understands the intricacies of a technological project better than the developers. If a development team tells you it's going to take 4 months in the best case, you should plan for 6 or more.

Building technology is a hard task with lots of surprises and things that can go wrong. If the environment is constantly trying to push deadlines you know you can't keep, you'll end up losing motivation.

The easiest solution for this is to listen to the team's concerns. If they tell you it can't be ready in two months, putting the x on the calendar on that date will only hurt their motivation.

Ass in seat policy

This one seems to be particularly rare, as most companies seem to understand that flexible schedules and measuring performance instead of time spent in a chair are better options.

You can either measure how much time developers spend in front of a laptop, or how much value they provide, but you can't effectively measure the two at the same time. Go for value, it will make everyone's life easier and happier.

Discuss these issues

Most problems at work usually have much simpler solutions than we'd imagine.

Yes, sometimes it happens that people are not really aware there is an issue, and often they are willing to make changes to improve things. Before taking action, people need to know some problems need to be solved.

You might have some of these problems at your workplace, or maybe you face different issues. It doesn't matter, the solutions always start with the same step: talk about them.

Discuss these issues with your colleagues and managers. You will be surprised by how easy it is to solve problems once people start talking about them.

Thanks for reading!

What to do next

  • Share this article with friends and colleagues. Thank you for helping me reach people who might find this information useful.
  • This article is based on previous experience and on books on the Soft Skills & Career section of the recommended reading list. This and other very helpful books can be found in the recommended reading list.
  • Send me an email with questions, comments or suggestions (it's in the About Me page)
Author image
Budapest, Hungary
Hey there, I'm Juan. A programmer currently living in Budapest. I believe in well-engineered solutions, clean code and sharing knowledge. Thanks for reading, I hope you find my articles useful!