I identified the 7 deadly sins of engineering productivity so you don't have to
Coding isn't the problem; these habits are. Eliminate friction like context switching and decision fatigue by optimizing your system for true impact.
Most engineers are not tired because they write too much code. They are tired because they fight too much friction. We often treat productivity as the ability to do more things, doing them faster. In software engineering, this definition is wrong. True productivity is about solving hard problems effectively.
There are invisible habits that drain your executive function battery before you even write a single line of code. We must stop optimizing for busy work and start optimizing for impact.
Productivity isn’t about discipline. It’s system design.
In this post, you’ll learn
Why context switching destroys your ability to write code.
How to prioritize business value over urgent but trivial requests.
Techniques to manage your mental energy and reduce decision fatigue.
Why adding more developers to a project often slows it down.
Context switching
It takes approximately twenty-three minutes to regain deep focus after a single interruption. When you multiply this by the number of notifications you receive daily, the math becomes alarming. Tools like Slack, Teams, and email act as slot machines for your attention. They condition you to react immediately to every ping. This prevents you from ever reaching the deep state required to solve complex problems.
The modern open office often makes this worse. It creates a paradox where physical proximity hurts communication rather than helping it. Consider the colleague who interrupts you four times by 11:00 AM for a code review. While their intention is collaboration, the result is that you arrive late to your own flow state. You end the day feeling exhausted, but look at your commit history and realize you achieved nothing tangible.
The fix requires a shift in how we view communication. I’d recommend writing a document with context first and sending a link rather than tapping a shoulder. This ensures you do some deeper work preparing the doc, and the other person isn’t interrupted to take a look. I’d also recommend batching your communication. Check messages only at specific slots like 9:00, 10:00... Finally, use visual signals. Wearing noise-canceling headphones is a clearer “Do Not Disturb” sign to the room, even if you are not listening to music. Just make sure you’re not always wearing the headphones.
Multitasking and task hopping
Addiction to shallow work causes a death by a thousand cuts. Jumping between tasks gives you a false sense of speed. You feel busy. You feel like you are moving fast. Your brain is never idle. In reality, it’s killing your ability for deep work. You are trading your ability to build hard things for the ability to be responsive.
I’m sure you’ve seen this during your meetings: some team member is physically present on the call but mentally absent. They are multitasking, reading emails, or fixing a bug while others speak. When called upon, they ask people to repeat what was just said. This wastes the collective time of everyone and signals that the meeting itself has no value.
The trap here is optimizing for “response time” over “resolution time”. You might answer a message in two minutes. However, because you were distracted from your main task, it now takes three days to actually solve the bug you were working on and would have been fixed in 2 days. To fix this, focus on single-tasking and having clear visibility over the upcoming work. Work on a single task, and every other impulse gets added to your task list for later. Use the “Parking Lot” method for interruptions in meetings, and send messages before walking by someone’s desk. When a new thought comes in, write it down and immediately return to your work. Do not switch contexts.
The urgency illusion
I’ve seen that everyone wants everything for yesterday. There’s a concept known as the “Law of Triviality”, also known as “bike-shedding”. Teams will spend hours debating variable names because they are easy to understand. Meanwhile, they ignore massive architectural debt because it is difficult to discuss. We prioritize what is urgent and easy over what is important and hard.
This causes teams to rush to build a demo feature for a presentation, make it look good on the presentation, but it provides zero value to the actual customer. You dedicate resources to making a demo, even if it delays the production launch. The irony is painful. You are prioritizing internal politics over features that create actual revenue or user satisfaction. This is also shown when we over-optimize systems without a business justification.
The fix is to use the Eisenhower Matrix to ruthlessly categorize tasks. Most urgent tasks, like Slack pings, are rarely important. Most deadlines are artificial. Ask “Why?” five times to differentiate between a business deadline, like a marketing launch, and an arbitrary deadline set by a manager who just wants to see progress. Always prioritize the feature that unblocks the user over the feature that impresses the boss. Your boss’s boss will likely prefer value delivered to the user.
Parkinson’s law
Parkinson’s Law states that work expands to fill the time available for its completion. This is closely tied to the planning fallacy. Engineers underestimate costs and risks while overestimating benefits. If you allocate two weeks for a task, it will take two weeks. It will likely take even longer because you will find reasons to add complexity.
I saw this on a database migration I was working on recently. We had a hard deadline to make the upgrade, or the upgrade would be done automatically outside our work hours, causing some downtime and paging the on-call. The team wasn’t aligned with the estimation of downtime we had, and we kept working on investigations and POCs until the deadline arrived. We ended up going with the initially proposed solution anyway. The work expanded simply because the time was allocated. The perfectionism trap tells us that work is never fully done. Strict time-boxing and artificial deadlines are your only defense against endless tinkering. Now I understand why managers push for deadlines that are artificial.
Seriously, apply aggressive time-boxing. Set a deadline shorter than you think you need. Force the Minimum Viable Product. If you are running out of time, cut the scope for the initial delivery. Do not extend the time. Before you start, write down exactly what finished looks like so you do not keep polishing past the point of diminishing returns.
The Zeigarnik effect (the mental RAM leak)
The human brain remembers unfinished tasks better than finished ones. This is the Zeigarnik Effect. Unfinished tickets and bugs act as background processes that eat up your mental RAM. You cannot focus on the present because your brain is still trying to solve the puzzle you left open.
The symptoms are familiar to most developers. You think about a bug while in the shower. You try to sleep, but your mind is racing with logic errors. You find yourself unable to be present with family or friends after work. The consequence is cognitive clutter. You cannot tackle the current complex problem effectively because part of your brain is still debugging the previous problem
You need to close the loops. My fix is a shutdown ritual. Never leave a task halfway without a note. Before stopping for the day, write down the exact next step. This offloads the task from your brain to the paper. It allows you to disconnect and flush your mental RAM. And try to close your tasks instead of having many started but not finished. This frees your brain to dedicate more resources to the current task.
Decision fatigue
Willpower is a finite daily resource. This is known as ego depletion. When the path forward isn’t clear, we suffer from analysis paralysis. We over-analyze to avoid mistakes.
By mid-afternoon, you are biologically incapable of handling complex architectural decisions because you spent your battery on micro-decisions like emails and Slack replies in the morning.
To fix this, you must automate trivial decisions. Use linters like Prettier or ESLint to stop debating code style. Use templates for your tickets. Do the hardest and most decision-heavy tasks first thing in the morning when your battery is full. Intentionally limit your options. If you want to go further, have the same breakfast and be clear about which clothes you wear each day. Your brain is a single one; reducing the decisions you have to make at home will help you at work.
Brooks’s law
Brooks’s Law states that adding manpower to a late software project makes it later. As the team grows linearly, communication complexity grows exponentially. Two people have one line of communication. Ten people have forty-five lines, which are more than I wanted to draw in the image below.
You see this when you have to constantly rebase changes because the team is moving fast. This highlights the paradox between the individual and the team. The project moves faster than a single person could, but the individual developer moves slower than they would alone. Large teams also suffer from the “Ringelmann Effect”: In a fifteen-person meeting, everyone assumes someone else is paying attention, so no one does.
The fix is to keep teams small. Amazon uses the two pizza teams rule. If two pizzas cannot feed the team, it is too big. You must also decouple architectures. Build modular systems where teams can deploy independently without stepping on each other’s toes. Finally, replace status update meetings with asynchronous documentation or automated dashboards.
Conclusion
Productivity is not about working harder. It is about protecting your mental resources. You won’t eliminate all these sins by tomorrow. Teams need communication, and projects need demos.
However, you can manage them to reduce them.
Pick one of these productivity enemies to eliminate this week.
Is it turning off Slack notifications?
Is it declining the update meeting?
Is it time-boxing the task?
If you recognized yourself in any of these productivity traps, it’s time to move from awareness to action. Upgrade to the Premium Tier of the newsletter to receive the exact templates and concrete tactics needed to eliminate context switching, automate decisions, and reclaim your deep work every two weeks. Join the engineers replacing “busy work” with systems for high-impact productivity. See all benefits here.
🗞️ Other articles people like
👏 Weekly applause
Here are some articles I’ve read last week and liked:
System Design Interview: Design Airbnb by Neo Kim. For high-scale booking systems, skip the complexity of distributed transactions by co-locating things like inventory and reservations.
What Meta’s diffs per developer metric revealed about engineering at scale by Dev Interrupted . Productivity metrics are a diagnostic tool, not a scoreboard. As your team scales, stop obsessing over raw output and start measuring flow and the removal of systemic friction.
Why Asking Friends for Career Advice Backfires by Adler Hsieh. Build your own decision framework for the hard trade-offs, and treat social circles as emotional support rather than a replacement for strategic planning.
P.S. This may interest you:
Are you in doubt whether the paid version of the newsletter is for you? Discover the benefits here
Could you take one minute to answer a quick, anonymous survey to make me improve this newsletter? Take the survey here
Are you a brand looking to advertise to engaged engineers and leaders? Book your slot now
Give a like ❤️ to this post if you found it useful, and share it with a friend to get referral rewards
The fancy images are likely AI-generated, the not-so-fancy ones by me :)
I’d love to see this rewritten from a geographically distributed team or stakeholder setup. Also, in the scramble to implement AI everywhere, I’ve seen many of these mistakes made. Add more people, scope creep, etc.