How to recover focus after interruptions while coding on Mac, for developers

What losing time after interruptions costs you

A typical loop goes like this. You trace a failing test in Cursor. A Slack message lands, and you answer it. Then you switch back to the editor and spend several minutes working out which function you were in and why the test failed.

The reply was quick. The rebuild is the slow part. While you code, you hold call chains, variable names and the next check in your head. An interruption pushes some of that out, and most of the lost time goes to getting it back.

How often developers get interrupted

Microsoft's 2025 Work Trend Index says people using Microsoft 365 are interrupted about every two minutes during core work hours, or 275 times a day. Microsoft counts meetings, emails and chats as pings. Its methodology says the 275 figure is based on the top 20% of users by ping volume, while the body text reads more broadly. Treat the number as a sign of scale, not a benchmark for you.

The same research surveyed 31,000 knowledge workers across 31 markets. Nearly half of employees, 48%, said their work feels chaotic and fragmented. One in three said the pace of work over the past five years made it impossible to keep up. If your day feels cut into pieces, you share that feeling with a lot of people.

What the research says about resuming coding work

The most useful study for developers is Parnin and DeLine's CHI 2010 paper, Evaluating Cues for Resuming Interrupted Programming Tasks. They surveyed 371 programmers. Most relied heavily on note-taking when they picked up interrupted work.

In their lab study, developers who used an automated cue completed tasks with twice the success rate of developers who only took notes. Developers also preferred a chronological cue that shows past activity as code snippets. That points to what good recovery looks like. It shows the trail you walked, not a summary of it.

Why the 23-minute refocus number is shaky

You may have heard that it takes 23 minutes to refocus after an interruption. The number spreads fast, and it is shaky. A secondary analysis says the 2008 CHI paper by Mark, Gudith and Klocke, often cited for it, does not contain the figure at all.

The closest published figure comes from Mark, Gonzalez and Harris at CHI 2005. Their paper reports an average of 22 minutes 37 seconds. That measures time to return to a project, not recovery of concentration. Secondary write-ups even disagree on the 2005 number, so check the paper itself before you quote it.

Gloria Mark's website says attention on a screen averages 47 seconds, and that it is shrinking. The page names no study or year. Use it as a teaching line, not a measurement, and do not plan your week around it.

A worked example: one interruption, step by step

Say you are mid-refactor in VS Code. A teammate pings you in Slack with a question about a deploy. You answer, then you come back. Here is what a resume note changes.

1. Before you reply, jot a resume note in a scratch file: 'Stopped in billing/invoice.ts. Rounding test fails on zero-amount lines. Next: check the tax helper.'
2. Reply to Slack in one line. Do not open a second round of the thread.
3. Read the note, then open the failing test.
4. Run only that test first, before the full suite.

Without the note, your first minutes go to hunting for your place. With the note, the first minutes go to the fix. Nothing here is complicated. The note moves the rebuild work onto paper, where it is quick to read.

Set up Focus on Mac so alerts wait

Open System Settings, then click Focus in the sidebar. You can create up to ten custom Focuses. Make one called Coding and keep the rest for personal time.

Apple's guide says a Focus can turn on by time, by location, or by app. A time schedule matches your calendar. An app trigger fits when you want the block to start the moment you open the editor. Pick the trigger you will actually follow.

Focus Filters change what you see while a Focus is on. You can show selected calendars, selected Mail accounts, a People List in Messages, or a Tab Group in Safari. Start with Mail, since it is the easiest thing to glance at by reflex.

For a one-off block, use Control Centre and turn on Do Not Disturb. It silences all notifications at once. Turn it off when the block ends, or it will quietly hide messages you need later.

Match each interruption source to a setting

Slack: pause, schedule and use /dnd

On Slack's desktop app, click your profile picture, hover over Notifications, and choose a time frame or Custom. Select Resume notifications when you want them back. For a standing schedule, open Preferences and find Working hours. The Allow notifications menu offers Every day, Weekdays, or Custom.

The slash commands are faster when you are already typing. /dnd for 15 mins silences notifications for a short block. /dnd until 17:00 holds them until a fixed time. /dnd off ends it early. A workspace admin's default schedule gives way to your own, so the setting is yours to change.

Write a resume note that takes under a minute

A good resume note names the file, the symptom and the next step. For example: Stopped in auth/session.ts. The refresh test fails only when the clock mock runs first. Next: check the order of setup hooks in the test file. You can read that in a few seconds, and it points you at the code.

Keep the note where you will see it. A scratch file in the project works. So does a TODO comment that you delete later. Parnin and DeLine found that automated cues showing recent activity helped more than notes alone. You can copy the idea by keeping a running list of the commands and files you touched.

Mistakes that eat your recovery window

• Muting Slack, then checking it every few minutes anyway. The alerts are gone, but the habit stays.
• Writing a note that says fix the bug. A note needs a file, a symptom and a next step.
• Rereading the whole file to find your place. A good note makes that search unnecessary.
• Jumping to email or a tiny task to dodge the hard part. The small win feels good, but it resets nothing.
• Turning on Focus all day and never checking whether it helps. Schedule it, then review it after a week.

Most of these mistakes come from trying to stop interruptions with willpower. A setting you change once holds up better than a promise you make each morning.

Where Lazur helps, and where it does not

Lazur is a voice assistant for the Mac that lives in the notch. Hold ⌥⌘ to ask about anything on screen, and Lazur answers out loud. Ask where a control is, and Lazur draws a circle and a label around it. Ask how to do something, and Lazur guides you one click at a time, waiting for each click.

For interruptions, three parts are useful. Hold fn to dictate a resume note at the cursor in any app, so you speak it instead of typing it. Ask out loud what an error on screen means without leaving your editor. Ask how to set a Focus Filter, then follow the steps. For the wider set of developer tasks, see the developer page.

Lazur does not click buttons or operate other apps for you. It does not restore your editor, your open tabs or your place in a file. It keeps a memory of what you asked and did, on the Mac. Dictation is unlimited on both paid plans, but AI actions are capped by plan, so check pricing before you rely on it every day.

Measure your own recovery time

Read your interruption log at the end of the week. Look for the source that shows up most often and the one where you lost the longest time. Those two are rarely the same. Ask of each one whether it needed an answer right away. Most will not.

Regulated and client code: check the rules first

If you write code for clients, patients or regulated data, your employer's rules come first. Check them before you paste code, screenshots or dictated notes into any AI tool. Lazur listens and looks only while you hold the shortcut. Audio and the screenshot go to AI providers to answer, and they are not stored. Your employer's policy may still say no, and that answer wins.