Context Switching

Context switching is the silent killer of engineering productivity. It looks like work — you are busy, you are responsive, you are involved in multiple projects. But the output tells a different story. An engineer working on three projects simultaneously does not deliver three things in the time it takes to deliver one. They deliver one thing in the time it takes to deliver three, and all three are lower quality.

The Real Cost

Context switching has two costs that multiply each other:

Cost 1: Transition time
  Every time you switch tasks, you spend time:
  - Saving your mental state on the current task
  - Loading the mental state for the new task
  - Remembering where you left off
  - Re-reading code, notes, or messages to rebuild context
  
  Minimum transition: 5 minutes (trivial switch)
  Typical transition: 15-25 minutes (complex engineering task)
  Worst case: 45+ minutes (you were deep in debugging)

Cost 2: Reduced depth
  Even after the transition, you do not reach the same depth
  of focus. Part of your brain is still holding residue from
  the previous task. This is called "attention residue" —
  research by Sophie Leroy at the University of Washington
  shows it persists for 15-20 minutes after switching.

The combined effect is devastating:

Working on 1 project:
  Available focus: ~6 productive hours per day
  Depth: full
  Output: high-quality, consistent progress

Working on 2 projects:
  Available focus: ~4 productive hours per day (not 6/2 = 3 each)
  Overhead: ~2 hours lost to switching
  Depth: moderate
  Output: slower progress on both, more bugs

Working on 3 projects:
  Available focus: ~2 productive hours per day
  Overhead: ~4 hours lost to switching
  Depth: shallow
  Output: barely any progress, frequent mistakes, lots of "catching up"

This is not linear degradation. It is worse than linear because each switch taxes working memory, and engineering tasks have high working-memory demands.

Why Engineers End Up Juggling

Nobody chooses to context-switch constantly. It happens because of organizational dynamics:

Common causes:
  - "We need you on this too" (staffing pressure)
  - Urgent bug in production + feature deadline (competing priorities)
  - PR reviews for 3 different projects (collaborative overhead)
  - Meetings about project A between focus blocks for project B
  - On-call rotation during a feature sprint
  - "Can you just take a quick look at this?" (unbounded favors)

The root cause is usually that the organization values responsiveness and breadth over depth and completion. This is a management problem, but individual engineers can mitigate it.

Single-Tasking for Engineers

Single-tasking means working on one thing at a time, completing it (or reaching a clear stopping point), and then moving to the next thing. It sounds obvious. It is extremely difficult in practice.

Daily Single-Tasking

Instead of:
  9:00  Work on feature A for 30 min
  9:30  Switch to bug B for a PR review
  10:00 Meeting about project C
  10:30 Back to feature A, spend 15 min remembering where you were
  10:45 Slack question about bug D
  11:00 Meeting about feature A
  11:30 Try to work on feature A, give up, do email
  12:00 Lunch, demoralized

Do this:
  9:00  Focus block: feature A only (90 min, DND on)
  10:30 Communication batch: PR review, Slack, email (30 min)
  11:00 Meeting about project C (30 min)
  11:30 Focus block: feature A continued (60 min)
  12:30 Lunch, made real progress

The second schedule has the same meetings and obligations. The difference is sequencing: focus work is grouped, communication is batched, and each block has a single purpose.

Weekly Single-Tasking

When you are assigned to multiple projects, negotiate for temporal separation:

Bad: work on project A and project B every day
  Monday:    A morning, B afternoon
  Tuesday:   B morning, A afternoon
  (10 context switches per week)

Better: alternate days
  Monday:    project A all day
  Tuesday:   project B all day
  Wednesday: project A all day
  (4 context switches per week)

Best: alternate weeks or larger blocks
  This week:    project A
  Next week:    project B
  (1 context switch per week)

The larger the blocks, the deeper you can go. A full day on one project lets you reach a level of understanding that 4 hours never will.

Handling Urgent Interruptions

Single-tasking does not mean ignoring emergencies. It means having a protocol for them:

When interrupted during focus work:

  1. Assess urgency (5 seconds):
     Is this actually urgent? Does it need ME? Does it need me NOW?
  
  2. If not urgent:
     Acknowledge receipt, give a time estimate.
     "Saw this. I'll look at it at 11:00."
  
  3. If urgent and needs you now:
     Write down EXACTLY where you are before switching.
     Not "I was working on the feature" but:
     "I was in payment_service.py line 47, testing whether
      the retry logic handles timeout correctly. Next step:
      add a test for the 3-retry case."
  
  4. Handle the interruption.
  
  5. Return using your notes.
     Your written breadcrumb saves 15 minutes of "where was I?"

