Topic
Developer Work
Developer productivity is not a generic to-do list. Code, reviews, builds, and debugging load different working sets. These pieces cover how to protect expensive concentration, separate pipeline green from finished work, plan Feature vs Review days, and leave branches pick-up-ready overnight.
Engineering work is ruined by interrupt culture that treats every ping as free. A context switch mid-debug can cost more than the meeting that caused it. Waiting on a build is not free time if it shreds the mental model you were holding. Fake busyness - open PRs as theatre, green CI as a substitute for verified outcomes - hides stalled delivery.
This topic is written for people who ship software: protecting deep work, using waiting time without losing the thread, sizing focus intervals to the test loop, and leaving handoffs that another developer (or future you) can continue without a walkthrough call.
Begin with the cornerstone guide on developer productivity without fake busyness. Use the related articles when debugging is shredded by interruptions, five small tickets cost more than one feature, or green builds keep getting celebrated while users see nothing.
Motion vs finished signals
Green dashboards and open PRs are easy to fake; finished work has checks a teammate or user can run.
| Signal | What you are seeing |
|---|---|
| Motion | Many small commits with no user-visible change, or CI green while staging was never exercised. |
| Finished | Behavior verified locally or in staging, with notes on edge cases someone else would hit. |
| Motion | Review requested on a diff the author cannot summarize in two sentences. |
| Finished | PR describes intent, test evidence, and rollback or follow-up if scope stayed intentionally narrow. |
| Motion | "Looking at" a bug with no repro steps captured for the next session. |
| Finished | Branch left pick-up-ready: current hypothesis, next command or file, and what would disprove the fix. |
What this topic covers
- Rejecting fake busyness metrics in favor of finished engineering work
- Protecting debugging and deep focus from cheap interrupts
- Working with long builds, uploads, and exports without losing context
- Leaving code and notes so someone else can continue
- Choosing focus lengths that match technical work