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

This is the second article in a series about productivity in software development. You can find the first article here.

In this article, we will continue discussing some of the most common obstacles in developer productivity.

Good, let's get started.

Poor team policies

Some things do wonders for the productivity of a software development team.

Software-quality-centric development, good testing practices, continuous integration, frequent deployments and code reviews all help you produce top-notch work.

Sounds awesome right? Yes, unfortunately, not all teams have these types of practice as a part of their daily work. Some teams have been doing things in a certain way for a very long time, and they might put a lot of resistance to some of these practices. If it ain't broke don't fix it, right?

These practices can be uncomfortable in the beginning, but they can really help you in the future. Think, for example, about the task of refactoring a complex piece of software and all the things that can go wrong. Having good test coverage makes refactoring much easier, and so does continuous integration.

Give them a try for a couple of months, if you don't see the point after some time you can always go back to do things the old way. In the worst case, you end up learning new practices that might be mandatory in a future job.

Bad in-house support

Access to databases and servers should be carefully managed. Give the wrong person access to data they shouldn't touch and you could be in great trouble.

Sometimes we need to access specific servers or databases to get things done, and in those situations, we are really grateful for responsive operations or IT support teams. Few things can delay a task as much as having to wait for weeks (yep, plural) to get access to the resources you need.

Having a fluid support workflow is something every developer in the world is grateful for. If your company still struggles with providing good support for this type of task, you might need to start talking to people. This is not a nice to have, it's a crucial part of our job. So please, provide us with good support and don't make the process of getting access to the resources we need a total nightmare.

Too many meetings that could have been emails

You should let people skip meetings if they don't have anything to add.

I know lots of people love holding meetings and talking about important stuff, it makes them feel productive. In reality, I believe that somewhere around 80%-90% of all meetings developers participate in could be replaced by emails.

Yes, there are genuinely important meetings where problems get solved, but if you find yourself spending an important part of your daily work in meeting rooms listening to things you barely understand, maybe it's time to set some boundaries.

Developers need to be able to spend long spans of uninterrupted time to be able to work efficiently. The context switch that meetings represent costs more than just the time spent in the meeting, it also costs the mental momentum that took you dozens of minutes to gather.

Make (most) meetings optional, and let developers decide the most important ones.

Lack of good remuneration

It's not a secret for anyone that compensation plays a big role in motivation.

Of course, some things matter more: finding meaning in your daily work, enjoying what you do, having control over how you do things are all very important aspects of any job. All these things are proven to increase satisfaction to a higher degree than money alone, but the economy is still a factor of the equation.

It's not about greed, it is about not having to worry about the monetary side of things. If you receive fair compensation, you won't need to worry about other things and can concentrate on providing as much value as possible to your employer.

Paying peanuts and expecting great work in exchange is not realistic. People often complain that there is a shortage of good software developers, I don't believe this is true. There is a shortage of experienced software developers willing to put up with unrealistic deadlines and overtime in exchange for a subpar salary.

Compensate your developers fairly, they will know how to make it worth it.

Open-plan offices

This is a controversial topic, proceed with caution!

DHH wrote a great article on the topic, and I don't think I can add anything.

You can find the article here

You are not alone

Most developers I know have experienced at least one of the issues we discussed in these two articles.

The truth is that very often the solutions for these problems are actually not that difficult, but you need to talk about them. Waiting for these problems to sort themselves out is not going to work. Even worse, assuming a passive-aggressive stance will only make things worse for yourself and everybody else.

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. It can be a bit scary, but you will soon realize that everyone is happy to make changes if it makes things better for yourself and the company.

Trust people, most of us really want to make things better for everyone, but first, we need to know about the issues.

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!