The key insight is step 3: writing a precise breadcrumb before switching. Most engineers just switch and trust their memory. Memory is unreliable, especially under stress.

Good breadcrumbs:
  "Debugging: the user's cart total is wrong. Traced to
   calculateDiscount(). The percentage discount is applied
   before the fixed discount, but it should be after.
   Next: write a test for the correct order, then swap the calls."

  "Designing: the notification system needs to handle 3 channels
   (email, SMS, push). I've drafted the email path. Next: define
   the interface that all 3 channels implement."

Bad breadcrumbs:
  "Working on the cart thing"
  "Notifications"

A good breadcrumb takes 30 seconds to write and saves 15-25 minutes of re-orientation.

Saying No to Context Switches

The most effective way to reduce context switching is to prevent it. This requires saying no, which engineers are often bad at.

Scripts for declining context switches:

"Can you help with X?"
-> "I can look at it at 3:00. Is that soon enough?"
   (90% of the time, yes)

"We need you on project B too"
-> "If I split between A and B, both will take twice as long.
    Which one should I focus on first?"
   (forces a priority decision)

"Can you just take a quick look?"
-> "I'm in a focus block until 11. I'll check it then."
   (protects the current block)

"This is urgent"
-> "What happens if we handle it in 2 hours instead of now?"
   (tests whether it's actually urgent)

The key is not refusing to help. It is negotiating timing. Almost nothing in software engineering is so urgent that it cannot wait 2 hours.

The Myth of Multitasking

Some engineers believe they are good at multitasking. Research consistently shows this is not true. What feels like multitasking is rapid task-switching, which has all the costs described above. The subjective feeling of productivity during multitasking is an illusion — people who multitask rate their performance higher than people who single-task, but actually perform worse.

"Multitasking" in engineering:
  What it looks like:  handling Slack, writing code, and reviewing a PR
  What is happening:   doing none of them well, switching every 3 minutes
  What it produces:    shallow code, missed review comments, slow responses

Single-tasking in engineering:
  What it looks like:  ignoring Slack for 90 minutes
  What is happening:   deep focus on one problem
  What it produces:    solid code, then a focused review, then thorough responses

Real-World Example: The Two-Project Engineer

An engineer was assigned to two projects: a database migration and a new API. They spent every day doing some of each. After 3 weeks, neither was done. The migration was 60% complete with several bugs. The API was 40% complete with design issues that needed rework.

Their manager let them focus on the migration exclusively for one week. It was done by Wednesday. They spent Thursday and Friday on the API, rethought the design with fresh eyes, and delivered it the following Tuesday.

Total elapsed time: 4.5 weeks when split. The estimate for sequential work: 3 weeks (1 week migration, 2 weeks API). Splitting the work did not save time. It added 1.5 weeks of overhead.

Common Pitfalls

Wearing context-switching as a badge of honor — "I'm juggling 5 things" is not impressive. It means none of them are getting your best work. Effective engineers focus.
Not writing breadcrumbs when interrupted — you think you will remember where you were. You will not. Write it down in 30 seconds and save 20 minutes later.
Accepting every "quick question" — quick questions are never quick. They break your focus, trigger attention residue, and cost 15+ minutes of recovery. Batch them.
Splitting the day between projects — half a day is not enough for deep engineering work. If you must split, split by full days or full weeks, not by morning and afternoon.
Blaming yourself for low output — if you have 6 meetings, 3 projects, and constant Slack interruptions, low output is not a personal failure. It is the predictable result of an environment designed for context-switching.

Key Takeaways

Context switching costs 15-25 minutes per switch, and the cost increases with task complexity. Three projects do not mean one-third speed on each — they mean one-fifth speed on each due to compounding overhead.
Single-task by grouping focus work into uninterrupted blocks. One project per block, one task per block. Batch communication separately.
When forced onto multiple projects, negotiate for the largest possible blocks. Full days beat half days. Full weeks beat alternating days.
Write precise breadcrumbs before any forced context switch. Thirty seconds of writing saves 20 minutes of re-orientation.
Most interruptions are not urgent. Negotiate timing instead of dropping everything: "I can look at it at 3:00" is almost always acceptable.