DEV Community

Cover image for 11 Mental Drains That Kill Developer Productivity (And How to Fix Them)
Peter Parser
Peter Parser

Posted on

11 Mental Drains That Kill Developer Productivity (And How to Fix Them)

You sit down to code. Two hours later, you’ve written 10 lines, switched tabs 50 times, and feel exhausted. Sound familiar?

Most developers don’t run out of skill. They run out of mental energy — wasted on tiny, repetitive, invisible drains.

Here are 11 common ones, with simple alternatives that keep your brain fresh.


1. Manually Repeating the Same Commands

The drain

Typing commands like:

git status

npm run dev

cd ../../projects/api

hundreds of times a day.

Each command takes 2 seconds, but the context switch costs 10 seconds of remembering what you were doing.

Over a day, that’s 30+ minutes of friction.


The alternative (clear action)

Create shell aliases or a Makefile.

Example for your .bashrc or .zshrc:

alias gs="git status"
alias gp="git push"
alias nr="npm run dev"
Enter fullscreen mode Exit fullscreen mode

Or for repeated multi-step workflows (restart DB, clear cache, run tests), write a Makefile:

reset-db:
    docker-compose down -v
    docker-compose up -d
    npm run migrate
Enter fullscreen mode Exit fullscreen mode

Now one command does the work of five. Your brain stays in flow.

2. Holding Too Many Things in Working Memory

The drain

You’re debugging a payment failure. You’re tracking:

  • user ID
  • payment token
  • API endpoint
  • error response
  • database state
  • three variable names

Your brain feels like a sticky whiteboard.

One distraction, and you lose half of it.


The alternative (clear action)

Externalize your thoughts.

Open a text file or notebook and write something like:

Current state: user=123, token=abc, error=timeout. Trying: increase timeout to 10s.

Use comments directly in your code:

// TODO: Investigate timeout issue with payment API
// DEBUG: paymentToken sometimes undefined here
Enter fullscreen mode Exit fullscreen mode

You can also try rubber duck debugging — explain the problem aloud to a toy, a plant, or a colleague.

Speaking forces your brain to structure the problem clearly.

When you write things down, your brain stops holding information and starts thinking.


3. Manually Repeating the Same Code Snippets

The drain

Every time you need:

  • a try/catch block
  • a useState declaration
  • a for loop over an array

you type it from scratch.

Or you copy-paste from an old file and delete irrelevant lines.

Small friction. Repeated hundreds of times per week.


The alternative

Use snippets or autocompletion.

In VS Code:

  1. Go to File → Preferences → User Snippets
  2. Create your own snippet.

Example usage:

Type:

trycatch

Then press Tab → expands into:

try {
    // your code
} catch (error) {
    console.error(error);
}
Enter fullscreen mode Exit fullscreen mode

Snippets turn 10 seconds of typing into 1 second.

Seconds saved × hundreds of repetitions = hours of reclaimed focus.


4. Context Switching Between Slack, Email, and Code

The drain

A Slack notification pops up.

  • You glance at it (2 seconds)
  • You decide to reply (30 seconds)
  • You return to coding

But research shows it can take ~23 minutes to fully return to deep focus.

Do this 5 times a day and you lose 2 hours of productive thinking.


The alternative (clear action)

Batch your communication.

Try this simple system:

  • Turn off notifications except calendar reminders
  • Check Slack at 10:00 AM
  • Check again at 1:00 PM
  • Final check at 4:00 PM

Enable Do Not Disturb on your OS or IDE.

Set a status message:

“Deep work until noon. Ping only for production fires.”

Your teammates know when you're available.

Your brain stays in flow longer.

Deep work isn't about working harder — it's about protecting your focus.

5. Fixing the Same Lint / Formatting Issues Over and Over

The drain

You write code.

Then you manually:

  • add spaces
  • fix indentation
  • move commas
  • add semicolons

Your brain acts like a linter — boring, error-prone, and wasteful.


The alternative (clear action)

Automate formatting on save.

In VS Code, install Prettier and enable auto-formatting.

Example .vscode/settings.json:

{
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
}
Enter fullscreen mode Exit fullscreen mode

Other useful formatters:

  • JavaScript → eslint --fix
  • Python → black

Now every time you press Ctrl + S, your code cleans itself automatically.

You never think about commas again.


6. Wrangling Git Conflicts That Could Have Been Avoided

The drain

You and a teammate edit the same file.

