Deep work for developers by career stage

Individual contributors navigating different expectations for autonomy, scope, and interruptibility. Titles vary by company—treat the sections as shapes of work, not HR labels.

Uncertainty is the default: unfamiliar tooling, vague tickets, and a smaller library of “known good” moves. Depth is still possible, but the checkpoint should be smaller and more legible: reproduce the bug, document findings, add one test, or complete one tutorial slice.

• Bias to shorter blocks when you are still discovering the next step every few minutes.
• Write questions as you go—depth fails when you orbit silently.
• Prefer one narrow PR story over “touch everything.”

You can execute end-to-end, which means your calendar fills with “easy to ask you” work: reviews, help threads, and small fires. Depth breaks from parallel tickets and context debt more than from raw skill gaps.

• Cap WIP visibly—two active maker threads is often healthier than five.
• Batch reviews so they do not interleave inside compile-debug loops.
• Use longer blocks only when the ticket truly spans multiple subsystems.

Depth competes with design work: RFCs, tradeoff discussions, cross-team alignment, and risk reviews. The maker window may be shorter even when the problems are harder—because the day is legitimately multi-modal.

• Name modes explicitly: “design until 2pm, implementation sprint after.”
• Prefer fewer, larger checkpoints for cross-cutting changes—still one objective per block.
• Protect at least one weekly block where you are not the meeting owner.

Your job is often interruptible by design: unblocking others, interviews, planning, incidents. Depth still matters for the parts only you can do—risky migrations, performance cliffs, security-sensitive edits—but you must schedule maker time like infrastructure, not leftovers.

• Put maker holds where you would never skip a 1:1.
• Delegate or postpone “quick questions” inside those holds when culture allows.
• Prefer small, high-signal coding checkpoints over heroic all-nighters.

• One sentence checkpoint before the timer starts.
• One breadcrumb note when the block ends—see how to end a coding sprint well.
• One tab discipline policy for audio—see why instrumental music usually works better for coding.

Career stage changes the enemy: uncertainty, WIP, coordination, or calendar ownership. It does not change the winning move: fewer simultaneous objectives, believable checkpoints, and a defended window long enough to finish a thought.