• Who's Actually Out of a Job?

    Every decade has had a tool that promised software without developers. The hard part never moved. What AI actually makes cheap is the part managers thought was theirs - and engineers can do that part too.

  • Vibes Don't Maintain

    A friend built an app for his restaurant with Claude Code and asked me to host it. What he had was a click-dummy. The parts of software you can see are the cheap part. The parts you can't are the product.

  • XP Is More Important Now Than It Was Before AI

    AI coding tools make Extreme Programming practices more important, not less. When the machine writes the code, human judgment about what to build becomes the scarce resource.

  • The Spec That Runs

    Every team has two descriptions of what their software should do: the tickets and the code. Neither is authoritative. The spec that runs is - and most teams don't have one.

  • Stories Scale

    When the team is small, user stories are overhead. When it grows, they become the only reliable way to coordinate work without everyone stepping on each other.

  • Always Be Knolling

    Tom Sachs' knolling principle applied to software: scan for what's not in use, put it away, group like things, align everything. The discipline of leaving a codebase more organized than you found it.

  • Sacred Space

    Respect for space and tools is essential. Don't leave a mess. The way a team treats its codebase, its backlog, and its environment is the clearest signal of how seriously they take the work.

  • The Curse of the Clever Solution

    Clever code is satisfying to write and painful to read. The author spent an hour finding the elegant path. Every future reader spends an hour reconstructing it. Write for the reader.

  • Work to Code

    Creativity is the enemy of execution. You have a way of working already in place. New inventions should come from necessity, not from what interests individuals. Consistency compounds.

  • Cut Every Task in Three

    Prepare the task. Complete the task. Leave no trace. Most people only do the middle one. The other two are what separate good work from work that makes a mess.

  • Keep a List

    Not productivity theater. A prioritised list of tasks is your memory, your commitment, and your accountability system. It justifies your actions and records your past. Without it you are guessing.

  • Nobody in Software is self-taught

    Nobody in software learns alone. The self-taught developer story leaves out the Stack Overflow threads, open source codebases, and patient colleagues who filled the gaps.

  • Mentoring Is Leverage

    Mentoring isn't a cost senior engineers pay. It's the highest-leverage activity on most engineering teams. The math on compounding skill across a team is straightforward.

  • Stay Close to the Code

    The best engineering leaders stay close to the code. Drifting into pure management mode is how you lose both the technical judgment and the credibility that made you effective.

  • Make Something. Now You Have a Problem.

    Abstract planning loops indefinitely. Building something - anything - ends the loop. You can't know what you're actually building until you've started building it.

  • YOLO-Driven Development

    At some point the analysis has to stop and the building has to start. The case for committing to a direction sooner, shipping smaller, and letting reality tell you what's wrong.

  • It's Not About Writing Code

    The job title says software engineer. The actual job is mostly not writing code - and the sooner you internalize that, the better you get at the parts that matter.

  • Productive Procrastination

    Spending two hours on your editor config when you should be writing tests isn't always wasted time. The distinction between productive and unproductive procrastination is worth understanding.

  • Don't Hire the Smartest People. Hire the Laziest.

    Lazy engineers solve problems with less code, fewer meetings, and simpler systems. The hardest worker on the team is often the one creating the most unnecessary work for everyone else.

  • Everything Is Overengineered

    Pick any codebase at random and look carefully. You'll find abstractions for problems that don't exist yet and patterns applied where none were needed. Complexity is the default.

  • Never Force a Human to Do What a Robot Can

    Every manual step in your workflow is a context switch, an error source, and a slow leak of team morale. Automate the mechanical and keep humans for the parts that require judgment.