14 Personal Lean: Building habits

This chapter argues that personal effectiveness in software work is a Lean problem: developers often spend their best attention on interruptions, routine fixes, and low-value coordination instead of on the judgment-heavy work that compounds over time. The remedy begins with noticing where cognitive value actually goes, then using simple daily habits to capture context, track friction, and separate useful work from busywork. Rather than relying on willpower alone, the chapter frames personal improvement as a system that can be observed, measured, and improved one practice at a time.

A major theme is converting recurring mistakes into standard work. By writing checklists from real failures, keeping them short, and pruning items once automation takes over, a developer gradually turns fragile habits into reliable process. The same logic applies to learning: reading incident reports, extracting the underlying pattern, searching one’s own codebase for similar risks, and fixing the category rather than the one-off bug creates a durable feedback loop. In this model, failures become lessons, lessons become checklists, and checklists eventually become automation.

The chapter also stresses managing all forms of work in progress, not just tickets. Mentoring, reviews, meetings, and learning all consume cognitive space, so capacity planning must include them honestly or deep work will be fragmented and shallow. Finally, it argues that AI should be used as an accelerator anchored to specs and verification, not as a brittle dependency on tool behavior; as tools change, the stable part is the desired outcome, while prompts and workflows evolve around it. Over time, this discipline helps developers grow into broader, deeper practitioners who can combine domain expertise with a second area of strength and continuously improve their own system.

Where cognitive value gets spent versus where it compounds.

Pre-deployment checklist as a gate; each failed check stops the deployment before damage compounds.

The incident-driven learning loop: each cycle converts a specific bug into a prevented category of bugs.

The spec as the stable anchor in an AI-assisted workflow: the AI varies, the acceptance criteria don't.

The T-shaped developer has deep expertise in one discipline and broad working knowledge across adjacent ones.

From T to Pi, AI thickens the breadth and makes a second vertical realistic.

• The eighth waste operates at the personal level: skilled judgment spent on config fixes, flaky tests, and formatting reviews is talent that compounds nowhere.
• A cognitive value log, tagging what required your judgment versus what just consumed your time, reveals your personal eighth waste quickly.
• Personal standard work checklists prevent skilled developers from skipping steps under pressure.
• Learning loops turn incidents into permanent skill upgrades by extracting patterns from specific bugs and searching your own code for the same class of defect.
• WIP isn't just tickets; meetings, mentoring, learning, and team events all consume cognitive space, and a WIP limit that ignores them overloads the person
• Know when you do your best thinking and defend that time; teams that cluster meetings into specific windows create protected blocks where deep work is the default, not the exception.
• Documentation now serves two audiences: humans who skim and AI assistants that ingest.
• AI-resilient workflows treat the AI as an unreliable supplier and use specs as incoming quality checks, so model upgrades change the tool's behavior without breaking your process.
• AI evolves the T-shaped developer toward Pi: it thickens the breadth from awareness to contribution, makes a second vertical of deep expertise realistic, and compresses the ramp-up that used to make Pi-shaped developers rare.
• Your personal standard work guide is a living document that you follow today and improve tomorrow; a guide that never changes is a guide that stopped working months ago.

FAQ