DEV Community

Cover image for Top 7 Things That Kill Developer Productivity
Suraj Vishwakarma
Suraj Vishwakarma

Posted on

Top 7 Things That Kill Developer Productivity


A few weeks back, I had an epiphany: my code time, and active code time, had a whopping 2 hours difference when working for 4 hours. To get back on track, I actively cut down my blockers and tried to reduce the gap so I can build more, and spend less time on unwanted stuff. The greater the gap between these phases, the less productive my coding becomes.

Software developers battle productivity hurdles more often than other professionals. These barriers to developer productivity often spiral into low developer confidence, less time to code and groom, and even higher instances of burnout. It also impacts their creativity, and zeal to build.

According to this week’s average global coding time on CodeTime, around 45% of the total coding time is just passive coding. The difference is resulting in the teams and organizations wasting time and money.

The lack of productivity stems from inefficient workflows, and the way devs spend their time.

In this article, we are going to look into some of the obstacles that kill the productivity of a developer. By knowing these, we can aim to shed light on the factors that can hinder development processes, delay projects, and lead to frustration for both individual developers and the entire engineering team. After knowing the problem, you can take the necessary steps to work on it.

So, let’s get started.

1. Meetings


Ineffective meetings are by far one of the most unnecessary factors that lead to less productivity of not only developers but all other stakeholders. Coding requires focus. On average it takes around 30 minutes to indulge in focus mode. But due to many meetings, this focus gets broken and again the developer has to establish focus with the code.

There is also time consumption, as sometimes 10-minute meetings stretch to an hour. Thus, it reduces the time available for actual coding and problem-solving. Also, there is unnecessary attendance that is required for some meetings. If a meeting doesn't directly involve a developer's expertise, their presence might not be required.

2. Technical Debt (Fix it later)

Technical Debt

Technical debt can be simply defined as the “Fix it later” mindset. It refers to the amount of work that has accumulated by taking shortcuts or making suboptimal code implementation during software development.

Initially, we try to make the function work and leave optimization for later. This might work in the short-term as it speeds up the project and you might meet your deadlines on time. But doing this again and again will leave a considerable amount of work to be done. Thus making it harder to maintain, extend, and improve the software

Technical debts can hamper the productivity of developers in many ways. Some of them can be:

  • The bottleneck in code review: When technical debts increase, it leads to an increase in the time spent on the code review.

  • More bugs: As the initial motive was speed and not optimization, this will lead to the introduction of hidden and unnoticed bugs.

  • Reduced code quality: Working to just make it work, will lead to bad code quality, haphazard code reviews, even no code comments, complex code, and more.

All the points mentioned above will need additional time to work on it. Thus stretching the project timeline.

3. Code Reviews

Code Reviews

Code reviews take time, and if the review process is too slow or overly bureaucratic, it can delay the integration of new code and slow down the overall development process. Sometimes developers raise PR but code reviewers don’t have time to review it. Thus increasing the time for developers to work on the next task. Even when the developer starts with the next tasks, there will be context switching while doing the code reviews. Thus hampering the concentration and productivity of the developer.

For code reviews, developers might have to attend multiple meetings causing a decrease in the productivity of developers. Often unclear or complex feedback on the code can take longer to solve the issues as it takes further conversation to understand the feedback. Code reviews are essential and a crucial part of an organization but done in the wrong way can only lead to a lack of productivity.

4. Micromanagement (Lack of Autonomy)


Micromanagement is a management style in which a supervisor closely observes and manages the work of their subordinates. In the context of developers, this can occur when a manager tries to control the way a developer codes. This can result in developers having less control over their code, processes, decisions, and creativity.

It can lead to a lack of productivity among the developers in various ways. A few of them can be:

  • Lack of Motivation: Micromanagement can show that the organization has less trust in the developer’s ability. That way, developers can easily feel demotivated.

  • Less Creativity: Developing software is a creative task where you need to have your focus to explore creative solutions. But micromanagement will lead to having less control over the code, even hindering developer creativity.

  • Slow Decision-making: Developers have to get confirmation from managers on simple decisions, wasting a lot of time in the process.

In all these cases, the productivity of the developer will go down.

5. Burnout


Burnout is one of the significant concerns of developers. Working on complex and challenging projects with tight deadlines, and the constant pressure to deliver high-quality code can lead to burnout. It can eventually lead to a fall in the developer's productivity as it will reduce the developer's focus and ability to concentrate on coding and building.

It will also lead to a decrease in the creativity and problem-solving skills of developers. It will eventually lead to a slower development cycle.

6. Poor Documentation

Poor Documentation

Documentation is essential for developers as it conveys critical information about code, projects, and processes. Poor documentation can cause significant delays in the development cycle as the developer will have to spend more time trying to understand the codebase, project, and process. Thus leading to reduced productivity for the developer.

