Project Ariadne.

The book

Contents

Six parts, thirty-one chapters, four interludes, an epilogue. Every chapter closes with a paragraph the book calls the thread — the idea compressed to something you can hold on to. All thirty-one are printed below, in full, so you can see exactly what the book claims before you buy it.

  1. Introduction · free to read

    The Thread

  2. Part I

    The Craft

  3. Chapter 1

    Simple Is Not Clever

    Complexity lives in the problem; complication lives in your solution — make every unit of the second pay rent against the first, at a rate your team can actually hold. Cleverness serves the writer, simplicity serves the reader, and the reader outnumbers you. Ask do we need this now? before you build, and extensible for what? before you generalize. Remember the payment machine: a masterpiece with one reader, most of the money still moving down the old paths beside it. Simple is not clever. Simple is what clever looks like when it grows up.

  4. Chapter 2

    Functions, Names, and the Cabinet

    Code is a cabinet: drawers inside drawers, every level labeled, so the structure does the remembering. Make the naming plan before the code, keep functions under twenty lines with ninety percent firmness, and let names be promises that report the whole truth — when the honest name is ugly, the design is confessing. Arrange every file like a newspaper. All of it serves one master: context is clarity. A reader who always knows where she is reads at full speed — and the reader, remember, outnumbers you.

  5. Chapter 3

    Code Never Lies (the Comment Wars)

    Code never lies; everything written about code can, because nothing in the toolchain keeps it honest. Never comment the what — the urge itself is a missing function asking to be born. Always be willing to comment the why: intent, evidence, the cliff someone already drove off. Documents are comments at scale; write answers, not novels. Trust flows to whatever is executed and tested daily. Spend your keystrokes where the truth lives.

  6. Chapter 4

    Leave It Better Than You Found It

    There is no later — quality lives inside the daily work or nowhere. Leave every file a little better than you found it, and make that a team policy, because entropy already is one. Borrowing is legitimate; invisible borrowing is not. Distrust the heroic rewrite, trust kaizen, and when the pressure comes, say the two-letter word with the costs on the table. Your code is tomorrow’s speed limit. Set it on purpose.

  7. Chapter 5

    Code Blindness

    Familiarity doesn’t sharpen your sight; it replaces it — you see five percent of the familiar and your memory paints the rest, and after about three years the beginner’s view is gone for good. You can’t cure that; you compensate, like a sailor with a known compass error: harvest every newcomer’s sighted weeks before you teach her to stop seeing, grade your systems on a calendar, and map your direction so drift becomes data. Trust your experience for speed. Fly on instruments for truth.

  8. Interlude I

    My World Was a PlayStation

    An interlude: notes from the margins, about why any of this is worth doing.

  9. Part II

    The Machine

  10. Chapter 6

    Smaller Everything

    Nobody at Ariadne questioned the batch, so everybody paid it. The whole history of software is one trend that never reverses — everything gets smaller — because small is fast feedback and small is honest. Chunks you can review in a glance, cycles short enough that being wrong is cheap, products scoped to the question they answer, teams small enough to share one brain. Smallness relocates coordination rather than abolishing it; the next two chapters are the machinery that pays that tax. The size of the bite was always the problem. Take smaller bites.

  11. Chapter 7

    Every Change Is Releasable

    The runbook was a document, and documents lie, so convert the process itself to code: a pipeline that is the deployment, tests that guard what matters, environments generated from descriptions that cannot drift. Keep every change releasable, so “can we ship?” stops being a question and fear leaves the building. Decouple deploying from releasing, and let work flow piece by piece until releases are heartbeats instead of surgeries. The ceremony was never the safety. The machinery is the safety, and the machinery, unlike step nineteen, runs every day and cannot forget.

  12. Chapter 8

    Kill the Dependencies

    Too many dependencies will kill you — not dramatically, but the way Ariadne died: an expensive organization converted into queue time, one man’s inbox setting the speed of the whole. A dependency is a queue; queues compound; toll booths create convoys, which is why your batches won’t shrink no matter how much you believe in small. Chase independent deployability, not small services; autonomy, not uniformity. Keep the dependencies you choose, visible and priced. Kill the ones you merely inherited — before the default wins again.

  13. Chapter 9

    Continuous Culture

    A machine that ships continuously but improves occasionally is half-built. Improvement items are work items, with doers and dates, or they’re stationery; the technical system gets a seat at the retro; mob on what one head holds hostage; make learning legitimate and scheduled. And watch the direction of travel: the better the machine gets, the less the ceremonies hold up. Keep the appointments, kill the liturgy. The sticky note attended thirty retros. A doer would have needed one.

  14. Interlude II

    Material Things Are Small

    An interlude: notes from the margins, about why any of this is worth doing.

  15. Part III

    The People

  16. Chapter 10

    The Job Is People

    Below every technical failure, two humans and a silence. A team is one brain in several skulls: its intelligence is the parts times the bandwidth between them, trust is the protocol, and when you know something, you help — hoarding is brain damage you choose. Distance is a tax you pay deliberately or pay in silences. The code is where the people-problems surface. Debug them where they live.

  17. Chapter 11

    Psychological Safety and the North Star

    Three people knew, and the team had taught them all the same lesson: silence is cheaper. Two conditions govern a team’s transmissions: safety, which decides whether people speak, and clarity, which decides whether the speaking aims anywhere. Make the goal a North Star people actually steer by, push authority to where the information lives, and hold it in structure strong enough to kill ambiguity and light enough to skip the surveillance. Open the valves, point the team, and get out of the way.

  18. Chapter 12

    Rituals That Work

    The napkin beat three meetings because information flows between humans in the unstructured hours, so engineer the unstructured hours. Rituals are chosen habits that pay, audited by output; ceremonies merely occur. Grant every ritual, including these, only as much tenure as its results buy. The soft things are the infrastructure. Budget for them like it.

  19. Chapter 13

    Welcoming the New

    Onboarding is culture made visible: the newcomer reads your real values off your first-week behavior, so choose the lesson. Show the business before the build system — why compounds, how merely accumulates. One named human, a one-page path through the fog, a first deploy worth remembering, and guides proud of becoming unnecessary. A generous man at the next desk made me an engineer in a month; a company that skipped him unmade a roomful. The hire you celebrated in the offer letter is decided in the ninety days after the laptop arrives.

  20. Chapter 14

    Conflict Without Yelling

    Conflict is fuel; contempt is fire in the building. Argue at full intensity about the work, never at a person, because a yell transmits nothing but rank and reprices every future act of honesty for everyone watching. Expect the chimp and never let it publish. Disagree at whiteboard prices; spend appreciation in public; embrace your faults out loud and let the team get rich on the example. Merciless about the work, unconditional about the people. That’s the whole trick.

  21. Chapter 15

    Cohesion Is the Multiplier

    Chemistry is the multiplier on everything a team builds, and I will not pretend the paper-perfect team that never connects is anything but a loss. But resemblance is chemistry’s cheapest source and its trap: comfort agrees fast and errs in unison, and “fit” launders bias hire by hire. Hire for the capacity to connect, never for the resemblance that fakes it, then build the cohesion ritual by ritual. Never field a team that can’t connect. Never let “connect” mean “looks like us.” Both failures lose — one of them just loses in silence.

  22. Chapter 16

    Knowledge Doesn't Live in One Head

    The business is too big for one head, and knowledge left alone doesn’t spread — it concentrates, groove by groove, until the team has built a single point of failure and named him employee of the year. So distribute on purpose: a vault for everything that can be written, question-shaped and demand-grown; and for the rest, the only way tacit knowledge moves — through people, rotating, in pairs. Stefan’s handover was eleven pages. The team’s memory should never have fit in eleven pages — and never, ever in one head with cake at the end.

  23. Interlude III

    Harmony With Nature

    An interlude: notes from the margins, about why any of this is worth doing.

  24. Part IV

    The Process Heresy

  25. Chapter 17

    The Ceremony Problem

    I hold the credential and nobody ever asked, because the industry adopted the meetings and abandoned the meaning: a generic calendar welded onto a craft it never mentions, and a vocabulary everyone speaks and nobody shares. Audit the ceremonies one by one and what survives is an estimate that measures the room’s mood and a timebox that dams a river we spent twenty years teaching to flow. Honor what Scrum killed. Then count the hours like the treasury they are. The certificate stays in the drawer. The hours, I want back.

  26. Chapter 18 · free to read

    When the Going Gets Tough

    A method is what it does under load, and Scrum’s most honest output is the sentence every team eventually says — drop the process, let’s just fix this — uttered with relief at the exact moment the work turns serious. Then one word meant five things to five teams, and I saw I’d been prosecuting the wrong defendant. The reason is people, and people don’t pause for the sprint. The tensions aren’t obstacles to the work. They are the work.

  27. Chapter 19

    Full-Stack Is a Utopia

    We declared every team cross-functional and kept a man who could touch only the database. The universal full-stack engineer is a utopia; a team can still be whole, because wholeness is the group’s combined coverage, not each person’s. So change the unit — one feature, one person, end to end, specialists consulting instead of gating — and organize per project, not per stack, so Conway’s Law works for you instead of against you. The seam is hard because deciding is hard. So let’s finally talk about deciding.

  28. Chapter 20 · free to read

    Decision-Making Is King

    The day I did nothing was not a dependency problem. It was a decision void, and the void is what kills projects: the bottleneck in software is almost never the code, it’s the choices no one will make. There is always a leader; flatten the chart and power goes underground, so name it. Treat the decision system as architecture, put the decider inside the team, and sort the reversible from the irreversible before you move. Decision-making is king. Everything else is logistics. Now — who should the king be?

  29. Chapter 21

    Don't Put an Engineer in a Suit

    We reward great engineers by removing them from engineering and call the double loss a promotion. Stop putting your engineers in suits; build a ladder that lets them rise without leaving the craft. Make the decider of what a senior developer who understands how, keep everybody in the code, and choose them for personality as much as skill. I asked who the king should be. The answer: someone still holding a keyboard, who never had to put on the suit to be allowed to lead.

  30. Chapter 22

    A Framework for Gutsy Engineers

    Not a new liturgy — ceremonies can’t answer a human problem — but a thread for engineers gutsy enough to run their own process: grow it from felt pain, start coding and let the patterns show themselves, make who-decides the spine, shape the work by its own stages, make the pieces of a big system talk before you make them rich, automate everything that isn’t the point. And over all of it, no dogma — not even this. Frameworks don’t ship software. Doers do. Be one.

  31. Interlude IV

    Everything Goes to Shit

    An interlude: notes from the margins, about why any of this is worth doing.

  32. Part V

    Designing & Deciding

  33. Chapter 23

    Start With Why

    We built the replacement system properly and it went from repository to nowhere, because the only unfixable code is the code that works perfectly and should never have existed. Start with why — the question no pipeline asks by default. Learn the domain, because the why lives there, not in the ticket. Then hold the why loosely enough to test it: ship the smallest real thing and let reality answer “should this exist?” before you spend the quarter assuming. The replacement system passed every test in this book except the first one.

  34. Chapter 24

    Build to Throw Away

    The most expensive prototype costs years, because it was built to die and someone let it live. A prototype is an instrument whose only output is learning, so build it for speed, not survival: hit the database direct, skip the cleverness, use the tools you already know. Keep two or three seams — handholds for the throwing-away. And declare which kind of code this is, out loud and in writing, because “it already works, why rebuild?” is coming, and that decision gets made either way. Build to throw away. Then actually throw it away.

  35. Chapter 25

    Never Trust the Client

    Nobody could hand me the do-not-call rules, because nobody had them in the shape code needs — and software built from what clients say implements their contradictions faithfully, lawsuits included. Distrust the client’s data, distrust the client’s stated solution, and trust the client’s lived problem absolutely. Care transmits: a developer’s joy becomes the user’s joy by the concrete mechanism of attention paid, and speed is that care with a stopwatch. Never trust the client’s keyboard. Trust their Tuesday completely.

  36. Chapter 26

    Your Mind Has Bugs

    The stress-test Friday had perfect machines and a broken room: exhausted people pattern-matching recoveries onto a situation that differed in exactly the part they didn’t look at, with no one owning the next move. Checklists against familiarity; scrub in before what can’t be undone; complex before complicated; nothing irreversible while tired. The instrument doing all your judging is your own mind. Learn its bugs like you learned your language’s. Now let’s go build that instrument.

  37. Part VI

    The Developer's Self

  38. Chapter 27

    Effectiveness Before Efficiency

    The payments company had all the velocity in the world and never once checked the direction, and I spent my last months there impeccably efficient at work that didn’t matter. Speed in the wrong direction is worse than useless — it carries you further, faster, with more conviction. Ask “the right things?” before “things right?“, every day, in that order. Then be fast. Just never let the running disguise the fact that you forgot to choose where you were going.

  39. Chapter 28

    Defend Your Attention

    I was available for nine hours and built nothing. Software is made of sustained attention, not of hours or typing, and the modern workplace is a machine for shredding it. Kill the notifications — the urgent will find you. Set the psychic weight down in one place you trust. Work in blocks. And hold it as rhythm, not walls, because sometimes the work that matters is the person trying to reach you.

  40. Chapter 29

    Monday Vision, Friday Reflection

    There are years I can’t account for — not lost to hardship but to drift, which is being extremely busy with no aim. The cure is a rhythm: three outcomes at three horizons, ten honest minutes on Monday and ten on Friday, the five-year game once a year, every goal forced down to one written sentence. Hold it lightly; the planning serves the doing. Direct your years, or they will pass through you. I have the missing ones to prove it.

  41. Chapter 30

    Know Your Shit, Forever

    Two engineers, ten years in: one with ten years of growth, one with one year repeated ten times, and in a field where the ground moves under you, that gap is the whole game. Two deliberate hours a week, at the edge, for a decade. Mine your own wreckage and read everyone else’s for free. Turn off the TV. Start before you’re ready, and when momentum arrives, go. Know your shit — and then keep knowing it, because “your shit” keeps changing, and so, if you’re doing this right, do you.

  42. Chapter 31

    Keep Your Shit Together

    Everything in this book runs on one piece of hardware — you — and the most optimized engineer in the world is worthless if they’ve destroyed the self the optimization was for. Push hard in the real seasons; just never call a permanent sprint a life. You are the instrument every other chapter plays. Keep it whole.

  43. Epilogue

    A Last Word: Out of the Labyrinth

The appendices

The book once ended with three appendices. Two of them were advice about interviewing, and one was about web performance — and all three had the same problem: they go stale. Interview norms move, and the performance appendix said so about itself, in its own text, asking the reader to refresh its numbers.

So they left the book and became field notes: maintained, dated, and correctable. What stayed in print is the part that will still be true in 2040.

  • Appendix A — The Interview, From Both Sides → field note
  • Appendix B — The Whiteboard Method → field note
  • Appendix C — Make It Fast → field note