How to stop context switching as a developer

Most developer context switching comes from three sources: chat and review pings, waiting on builds, and side quests you start yourself. Cut it with a one-line re-entry note before every stop, set times for checking chat, one protected focus block a day, and a paper list for side quests. On a Mac, Dayflow can show where the switches happened. A website blocker wins if you need something to stop them.

You open the editor at 9:40 with a clear plan: fix the pagination bug. Then a review request lands. You skim it and leave two comments. You notice a flaky test in CI, open the logs, and get pulled into a thread about the staging database. By 11:15 you are back in the original file, staring at a function you understood an hour ago, and you cannot remember which branch of the conditional you were about to change.

Nothing went wrong, exactly. Every switch looked small and reasonable at the time. But the day ends with a dozen half-finished things open in tabs, and “still on pagination” at standup feels like a confession.

This guide covers why switching costs so much when you write code and gives you seven things to try. Most of them need only paper, a timer or a short conversation. It ends with where an automatic record of your day fits and where it doesn’t. Disclosure: we make Dayflow, a free, open-source Mac app that comes up later. The details about it come from its own published documentation for version 2.2.0, reviewed in September 2026.

The short version

• Before you leave a task for any reason, write one line: the exact next step.
• Check chat and email at set times, not whenever a badge appears.
• Put one protected focus block on your calendar each day and tell your team what it is for.
• Keep a paper “later” list for side quests you spot mid-task, and don’t start them.
• Choose a small waiting task before you kick off a long build or CI run.
• Count your switches for one day so you know which source to fix first.

Why does switching hurt so much when I’m coding?

Programming asks you to hold a lot in your head at once: what the function is supposed to do, which values you have already checked, the hypothesis you are testing, the three files involved, and why the obvious fix won’t work. Almost none of that is written down. It lives in working memory, and working memory gets cleared when you turn to something else.

So the real cost of an interruption isn’t the two minutes spent answering a message. It’s the rebuild afterward. You reread code, retrace your reasoning, and sometimes redo a check you had already done because you no longer trust that you did it.

A few other things make it worse:

• Interruptions arrive at the worst moments. Pings don’t wait for a natural break. They land halfway through a thought, which is exactly when there is the most to lose.
• Unfinished tasks keep tugging. Many people find that a half-done review or an unanswered question sits in the back of their mind while they try to work on something else, so even the “main” task gets only part of their attention.
• Waiting is built into the job. Builds, test runs, deploys and code reviews all leave gaps. A gap feels like a perfect moment to check something quickly, and quick checks rarely stay quick.
• Many switches are self-started. When a problem gets hard, opening chat or a new tab can feel like relief. That is a normal human response to friction, not a character flaw.

None of this means you lack discipline. It means your work depends on fragile mental state, and the environment around it is full of things that knock that state over. The fixes below either cut the number of knocks or make recovery cheaper.

1. Count your switches for one day

Before changing anything, find out what you are dealing with. Keep a sheet of paper next to the keyboard for one working day. Each time you leave the task you meant to be doing, make a tally mark and add a letter for the cause: C for chat, R for review, B for build or waiting, M for meeting, S for self-started.

Illustration: at the end of the day your sheet might show 23 marks, with 9 S, 7 C, 4 B, 2 R and 1 M. That points to side quests and chat as the first things to fix, not meetings.

After a week: you don’t need to tally every day. Do it once now and once a week after you start trying the steps below. If the total drops or one letter shrinks, the change is working. If you want a rougher, faster estimate of where your hours go, the where does my week go calculator takes a few minutes. For more on reconstructing a lost day, see where did my day go.

2. Leave a re-entry note every time you stop

This is the cheapest habit on the list and often the most useful. Whenever you stop working on something, for a meeting, lunch, a ping or the end of the day, write one line saying exactly what you were about to do next. Write the next physical step, not a summary.

Put it where you will see it when you come back: a comment at the cursor, a sticky note on the monitor, or the top line of a paper notebook. A daily work log works too if you like keeping these in one place.

Illustration: “Fixing pagination” is a summary. “Check whether offset is reset when the filter changes, line 142 of list.ts, I think it isn’t” is a re-entry note. The second one gets you working again in seconds.

After a week: notice how long it takes to get going after a break. If you find yourself reading the note and starting immediately, instead of rereading the whole file, it’s working. If the notes are too vague to help, make them smaller and more specific.

3. Batch chat, email and notifications

Most messages feel urgent because they arrive with a sound and a red badge. Very few actually need an answer within minutes. Pick set times to check, for example at the top of each hour or after each focus block, and close or silence the apps in between.