Two days later you merge and see 15 conflict markers.

You spend 45 minutes deciding whose change should win and re-testing everything.


The alternative (clear action)

Pull or rebase daily.

Before starting work:

git pull --rebase
Enter fullscreen mode Exit fullscreen mode

This moves your work on top of the latest changes, keeping conflicts small.

Also:

  • Make small commits
  • Push often

A 10-line commit conflicts far less than a 200-line commit.

Enable Git conflict memory once:

git config --global rerere.enabled true
Enter fullscreen mode Exit fullscreen mode

Git will remember previous conflict resolutions and auto-resolve next time.


7. Manually Navigating Deep Folder Structures

The drain

You need to edit a file like:

src/modules/user/features/authentication/handlers/oauth/callback.js

You click through 7 folders or type the entire path.

Each navigation breaks your mental focus.


The alternative

Use fuzzy finding.

In VS Code:

Ctrl + P
Enter fullscreen mode Exit fullscreen mode

Then type part of the filename:

auth call

VS Code finds callback.js instantly.

Terminal option using fzf:

find . -type f | fzf
Enter fullscreen mode Exit fullscreen mode

Or use z directory jumping:

z auth-hand
Enter fullscreen mode Exit fullscreen mode

Now you jump to the folder instantly.

Stop clicking. Start typing a few letters.


8. Debugging with console.log Spaghetti

The drain

You scatter logs everywhere:

console.log("here 1")
console.log("data:", data)
Enter fullscreen mode Exit fullscreen mode

Then you:

  • run the app
  • scroll through hundreds of logs
  • delete them
  • add new logs

It’s messy and slow.


The alternative (clear action)

Use a debugger.

JavaScript example:

debugger;
Enter fullscreen mode Exit fullscreen mode

Open DevTools (F12) and reload.

Execution pauses so you can:

  • inspect variables
  • step line by line
  • check the call stack

Python example:

breakpoint()
Enter fullscreen mode Exit fullscreen mode

In VS Code:

  1. Click the gutter to create a breakpoint
  2. Press F5 to debug

Debuggers turn guessing into seeing.


9. Trying to Optimize Prematurely (The Perfectionism Trap)

The drain

You spend 3 hours optimizing a sorting function.

Your dataset: 50 items.

Runtime improvement:

  • Before → 10ms
  • After → 2ms

Users will never notice.

But you just lost half a day.


The alternative (clear action)

Follow this rule:

Make it work → Make it right → Make it fast

Steps:

  1. Write correct working code
  2. Refactor for clarity
  3. Only optimize if profiling proves a bottleneck

Tools for profiling:

  • Chrome DevTools
  • Python cProfile

Ask yourself:

“Does this optimization matter to the user right now?”

If not:

// TODO: optimize if needed
Enter fullscreen mode Exit fullscreen mode

Then move on.


10. Reading Error Messages Without Understanding Them

The drain

You see a big red stack trace.

Instead of reading it, you start randomly changing code.

30 minutes later you're still stuck.


The alternative

Read the error carefully.

Ask three questions:

  1. Where did it happen?

    (File + line number)

  2. What type of error?

    (TypeError, ReferenceError, NullPointerException)

  3. What does the message say?

Example:

Cannot read property 'map' of undefined
Enter fullscreen mode Exit fullscreen mode

Translation:

Your variable is undefined.

Before changing anything:

Spend 10 seconds reading the error from top to bottom.

You’ll solve most bugs immediately.


11. Manually Running Tests After Every Change

The drain

You fix one line.

Then run tests:

npm test
Enter fullscreen mode Exit fullscreen mode

You wait 15 seconds.

Tests fail.

Fix another line.

Run again.

By the end of the day you’ve spent 30 minutes waiting for tests.


The alternative

Use watch mode.

Jest example:

npm test -- --watch
Enter fullscreen mode Exit fullscreen mode

Python example:

ptw
Enter fullscreen mode Exit fullscreen mode

(Via pytest-watch)

VS Code also supports auto-run tests on save.

Now tests run automatically in the background.

You get instant feedback without manually triggering anything.


What to Do Now

Pick one drain from this list that hits you every day.

Just one.

Apply its alternative tomorrow morning.

Notice how much calmer your mind feels by lunch.

Then pick another.

Over one month, you'll free hours of mental energy — energy you can spend solving real problems instead of fighting your workflow.


Which drain hit closest to home?

Reply with its number — let’s talk about solutions.

Top comments (0)