A complete, practical guide to the method — taught through two fully worked examples, because the examples are what make it land.
The method matters, but the two worked examples in Part 6 are the heart of this document. One is an argument handbook — the question of whether software engineers are going extinct. The other is a technical handbook — using Claude Code to build an AI simulation game. Everything before Part 6 is the setup; the examples are where you see exactly what "good" looks like, beat by beat. If you only internalize one thing, internalize those two.
Writing is high-leverage, and it's genuinely enjoyable once you're inside it. It feels like thinking out loud with the volume turned up. That matters, because handbooks are long-form, and the ones that get finished are the ones the author didn't dread.
A good handbook pays you back in more than one way. It is not a single-use asset. One artifact returns value along several axes at once: it establishes your authority; it represents your brand the way you actually want it represented — personal or enterprise; it compounds your reach as it gets found and shared for years; and it sharpens your own thinking, because you can't write clearly about something you only half-understand. The return is not linear — one focused effort pays you in authority, brand, reach, and clarity.
The topic matters far less than people assume. You can write about almost anything. What separates a handbook that transfers real knowledge from one that doesn't is never the subject — it's the rigor of the process behind it.
The biggest mistake is writing straight out of your own head, assuming what you know is enough and current. It usually isn't — and you can't tell from the inside that it isn't.
Get your knowledge current first. Your existing knowledge might be excellent, and you still have no way of knowing whether it's up to date. Fields move, tools change, the consensus shifts — and none of that announces itself. Confidence is not currency. So before you write a word, go read: the research papers (primary sources, not summaries), other handbooks and books to see where the gaps are, talks and videos where practitioners say what they actually think, and what credible people are saying right now. This does two jobs — it verifies and updates what you know, and it exposes your own mistakes and gaps so you can fix them before you teach anyone. Read, catch up, stay open, then write.
Get it from other people, too. Don't work entirely in isolation — other people see what you're too close to see.
Name the open question. A strong handbook is built around something genuinely unresolved, where the reader actually wants the answer — often a fork like will this replace what we do, make it outdated, or neither? You name the question, gather the evidence, and let the evidence decide where you land.
Clarify where you stand. Once you've caught up, decide your thesis. You can't write with conviction if your own view is still mushy.
The next thing you produce is not chapter one — it's the introduction, the outline, the gist, and above all the table of contents, which is the skeleton. Build it as a clean nested hierarchy — main bullet, mini-bullet, sub-mini-bullet:
1. Main point
1.1 Sub-point
1.1.1 Detail
1.2 Sub-point
2. Main point
2.1 Sub-point
When the structure is right, writing stops being intimidating: you're no longer staring at a blank page, you're filling in a numbered list you built yourself, one point at a time, in order.
A handbook can be 2,000 words or 20,000 words — both are legitimate. The long, comprehensive ones take a reader all the way through a subject; the short, concise ones are a leaner, newer format with real value for a focused topic. But be honest about what the length delivers. A 2,000-word handbook and a 60,000-word handbook cannot transfer the same amount of knowledge — a short piece is inherently limited in how much it hands over. Don't mislabel a concise piece as a comprehensive one. Match the claim to the real substance, because knowledge transfer is the entire point.
Work through the handbook one chapter at a time, following your table of contents. Go point by point, and don't skip — what's obvious to the author is often exactly what the reader needed spelled out. Hit each point cleanly; that discipline is what separates a handbook that teaches from one that just gestures at a topic. And keep it good and technical — depth earns the reader's time, and earns you the brand return.
Here is what the method actually looks like when written out. These two examples are the impact of this entire guide. Study how concrete and how opinionated each one gets.
This is the archetype where you take a contested question and reason your way to a grounded conclusion. Watch the five beats.
Are software engineers becoming outdated? Are they on their way to extinct? Do you even need passion for this anymore? Do you need any real talent — any real brain — or has all of that been automated away?
Open by sitting inside the confusion honestly. The reader has heard both "engineers are finished" and "engineers have never been more valuable," and they don't know which is true. Don't rush past that. Show them you understand why the question is genuinely open before you give them your answer.
Map the landscape before planting your flag. What is this credible authority saying, what is that one saying, where do they disagree? Pull in what you read while gathering — the papers, the practitioner takes, the loud predictions. You're showing the reader you've actually looked, so that when you do take a position it reads as informed rather than reflexive.
Now divide off your own view and mark it clearly as yours:
In our experience, software engineering is far more than writing a simple line of code. And yes — a simple line of code is easy. The entry-level surface of the work is easy, and it's getting easier every month. But that's the whole trap in the argument. The moment you stop writing simple lines and start facing genuinely hard problems, the entire curve plateaus. And at that plateau, it does not matter what shortcuts or tools you have — you still need real experience, real judgment, and the ability to actually drive a hard problem to a correct, finished solution. The tooling carries you across the easy part. It does not carry you across the hard part. That's the part where engineering actually lives.
Give the opposing view a real, fair hearing — not a strawman:
The strongest version of the other side goes like this: AI agents can simply handle all of it. You don't need software engineers anymore — you describe what you want, the agent builds it, and the human in the loop is a formality on the way out.
Lay that out at full strength, take it seriously, and only then answer it. A handbook that refuses to engage the best version of the opposing case reads as propaganda, and the reader feels it.
Bring it home with two kinds of evidence working together.
First, the research and credible sources. You've read the papers — for a good long while. You can point to reputable institutions: universities with real track records, thousands of students, serious research programs that have actually studied this. Make those citations real, not decorative. They're reputable, they've done the work, and that's exactly why they carry weight.
Then, your own experience, layered on top:
And here's what I know from doing the work: writing a genuinely good line of code still takes an enormous amount of brainpower. You still have to be able to read the research papers. You still have to actually know the code. You still have to know the basic, core tools. None of that has gone anywhere.
So the conclusion lands with force:
In our opinion, and from our experience, software engineers are not going extinct. What actually happened is narrower and more precise than the doom narrative: the entry got easier, but the S-curve did not change shape. The bottom of the curve — the easy tier — got dramatically easier to reach. But the steep, hard part of that S-curve is still just as steep, and the hard tier is still a very hard thing to run. The barrier to entry dropped. The ceiling did not move.
That distinction — easy tier got easier, hard tier stayed hard — is the entire payload of the piece. Everything before it exists to earn that line. And through all five beats: go point by point, never skip, never gloss.
This is the archetype that takes a reader from zero to a working result. The whole job is to walk them all the way through — and to talk about the actual game, not an abstract "project." Here is what each section delivers.
Introduce the thing itself: What is Claude Code? Then make the comparison the reader is already making in their head — by name, with conviction, not hidden behind "the alternatives":
Why Claude Code? Why is it the right call here over OpenAI — and why is Claude Code genuinely so good for building something like this?
Name the competitor, take a side, and defend it. Readers want a guide who has an actual opinion and will stand behind it. The named, opinionated comparison is exactly what gives a technical handbook its edge and its credibility — a neutral catalogue of options helps no one decide anything.
Deal with what people actually worry about before they even start. Introduce the pricing plainly. Then answer the real question: how do people reduce that cost? How do they actually cut it down? For a large share of readers, cost is the deciding factor in whether they can use the tool at all — so this isn't a footnote, it's load-bearing. Give them the concrete levers.
Walk it through completely: How do you install Claude Code? What platforms can you install it on? Lay it out as a clean A-to-Z sequence — the exact steps, the prerequisites, each supported platform, and a first-run check so the reader knows it actually worked. Assume nothing. Skip nothing.
Grow them through it, each step building on the last, so that by the end of the handbook they have a working result in their hands. Don't dump everything at once — evolve them one by one. By the final page they should have: the setup and access sorted (passcode and all), the Claude models understood and chosen sensibly, real Claude examples and real engineering examples in front of them, the install behind them, and the actual AI simulation game running. The list keeps going — and that's the point. Each piece is delivered in order until the reader is genuinely capable, not just informed.
Examples are extremely good — often the single most valuable thing in a technical handbook. Concrete, runnable, real examples are frequently the difference between a guide someone follows all the way to a finished game and one they abandon halfway. When in doubt, add another example.
https://www.freecodecamp.org/news/claude-code-handbook/
https://www.freecodecamp.org/news/the-lithography-handbook-machines-markets-and-the-next-wave-of-semiconductor-startups/
https://www.freecodecamp.org/news/the-case-for-end-to-end-engineering-education-preparing-institutions-for-a-dynamic-future/
https://www.freecodecamp.org/news/retrieval-augmented-generation-rag-handbook/
%402x.svg){kind=icon}