Make this safe by telling people. A short note to your team helps: “I check chat roughly hourly. For anything on fire, call me.” Many teams already have an on-call rotation for true emergencies, which means the rest of the time you really can wait.

Illustration: a developer who used to glance at chat every few minutes switches to checking at :00 and :30. The first morning feels uncomfortable. By the afternoon they notice nothing in the backlog needed an answer faster.

After a week: compare your tally of C marks with your baseline day. Also ask whether anyone was actually blocked by the delay. If nobody noticed, you can probably stretch the interval. If one person kept getting stuck, give them a faster channel instead of dropping the rule.

4. Protect one focus block a day

You don’t need a perfect schedule. You need one stretch each day, usually 90 minutes to two hours, where the default answer to everything else is “after.” Put it on your shared calendar as a real event with a clear name, like “Focus: pagination fix,” so people can see it and plan around it.

If your days fill up with meetings, try to cluster them. A morning with two meetings an hour apart often produces no deep work at all, because the gap is too short to load a problem. Moving them back to back can free a whole block. If meetings are the main issue, the meeting cost calculator can make a calm case to a manager for trimming a recurring one.

Illustration: a developer blocks 9:30 to 11:30 every weekday, moves standup to 11:30, and asks that reviews be requested after lunch unless they are blocking a release.

After a week: ask whether at least three of those five blocks produced real progress on one task. If they keep getting eaten, look at what ate them. That tells you which conversation to have with your team. For a longer look at this kind of work, see our deep work review.

5. Park side quests on a paper list

A lot of switching starts in your own editor. You’re fixing one thing and notice a confusing variable name, an outdated dependency, or a test that looks wrong. “While I’m here” is how a 30-minute fix becomes a three-hour afternoon touching six files.

Keep a paper list labeled “later.” When you spot a side quest, write one line and go back to the main task. Paper is better than a new ticket for this, because creating a ticket is itself a small switch with its own fields and tabs.

Illustration: during the pagination fix, the list collects “rename tmpData in list.ts,” “why does utils/date have two parse functions,” and “flaky test user-export again.” At the end of the block, two become tickets and one gets done in five minutes.

After a week: read back the list. If most items still look worth doing, you saved yourself from interrupting real work to do them. If most look trivial in hindsight, you also saved the time you would have spent on them. Either way, your S tally should be dropping.

6. Decide what you do while waiting

Long builds and CI runs are where many developers lose the thread. The fix is to choose your waiting task before you start the wait, not during it. Good waiting tasks are short, low-stakes and close to the current work: writing the commit message, updating the ticket, sketching the next test case, or just reading the diff you’re about to push.

Bad waiting tasks are new problems and open-ended threads. They tend to outlast the build, and then you have two half-loaded contexts.

Illustration: before starting a 12-minute test run, a developer writes on a sticky note: “while waiting: draft PR description.” When the run finishes, the description is done and nothing else is open.

After a week: look at your B marks and think about what happened after each wait. Were you back on the main task within a minute of the build finishing? If yes, keep going. If waits still spiral, try making the waiting task even smaller, or simply stay with the code and reread it.

7. Keep one task in progress

Having three tickets “in progress” feels productive, but it guarantees switching. Every time one gets blocked, you jump to another, and each jump costs a rebuild. Agree with your lead or a teammate on a simple rule: one main task in flight, plus at most one small backup for when you are blocked.

Saying no to pulling a new ticket can be uncomfortable. It’s easier if it is a shared agreement rather than a personal stand. A short chat with your lead along the lines of “I’ll finish more if I carry fewer things at once” is usually well received.

Illustration: instead of picking up a new ticket when code review stalls, a developer pings the reviewer once, then works on the small backup task. The main ticket stays loaded in their head.

After a week: count how many tasks you finished versus started. If finished is catching up to started, the rule is working. If you keep breaking it, notice why. Often it’s a blocked review, which is a team process problem worth raising.

Where seeing your actual day helps

Every step above works better when you know what really happened, and memory is a poor witness. By late afternoon most people can’t recall when the morning went sideways, which is why the tally in step one helps so much. It also takes effort to keep up.

That is where Dayflow fits. It’s a free, MIT-licensed Mac app (macOS 14 or later) that records your screen at one frame every 10 seconds and has AI write the day into a readable timeline. You don’t start or stop a timer. At the end of the day you can see when you were in the editor, when you drifted into chat, and how long a “quick check” during a build actually lasted.

