DEV Community

Cover image for Top 7 Things That Kill Developer Productivity

Top 7 Things That Kill Developer Productivity

Suraj Vishwakarma on August 07, 2023

Introduction A few weeks back, I had an epiphany: my code time, and active code time, had a whopping 2 hours difference when working for...
Collapse
 
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.
Collapse
 
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.

Collapse
 
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.

Collapse
 
eljayadobe profile image
Eljay-Adobe

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.

Collapse
 
wilmela profile image
Wilmela

You have a point

Collapse
 
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.

Collapse
 
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.

Collapse
 
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.

Collapse
 
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.

Collapse
 
surajondev profile image
Suraj Vishwakarma

That's a also a valid issue.

Collapse
 
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?

Collapse
 
mywaysql profile image
mywaySQL

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.

Collapse
 
mezieb profile image
Okoro chimezie bright

Thanks for sharing

Collapse
 
paulsalamone profile image
Paul Salamone

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

  1. The Internet and all its distractions itself :)
Collapse
 
respect17 profile image
Kudzai Murimi

Thanks a lot!

Collapse
 
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

Collapse
 
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.

Collapse
 
surajondev profile image
Suraj Vishwakarma • Edited

How do you overcome a lack of productivity?

Collapse
 
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)

Collapse
 
surajondev profile image
Suraj Vishwakarma

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

Collapse
 
piyalidebroy profile image
Piyali Debroy

Good to know information's, Thank you.

Collapse
 
bias profile image
Tobias Nickel

I need to add missing leadership and resulting unclear requirements.