While onboarding developers, providing poor documentation will lead to developers spending more time on tasks such as setting up the project, managing the environment, understanding the code, and other related stuff. In the absence of clear documentation, it becomes difficult to maintain and modify existing code. Developers may hesitate to refactor or make changes due to fear of breaking functionality. Thus, the productivity of the developers will be wasted on non-core tasks.

7. Unrealistic Deadlines

Unrealistic Deadlines

Deadlines are one of the things that demotivate the developers. When you have to work extensively during the smaller windows, you will get frustrated easily. It can cause burnout, poor code quality, negligence in code reviews, etc. This will lead to the accumulation of technical debts. Thus causing a fall in the productivity of the developer.

Deadlines are necessary to plan the development cycle, but putting pressure on developers by setting unrealistic deadlines will cause them stress. In stress, there will be a decrease in overall productivity and code quality.


A developer’s productivity can be hindered by the above-mentioned factors which include unnecessary meetings, accumulated technical debts, stretched code reviews, more focus on micromanagement, stress causing burnout, poor documentation of code, and setting unrealistic deadlines for projects. I have tried to shed light on the challenges that a software developer faces while in pursuit of effectiveness and creative solutions.

The key takeaway here is that these challenges can be overcome to establish a balance between the developer’s health and high productivity. You can use developer tools that can help you manage your productivity, deep focus, and work effectiveness.

Here are some tools that can help you in boosting productivity:

  • FocusGuard: It is a Chrome extension that can help you in building focus by blocking sites.

  • Code Time: It is a VS Code extension to track your coding time and active coding time.

  • JavaScript Booster: This VS Code extension can provide a suggestion for code refactoring. You can find this kind of extension for other programming languages too.

  • Hatica: While the above tools are confined to one task and are focused on coding, Hatica takes care of most of the work. It helps engineering teams boost developer productivity by improving the workflow, identifying bottlenecks, and tracking progress. By doing this, it can free a significant amount of developer’s time. Learn more about this engineering management platform here.

I hope this article has helped you understand the cause of the deterioration of the developer’s productivity. Thanks for reading the article.

Connect With Me

Let's connect and stay informed on all things tech, innovation, and beyond! 🚀

Top comments (24)

eljayadobe profile image
Eljay-Adobe • Edited
  1. Meetings — look at the itinerary, and if it isn't relevant, say "no".
  2. Technical Debt (Fix it later) — remove technical debt as soon as possible. The only person to blame for technical debt existing and lingering is ourselves (the developers).
  3. Code Reviews — imo, are practically worthless. If you want to do code reviews (because you like doing them, like I actually do), do them informally and after-the-fact of the check-in. Any issues found can be fixed later. Don't have code reviews block the process. But if you want real code reviews, the only options are either paired programming or mob programming — for continuous code reviews. Anything less than that is just gloss code reviews finding nits (curly brace placement and indentation) and typos.
  4. Micromanagement (Lack of Autonomy) — push back on micromanagement. If that doesn't work, then vote with your feet.
  5. Burnout — mix it up. The only person that can make that change happen, is you. If you don't be your own advocate for what you work on, then no one will advocate on your behalf.
  6. Poor Documentation — find bad documentation? Fix it! Find out of date documentation? Update it! Find no longer relevant documentation? Archive it! Find fluff documentation? Delete it! From documentation in the code, to architectural documentation, to API documentation, to system requirements, to end-user documentation, to technology white papers, to product life-cycle documents, to production documents, to process documents.
  7. Unrealistic Deadlines — who made those deadlines? Did you make them? Where they unrealistic to begin with? Well stop doing that! Did someone else make them? Then educate them.
fish1 profile image
Jacob Enders

I've never found pair programming to be that great. Too often I'm running through some logic in my head and then the person I am working with, will say "hey what about this", and it throws me off.

And nothing is really stopping them from nitpicking during the pair programming process, they can still say "hey add a new line there".

I do kind of like the idea of just "fixing" nit picks in the review process. If the reviewer sees a typo or a style thing, just append a commit onto the PR and have it merged in.

gabrielfemello profile image
Gabriel Felippe Mello

My latest pair programming were amazing. It depends on how you see and do It.

As a Mid-level I had three jobs, with juniors and with our senior.
With senior level, one was building the backend logics and callbacks on a Kafka consumer environment while another was working on Rails integration and data manipulation sent and received by kafka. We build all together, with little talks between one code and another. Was very prodductive.

With our juniors, I usually allow them do build the whole frontend structure while I build the APIs and backend validations ( Rails, either ). Side by side, without overestimulate or 'build the code' for the juniors, but helping on his doubts. I guess this is, actually, what pair programming is about. And it is freaking amazing for Code Review, Application Testing and validating Bussiness Logics. It all become more approachable and usefull for team.

