6 things that kill developers’ productivity

Developers’ productivity is essential to every business organization, big or small. 

As Satya Nadella, CEO of Microsoft, put it: “Computing is a core part of every industry. A car is now a computer. Software skills are a valuable resource.” 

Nowadays, every company is in part a software company. As such, you’ll want to ensure that your developers are productive and performing to the best of their abilities.

This article aims to help you out, walking you through the six most common productivity killers. 

Avoid the list below, follow our advice, and you’ll be well on your way to a productive developer team.

A common cause of developers’ unproductivity is, frighteningly, a common daily occurrence—meetings. 

Coding is deep work, individual and immersive. If there’s a meeting at 10 am, developers are unlikely to write high-quality code that morning, as they know they’ll be interrupted. 

Now imagine if there was another meeting at 2 pm, after the lunch break at noon—developers could never get their flow back. 

In fact, the graph below shows exactly how much developers dislike meetings.

As you can see, the developers in the survey voted meetings as the second-biggest killer of productivity.

To sustain developers’ much-needed focus, it’s recommended to schedule all meetings for a single dedicated weekday. 

That way, most of the week allows for the concentrated, constant deep work developers crave. 

An exception could be made for daily scrums, but it should be a short, morning daily scrum, so it’s out of the way.

On meeting day, however, it’s essential to know the meeting’s goal, namely, what questions you’re answering. Once that’s established, you can also determine who has these answers. 

You might not need to invite your entire team. Instead, gather only the employees essential to your meeting decisions. 

You can always brief the others afterward. They’ll probably thank you for it.

Besides meetings, instant messaging and email notifications are also terrible productivity killers. 

The beeping and flashing alone can shatter a developer’s flow, content notwithstanding. Research from UC Irvine recently proved the actual cost of interruptions.

It takes almost half an hour for someone to regain their focus after an interruption, and now, in the digital age, those lurk everywhere. 

To prevent this, instruct your employees to simply turn off their notifications when they’re handling an important task. 

You’re not leading a team of surgeons—no one is going to die without an immediate response.

Similarly, suggest turning off notifications for general channels. Instead, encourage your team to only enable notifications for direct messages, as those are likely the more urgent matters. 

Another tactic is not to check emails in the morning. By attending to emails first, everyone else’s needs distract developers from their daily tasks. 

However, if they postpone reading their emails to, say, after lunch, your team members will have a much better opportunity to focus in the morning. 

Sid Savara is also a fan of this approach.

Try introducing this method as a regular practice with your team—it should dramatically increase productivity.

Technical debt isn’t an immediate disturber, but it’s deadly in the long term. Under pressure to complete their tasks, developers’ only options are sometimes duct-tape solutions. 

There’s not enough time for elegant code, so they leave things unfinished and adopt an I’ll fix it later mindset.

The problem is, there’s never enough time to fix things later, and the makeshift code remains makeshift. Some adverse effects of technical debt are shown below.

The consequences of patchy code are clearly numerous and derail developers’ productivity later on. 

However, the biggest issue with technical debt is that non-technical stakeholders often don’t realize how damaging it is until it’s too late. 

It’s hard to explain needing additional maintenance while the software works fine. 

The damage only becomes apparent when new features are added to the fragile foundations.

Therefore, when justifying the extra refactoring to stakeholders, use business terms. 

Explain that you want to reduce your TTM (Time-To-Market) or that too much budget was spent fixing quality issues. 

If you have actual numbers from the budget allowance, even better. By speaking their language, you help the stakeholders recognize the importance of regular maintenance.

To ensure no technical debt carries over, periodic check-ups are your best bet. Organize a regular refactoring week, perhaps every three weeks. 

That timeframe can be used to evaluate the architecture, prepare the groundwork for new features, and debug the code. 

Your developers will appreciate it, as their jobs will be easier in the long run. 

Maarten Dalmijin explains the perils of technical debt below.

Given the grievances described above, it’s well worth investing in a regular refactoring period where all the kinks are worked out. For that task, a bug reporting tool like Shake can help. 

Shake helps report bugs in mobile apps: users can send a detailed bug report to the development team simply by shaking the mobile phone. An example is shown below. 

Users can include screen recordings, screenshots, and markup notes in the report—everything that should assist with the debugging and ensure you keep a clean code.

Non-technical managers making technical decisions is a conundrum. You’d think most would realize the futility of such an arrangement, but that’s sadly not the case. 

Whether it’s shutting down servers to free up internet traffic or refusing to implement automated testing because that takes too long, uneducated technical decisions often do more harm than good. 

Elon Musk has also commented on this, stressing the importance of technical know-how when managing a technical environment.

Technical knowledge is a must when managing software development. Otherwise, managers lack the necessary expertise to make informed choices and don’t even realize it.

So, what exactly happens when non-technical managers make technical decisions? A real-life example is described in the post below.

In this user’s case, developers are so fed up with unproductive decisions that they’re even considering leaving the company. 

To combat this, try educating non-technical managers with a brief introduction to the tech world. 

Investing just a week of training would make a significant difference; managers would understand what they’re selling beyond the sales brochure and therefore become better at managing its progress. 

Technical training programs are everywhere—nowadays, it’s easy to study up with websites like Udemy and LinkedIn Learning. 

There are even courses specifically designed for non-technical managers to gain technical awareness.

There are countless other programs, such as this one, readily available for anyone with an Internet connection and a bank account. 

Sometimes, training is necessary even for technical managers. 

As former developers move into management positions, they spend less time honing their tech skill set, instead focusing on project management skills. 

Inevitably, fresh technologies will surface, and managers won’t have time to keep up. Who knows, it could even happen to you.

