Managing Time and Energy as a Senior Engineer: Deep Work, Context Switching and Burnout

The higher up you go, the less time you actually spend coding deeply. Meanwhile, expectations for technical quality go up.

Few people say that paradox out loud. A Senior Engineer’s day gets torn apart by code reviews, answering teammates’ questions, sync meetings, and mentoring. Every one of those matters. And every one of them competes for time with the hardest part of the job.

The higher you go, the less time for deep coding

Picture a day with no plan. You start at 9, check Slack, answer a few questions. At 9:30 you join a 30-minute sync meeting. At 10 you get back to code for 20 minutes and someone asks about a production bug. At 10:30 you pick the code back up and get interrupted by a review request that needs to be done urgently. By 11, you realize you haven’t actually gotten into flow once.

The problem isn’t having too much work. It’s that there’s no block of time long and continuous enough for your brain to get into deep focus.

Take redesigning the data sync flow between the booking service and the payment system. You can’t solve that in scattered 15-20 minute pieces. It needs at least 90 continuous minutes for your brain to load enough context before it starts producing real insight.

That day plays out in exactly this order:

timeline
    title A day with no plan
    9:00 : Start work<br/>check Slack, answer a few questions
    9:30 : 30-minute sync meeting
    10:00 : Code for 20 minutes<br/>then someone asks about a production bug
    10:30 : Back to coding, interrupted<br/>by a review request needing to be done urgently
    11:00 : Still haven't gotten into flow once

What context switching costs

Every time you’re interrupted in the middle of a highly focused task, you lose the time of the interrupted task itself. That’s not all. You also lose another stretch reloading the context: the whole mental model of the problem you were solving, the variables, assumptions and logic branches you were weighing. You have to finish loading it before you can work as effectively as you did before the interruption.

The feeling of “so many meetings today and I got nothing done” isn’t wrong. Total meeting time might be only 2 hours. But it breaks up 2-3 potential deep-work blocks, each of which would produce more value than the 2 hours of meetings combined.

People who manage their energy well don’t refuse every meeting. They deliberately cluster the shallow work together, then keep the rest of the time for deep work.

How I block out the calendar for deep work

A few concrete rules I follow:

• A fixed golden window: pick 2-3 hours a day, usually early morning before Slack and email get noisy, and mark it “busy” on the calendar like a real meeting. Nobody gets to book over it, including me.
• Batch shallow work: push replying to messages, small code reviews and ticket updates into 1-2 fixed slots a day, say 11:00 and 16:00. Don’t handle them the moment a notification appears.
• Turn off notifications when you start deep work. Not out of irresponsibility. A genuinely urgent production bug rarely happens, and teammates know how to call you directly if it truly can’t wait.
• One thing at a time: in a deep-work block, open a single problem only. If you spot a side issue while working, note it down to handle later, and don’t jump to it right away.

When I was building the backend for the booking system at SmileViet, the most complex workflows were nearly impossible to design correctly with only 20 free minutes between two meetings. Take redesigning the saga for tour booking with several compensation steps: hold the seat, process payment, confirm, roll back on failure. Those designs always came out of a strictly protected deep-work block.

Does mentoring have to fight with deep work?

Many people think the less you get asked, the more productive you are. Not quite. Mentoring is a core responsibility of a Senior, not something that competes with deep work for time. The issue is when it happens, not whether it happens.

What I do: set fixed office hours every day, for example 15:00-16:00. Teammates know that’s the best time to ask questions, pair-program, or do a deeper review together. The number of surprise interruptions during deep-work hours dropped sharply. Teammates also have a clear expectation, instead of guessing when you’re free.

Put together, a day with deep work looks like this:

flowchart TD
    S["Early morning<br/>2-3 hour golden window"] --> DW["Deep work<br/>one single problem, notifications off"]
    DW --> B1["11:00 - batch shallow work<br/>messages, small code reviews, tickets"]
    B1 --> OH["15:00-16:00 - office hours<br/>questions, pair-programming, deep reviews"]
    OH --> B2["16:00 - batch shallow work"]

Early signs of burnout

Burnout doesn’t arrive suddenly. It builds up gradually, and it often gets ignored because you keep “getting things done” for a long time before you really collapse. A few early signs I watch for in myself:

• Less interest in technical problems you used to find fascinating. A hard problem no longer makes you curious, it just makes you tired.
• Decision quality slowly sliding: you often pick the “just get it done” solution over the right one, even though you know the difference well.
• Trouble sleeping even when your body is tired. Your brain keeps “running” work long after you’ve left the keyboard.
• Irritability over small things that normally wouldn’t deserve your attention.

Lasting over the long run, not a week of leave

“Take a week off and come back exactly the same” doesn’t solve anything. You have to fix the structure of your daily work so you don’t land in a constant overload state.

• Keep a clear boundary between work hours and rest hours. Turn off work notifications outside the agreed hours, except in a truly urgent situation.
• Periodically look at the workload you’re carrying, and talk to your manager proactively when it goes past what’s sustainable. Don’t quietly grit your teeth until you burn out.
• Set aside time for activities that have nothing to do with a screen: walking, exercising, reading paper books. Your brain needs a real break, not a move from one screen to another.

Energy management isn’t a “soft” skill separate from technical work. An exhausted Senior Engineer will make worse architecture decisions than a Middle Engineer who’s still sharp. And those decisions stay in the codebase far longer than the tiredness does.