Recordings and the timeline are stored on your Mac. You can keep screenshot analysis on-device with a supported local AI model, send selected screenshots to your own cloud provider, or use the optional Pro plan at $20 a month, where Dayflow manages cloud analysis. The local and cloud processing page explains what goes where. You can export a date range as Markdown from Settings → Export, which helps with standups and remembering what you worked on. AI summaries can miss or misread work, so check them before sharing. More detail is on the product details page.

Dayflow publishes this article, so weigh that when you read this section.

Where Dayflow is the wrong pick

Be clear about what it won’t do.

• It doesn’t stop switching. Dayflow has no website blocking. If you need something that physically prevents you from opening chat or a news site during focus time, a dedicated website blocker is the better tool. Dayflow shows you what happened afterward.
• It’s Mac only. If you code on Linux or Windows, or split your day across machines, it sees only the Mac part.
• It sees only the screen. A tap on the shoulder, a phone notification or 20 minutes thinking at a whiteboard won’t show up the way they felt.
• It’s not a coach. It won’t tell you how to restructure your day. The steps above, and a conversation with your team, do that work.
• It has no team reports, invoicing or payroll. If you need to bill clients or report hours across a team, look at Mac time trackers built for that, or our list of the best time trackers for developers on Mac.

If interruptions mostly come from how your team works, no personal tool fixes that. The batching and focus-block agreements will do more.

The bottom line

Context switching costs developers so much because the valuable part of the work lives in your head and gets cleared every time you look away. You won’t eliminate switches, and you don’t need to. Cut the avoidable ones, like side quests, idle waits and chat checks on reflex. Make the unavoidable ones cheaper with a one-line re-entry note.

Start small. Tally one day, pick the biggest letter on the sheet, and try the matching step for a week. If you want to see your day without keeping the tally yourself, an automatic record can help. The fixes still come from how you set up your time.

Frequently asked questions

What is context switching in software development?

Context switching is moving your attention from one task to another, such as from debugging a function to reviewing a pull request, answering a chat thread, or checking a failed build. Each move means dropping the mental model you built for the first task and loading a new one. Coming back means rebuilding the first model, which is often slower and less complete than it was before.

How long does it take to get back into code after an interruption?

It varies with the task and the person, and nobody can give you a reliable number for your own work. A trivial edit may take seconds to resume. A deep debugging session can take much longer, because you have to rebuild the hypothesis you were testing. To learn your own pattern, tally your interruptions for a day and note how long each restart felt.

How do I stop getting interrupted on chat while coding?

Check chat at set times, for example on the hour, rather than whenever a badge appears. Turn off badges and sounds during focus blocks, and tell your team how to reach you for something truly urgent, such as a direct call. Most messages can wait an hour. The ones that can't usually need a different channel anyway.

Is multitasking ever fine for developers?

Pairing a demanding task with a mechanical one usually works, like letting a long test suite run while you tidy notes or update a ticket. Trouble starts when two tasks both need you to hold a detailed mental model at the same time, such as debugging one service while reviewing changes to another. Keep one deep task in flight and let the shallow ones fill the gaps.

What should I do while waiting for a build or CI run?

Pick a waiting task before you start the build. Good choices are short and close to the current work: writing the commit message, updating the ticket, or sketching the next test. Avoid opening a new problem or a long chat thread. Those tend to outlast the build and leave you with two half-loaded contexts instead of one.

How can I see how often I actually switch context?

The simplest way is a tally on paper for one working day, with a mark each time you leave the task you meant to be doing and a letter for the cause. If you would rather not track by hand, an automatic record of your screen, such as Dayflow on a Mac, builds a timeline you can review afterward without starting timers.

Can Dayflow block distracting websites or apps?

No. Dayflow does not do website blocking. It records what was on your screen and has AI write a timeline of your day. If what you need is something that stops you from opening a site or app during focus time, a dedicated website blocker is the better choice. Dayflow is a record you review, not a gate.

Does Dayflow work for developers on Linux or Windows?

No. Dayflow runs only on macOS 14 or later. If you work on Linux or Windows, or split your time across machines, it will only see what happens on your Mac. For a full picture you would need a tool that runs on your other systems, or a simple paper tally that works everywhere.

Is Dayflow free?

Yes. Dayflow is $0 and MIT licensed, and screen recordings and the timeline are stored on your Mac. You can analyze screenshots with a local AI model on your Mac or with your own cloud provider, which has its own charges and terms. An optional Pro plan at $20 a month has Dayflow manage the cloud analysis for you.