In such a situation, it’s important to trust your team—don’t blindly make any decisions based on your own five-year-old knowledge. 

Instead, own up that you’re not 100% on board with the latest and greatest. 

Your team can guide you through the process and give pointers on what’s feasible and what isn’t. Hopefully, this is an approach non-technical managers are also open to adopting.

Sometimes, the programmers are also to blame for low productivity, not just managers. 

You’ve likely encountered these more difficult developers, the type who cling to technicalities like a dog with a bone. 

Something as banal as bracket placement can slow down the entire project.

This type of disagreement can genuinely happen on a development team, stopping the project in its tracks just because one employee won’t back down.

Another troublesome character is the diva—the programmer requiring hand-written, personalized requests to produce code. 

These types are the opposite of proactive and demand special attention as to actually work.

The problem with such programmers is that they create extra work for others. If one employee isn’t pulling his weight, the other team members have to clean up after them. 

A Reddit user recounts his own experience:

Damage control usually falls to the other team members, forced to fix the mistakes of pedantic and disinterested developers. 

Although your team offers short-term solutions by correcting these mistakes, it’s up to you, the team lead, to solve the issue long-term. 

If this situation continues for too long, your productive team members will resent not only their uncooperative colleague but also their passive team lead. 

Carl Larson and Dr. Frank Lafosto have highlighted this.

It’s imperative to watch for unproductive employees and solve the problem before the morale (and productivity) of the entire team collapses.

A good strategy for this is to host early code reviews. You’ll be able to pinpoint team members who aren’t open to suggestions, don’t share work, or have similar undesirable traits. 

Approach these programmers and explain the necessities of teamwork and how much their collaboration is valued and expected. Hopefully, they’ll correct their behavior.

If nothing changes for the better, you might have to let them go. It sounds harsh, but consider the numbers below—that’s the alternative.

When you examine these bad code statistics, the cost of letting one bad developer go seems minuscule. 

If they don’t show any signs of improvement, sometimes it’s best to bite the bullet—it’s for the greater good.

Poor documentation isn’t the most apparent productivity killer, but it can be fatal. 

Extensive software documentation serves as a microscope, providing detailed insights into the code’s inner workings. 

Without documentation, however, you’re basically looking at the code through a layer of smog. 

Imagine you’ve taken over a new project, and the documentation is the second type—two pages long, with the code six months old. 

You’d quickly appreciate the benefits of quality documentation.

Unfortunately, developers tend to realize the importance of good documentation only after they need it.

Prevent this from happening to your team, and implement comprehensive documentation practices from the outset. Perhaps the easiest way is to focus on comments first. 

That isn’t difficult to implement, as comments can be written in parallel with the actual coding.

Comments are an invaluable resource, as they explain ‘why’ the code is doing what it’s doing (the ‘how’ should be self-explanatory). 

There’s almost no chance you’ll remember why you wrote the code the way you did two years ago. This is where comments come in—they explain the code to humans.

Look at this uncommented code:

It’s legible, but why it’s doing whatever it’s doing is a mystery. Here’s the same piece of code, but with comments:

With comments, we know exactly what this code was designed to do, and why. 

Show the difference to your team—they’re bound to notice the benefits and should begin including regular comments. 

Besides comments, a quality README file is essential. 

A README document provides a general overview of the software, highlighting the most salient points. It often also has guidelines on how to install and run the software. 

READMEs answer most questions you have about the software just by quickly skimming the file. Here’s an example of a good README:

Everything under the sun is covered, and you can tell right away if it’s relevant to you immediately. 

It’s worth introducing your team to its benefits and educating them on how to write a good README. 

It’ll make everyone’s lives easier, and there are even online tools to help them write one.

Small changes can make a world of difference. 

Although asking for a different IDE or a new laptop might seem like employees being picky, developers often truly perform better with updated equipment. 

Coding is a highly technical, particular process, and inadequate tools can make or break the quality of someone’s output.

For example, having a second (or third) monitor might not seem necessary, but the additional screen can mean everything to your developers.

Consider this developer’s coding set-up:

Having such a comprehensive workstation is his way of doing things and allows him to code to his best ability. You’d be slowing him down if you take away even one component. 

What is more valuable—your employees’ long-term working speed or a couple of hundred dollars of short-term expenses?

When a developer requests different or upgraded tools, speak to your finance department. Ask if the expense is within the budget, and explain the developer’s contributions to the company. Strive to illustrate their worth, and even put it into numbers if you can. Do what you can to equip your team with the best equipment out there—it should pay off in the long run.

Besides hardware, high-performing online tools are also a must. A recent Claromentis survey revealed what employees need:

As you can see, employees are lobbying for improved tools, dissatisfied with the current options. 

Fragmented apps, in particular, are a source of frustration, as developers have to switch between different disconnected software instead of navigating a single source that does it all.

Instead of utilizing ten different apps, consider investing in an intranet platform—a piece of software that houses everything your team could need in one place. 

That way, you save your team members time since they won’t have to toggle between emails, windows, and apps. The investment pays off when you realize how many minutes you’re saving.

Such statistics are a great incentive to opt for a single, one-stop software. Such a tool is bound to increase your developers’ productivity.

If you recognize any of the above at your workplace, take action. 

If technical debt and poor documentation are eating up your developer’s hours, implement regular refactoring and technical writing hours.

Alternatively, if programmers or non-technical managers are causing friction, single them out, sit down with them, and try to work through the problems.

Finally, if inadequate tools impede the progress of your team, speak to the finance department about implementing new equipment. 

If meetings constantly interrupt your employees, condense meetings to one dedicated day.

We hope the above advice makes a difference. Follow it, and your team’s productivity should shoot through the roof.