eljayadobe profile image

Pair programming is like programming with a rubber duck. Except the duck talks.

I've done pair programming in short stretches (1-4 weeks), about a dozen times. Those few times were good experiences. The continuous code review in realtime was a huge secondary benefit.

brense profile image
Rense Bakker

Very often it is not possible to fix technical debt because some choice cannot be made yet, or because all developers are overloaded with other work by their manager. I don't think it is fair to always blame it on the developers.

As for code reviews, I find it very valuable to have other colleagues look at my work. Very often they will see things that I missed, or someone will know of a particular way to solve a problem more efficiently.

merri profile image
Vesa Piittinen • Edited

Code reviews also help block undesirable behavior. There are people who are very fast in writing code and who also have strong opinions, and unguarded can cause trouble. Having a code review step helps to add a bit of resistance and make people re-think what they are about to commit and change.

You can skip code reviews in a team where you can trust everyone (and that allows changes to happen incredibly quickly), but if someone can gain access to a repo and they can just push in changes like anyone else with no guards, you will have trouble.

An example from real life: one guy refactored the entire Redux store of a project from trunk promises to async generators in the purest form of functional programming paradigm. This did made the code shorter, but there were some problems: the guy wasn't a maintainer of that particular project, almost nobody else really wanted to work with such FP style, and there was actually a desire to get rid of that Redux store.

Thread Thread
brense profile image
Rense Bakker

Hmm ideally you want to catch such a cowboy before they make the pull request though. In my opinion code reviews should be a way to collaborate and not a means to catch unwanted behavior. Unwanted behavior should be prevented by using linters, or in the case of your redux cowboy, during work planning...

Thread Thread
merri profile image
Vesa Piittinen

Yes, you want to build an environment and system that in general encourages healthy behavior. There were multiple levels of missing things that made it possible to have the unwanted behavior.

The other reasons to have code reviews are more valuable. However I still wanted to point out this "hidden" value of code reviews, the value of having the extra bit of friction and it's indirect causes on human behavior.

fish1 profile image
Jacob Enders

Could add poor tooling to the list. I work at a company that doesn't even have source control, on top of most things you mentioned.

aarone4 profile image
Aaron Reese

I once asked my non-technical manager how I would recover lost files that were not yet in production. His suggestion was to be more careful about what I deleted...
I moved on fairly quickly after that.

surajondev profile image
Suraj Vishwakarma

That's a also a valid issue.

freddyhm profile image
Freddy Hidalgo-Monchez

I feel like tools can help to address these issues but also important is the culture change needed to even recognize there's a problem worth fixing. I feel that's often the biggest challenge.

How would you go about making a case for better documentation for example? Say to someone who believes gut feeling and asking so and so for help is a better approach?

mezieb profile image
Okoro chimezie bright

Thanks for sharing

surajondev profile image
Suraj Vishwakarma • Edited

How do you overcome a lack of productivity?

retakenroots profile image
Rene Kootstra

It starts by saying 'no' but explain why you say no. For instance a meeting that you're invited to but you know you will only be a listener. You can probably decline. With introducing technical debt you should say no when you know it will cost al lot of effort to fix later. If they insist ask for an email confirming that they want to introduce the technical debt so that you are covered and decisions have a paper trail. These two will already help a lot to gain productivity. (25+ years of dev experience)

surajondev profile image
Suraj Vishwakarma

Good idea to avoid those situations. Everybody should learn to say "No".

clickit_devops profile image
ClickIT - DevOps and Software Development

Great post! There are so many day-to-day activities that might be necessary and helpful, but by not managing them correctly they can really affect our productivity and overall performance

surajondev profile image
Suraj Vishwakarma

Absolutely! It's remarkable how the little things that we might even ignore or not considered them as unproducitve can hinder our productivity.

paulsalamone profile image
Paul Salamone

This is a great list! Can I add just one thing?

  1. The Internet and all its distractions itself :)
piyalidebroy profile image
Piyali Debroy

Good to know information's, Thank you.

bias profile image
Tobias Nickel

I need to add missing leadership and resulting unclear requirements.

mywaysql profile image

Bei einem meiner Jobs war tatsächlich das mental anstrengendste: Nicht bei den Meetings (Monologen) einzuschlafen. Fast so anstrengend, wie sich dann durch einen Fremdcode zu wühlen, der nach den dort festgelegten Konventionen erstellt wurde und in dem jeder Variablenname aus einem Roman bestand.

respect17 profile image
Kudzai Murimi

Thanks a lot!

Some comments may only be visible to logged-in visitors. Sign in to view all comments.