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.
Get the free AI Agent Building Blocks ebook when you subscribe:
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.