Why "never multitask" is bad advice for software engineers
Stop feeling exhausted by context switching. Learn how software engineers use "save states" and batching to manage multitasking and double their productivity.
Common productivity advice suggests that you should never multitask. This is a nice idea in theory: You hide in your cave, work on a feature, and come back when finished. It fails completely in practice for modern software engineers:
You are on an on-call rotation.
You must review pull requests from your peers.
You attend meetings that fragment your day.
You write code that takes time to build and deploy.
The expectation of pure single-tasking is a fantasy. It ignores the reality of the job.
The real enemy is not the act of doing multiple things. It is uncontrolled context swapping. Your brain spends more “CPU cycles” loading and unloading context than it does processing the actual logic. You end up exhausted at the end of the day with very little finished work to show for it
Has this happened to you?
Many people think productivity is a discipline problem. It’s not. It is a systems design problem. You don’t need more willpower. You need a better system to manage tasks. You can apply concepts from CPUs to your own work habits.
This approach helps you deliver high-quality code without burning out. Let’s look into it!
In this post, you’ll learn
How CPU concepts help us manage our attention span.
Techniques for creating mental save states to prevent data loss.
Strategies for pipelining and batching tasks to maximize throughput.
Ways to align work intensity with energy levels.
The architecture of attention
You likely face the Slack problem every day (or any software you use). Interruptions are like a forced kill signal to your current thought process. Most engineers operate in a system where the priorities are set by their communication tools. The loudest notification wins your attention immediately. This is a flaw, in my opinion.
These interruptions are not harmless context switches. They are traps that offer no opportunity to save your current state. You drop everything you are doing in the middle of a complex thought. This, sadly, results in data loss. You lose the thought process you spent twenty minutes building. You then spend another twenty minutes rebuilding it later. This is an inefficient use of your processing power.
Your brain should function differently. You should choose when to yield control to an unplanned task. This is moving from a push-based model to a pull-based model (more about these models in this other article). You ignore notifications in the moment, and not for too long, so people don't complain about your lack of responsiveness. You check for updates during designated downtime, like when you just submit a PR, while waiting on a build... This puts you back in control of your execution flow.
Doing two things at the same time is already problematic, like doing two different changes in the same codebase. However, switching between unrelated domains creates a big cold start. The cost of this switch is high because the mental model is entirely different; you need to unload and load new data. You cannot jump from debugging a race condition to discussing quarterly goals without a penalty. Better to minimize these cold starts to maintain performance.
Implementing “safe points” and mental registers
We can borrow a concept from the Java Virtual Machine known as safe points. The garbage collector waits for a thread to reach a safe point before it pauses execution. The idea is to never switch tasks in the middle of computation. You must define your own yield points instead. These could be all tests passing or a PR submission, whatever works for you.
☝️I’ve seen it’s tempting to think that submitting a prompt to AI is a yield point. That’s a problem because you’d yield too often. This is something we cover in this other article
Thanks to stopping only at these logical breaks, you are preventing data loss. I know humans don’t have internal registers or stack frames, but we forget things when we switch tasks, so we need a solution. That’s why we should externalize this. We need to create a small state dump before you yield a task. This records both the last work done, the current work (in case we yield because you’re waiting on something), and our next steps.
A good advice I have for everyone is to write concise bullet points instead of lengthy details. The simpler the system, the more likely we are not to skip it. But write all the bullet points needed, don’t rely on your memory. If in doubt, I’d lean toward writing more than needed. Do this as if you’d hand off the task to someone else. That will make sure you won’t forget about any step in the process.
I keep a small markdown file for this purpose. It acts as my working memory. I write for each “workstream” the past/present/future as I mentioned before. I also record other small TODOs that I have to do, even if they aren’t part of a bigger project (e.g., review Daniel’s PR). This scratchpad gives me peace of mind, I don’t have to remember everything in my head.
This post is all about the world not being perfect. So let’s see the different scenarios we may have
A task can be started and finished within one time block, without interruptions. For example, reviewing a PR from a peer, you may be able to finish it and just leave it approved, or leave the comments. If it needs another review in the future, it will come as a new item when you receive a notification or email, so no need to worry about it anymore. Mark it done in your scratchpad (your TODO list)
It can’t be finished because you have a hard blocker (e.g., a meeting). As the blocker is planned, just capture the details in the scratchpad and switch to the other thing
It can’t be finished because you get unexpectedly interrupted and can’t avoid it (e.g., someone in person or a pager). Because you capture the past/present/future, your scratchpad already reflects that you were working on this. In this situation, which is far from ideal, I’d just recommend dumping your first thought next to the item, take 20 seconds for it, and move to the urgent thing. It’s not perfect, but as you’re the one coming back personally to the interrupted task, you’ll be able to grab the context faster thanks to being the one writing this small snapshot of the status.
Also, if the interruption is just a couple of minutes and you’ll go back to your original task, capture down your past/present/future of any new work this interruption gives you. This also works great because the requester will feel acknowledged when they see you captured in your scratchpad their request.
The goal is that you always close your loop of that task and later come back to it. I’ve also been on the other side, someone talking to me in person, a page, a meeting’s autocall sound before I was finished... If you just switch tabs or close the laptop, you will lose data.
Even if not perfect, always follow these two principles
Write somewhere the progress of your work and the next steps.
Try to close your loop. Take 20 seconds to persist where you left off.
For example:
Prioritizing and batching
You must distinguish between the big rock and snacking. Small tasks like answering emails or minor code reviews feel productive because you can do a lot of those during the day. They distract you from high-return work. You should focus on one big problem. You cannot juggle four small rocks effectively.
Identify the work that really matters today. I want to be careful, so the message isn’t that you should be selfish and prioritize always making a direct impact through your tasks in a sprint. Some days, the most important work is reviewing a critical pull request from a peer. On other days, you must prioritize your own big impactful work. You must be clear about what the important work is before you start jumping between small tasks.
☝️In that line, premium subscribers have access to the productivity workstation, where they can make sure that they always start their day knowing their priorities. I use this every day, including for my personal projects like this newsletter. Get it here
Sometimes, you might start a task that requires input from someone else. You will have trouble if you delay this task until the deadline. That’s why here, the best action is to break down the work and prioritize the action to trigger the external communication. You wait for the response and forget about this workstream until you get notified that this work is available. Once it’s available, whenever you can pick it up, you’ll work on it again. Of course, the longer the task will be without your attention, the more details I’d add to the before/current/after state dump.
Don’t put all your efforts into one basket. If you were so rigid that you only worked on one task until finished, you’d have very little impact because you’d spend a lot of time idle. That’s why it’s good to keep 2 or 3 workstreams active.
You can batch similar tasks. For example, one TODO can be to check all your emails, all your Slack messages... if any of them require half an hour of work to investigate and answer, add it as a separate TODO in your list and finish checking the rest of the messages.
Energy-aware scheduling
I know all the analogies of this post are with CPUs, but we are not machines. We have peak performance periods and low energy periods. Forcing deep work on a complex problem during a low-energy period leads to burnout, so don’t get your expectations too high; you’re not a machine. Everyone has a high-performance time window. I know my energy is highest in the mornings. I use this time for the hardest problems and big rocks.
You will likely hit a plateau in the afternoon, especially after lunch. Your energy dips. At that point, switch to low-intensity tasks. You can review non-critical pull requests, update documentation, and solve small tickets. It’s like the brain is in low-power mode. You keep making progress on necessary items without requiring high intensity.
Don’t be too rigid. Change your approach depending on the constraints. Some days, I’ve been stuck in a meeting marathon in the morning. I’d end up exhausted if I tried fighting against it and trying to do complex work, rather than changing my approach and doing the important work at another moment. In those situations, just run some stuff in the background, like building code or running a deployment.
Aligning your internal energy, your external constraints, and your TODO list of work requires intentionality rather than rigid discipline.
When some company founders talk about work-life balance not being a thing and promoting concepts like “work-life harmony”, the point is that you become even more flexible. Instead of designing energy levels “at work” as I’ve talked in this post, you use the low period times to do things like picking your kids up from school or commuting. Then use other high-energy times for work, even if outside regular office hours. It’s easy for work to occupy your entire day, and it may work better to define a clear boundary where work ends, so be flexible about your energy levels, but with caution.
Conclusion
Once you design your task boundaries and state management, you move from being busy and exhausted to being effective and high-throughput. Treat your brain like the sophisticated processor it is.
Your brain isn’t a parallel processor, but that doesn’t mean that it has to block when a task blocks. You can have concurrency if you have good state management.
Productivity isn’t a discipline problem. It’s a system design problem.
🎁 Bonus: Big and small rocks
Start with the big rocks, fit the rest in between
🗞️ Other articles people like
👏 Weekly applause
Here are some articles I’ve read last week and liked:
Hungry Minds by Alexandre Zajac. My go-to source for finding content
The Product-Minded Engineer: The importance of good errors and warnings by Gergely Orosz . Treat your errors and diagnostics like core product features.
Death of the Coding Machine: The Archetypes Replacing It You Need to Know by Sidwyn Koh . Now that AI has commoditized raw code, your value lies in judgment.
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 :)
This lands because it reframes exhaustion as a coordination failure, not a discipline issue. When work constantly forces context loss, people spend more energy holding their place than actually making progress. Designing for save states is really about making it easier to pick things back up and keep moving forward.