Lesson 07-06 ended with a very specific instruction: read it with the pipeline in front of you. This lesson is where that gets put to the test. It is not a bibliography — a bibliography is a homework list nobody works through — but a map of what to read, in what order, to solve what, and with how much scepticism.

The difference between reading these books before the course and reading them now is enormous, and it is worth understanding why. Before, Continuous Delivery was an instruction manual about a world you had not seen: you read "the artifact must be built once and promoted between environments" and nodded without the sentence costing you anything. Now you have built that artifact, identified it by digest, seen what happens when somebody rebuilds the image in the production step and written in your PIPELINE.md why that is forbidden. The same sentence is no longer information: it is a confirmation or a discrepancy, and both of those teach you something.

This entire module rests on one idea: the goal of technical reading is not to accumulate, it is to decide better. And you can only decide better about a system that exists.

1. How to read technical material once you have a system
2. The four fundamentals
3. By topic: testing and design
4. By topic: resilience and operations
5. By topic: architecture and deployment
6. By topic: infrastructure
7. By topic: organisation and teams
8. By topic: scale and engineering
9. Living sources: what ages better than books
10. Master table: resource → problem → when
11. A 12-month reading plan
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

There are two ways to read a technical book and only one of them works at this stage.

Reading to accumulate is the school way: you start on page 1, underline, finish, feel good, and three months later you remember the title and little else. It is the approach that produces that very common and very misleading feeling that "I need to read more". You do not need to read more: you need to read with a question.

Reading to decide works like this: you come to the book with an open problem in your system, look in the table of contents for the chapter that touches it, read that chapter in full, and change something or write down why you are not changing it. The rest of the book waits until the next problem appears. A technical book is not a novel; it is documentation with a narrative, and you consult it.

A few practical rules make this work:

• Open the book with a written question. Literally written down, in a note. "Should we introduce canary in Mini-Reservalia or is rolling with health checks enough for us?" is a question. "I want to learn about deployment" is not.
• Read the full table of contents before anything else. It gives you the author's mental map and tells you which chapter to come back to in six months' time. It is 5% of the time and 40% of the value.
• Note the disagreements, not the agreements. When the book says what you already do, you learn nothing. When it says something that contradicts your pipeline, you have gold: either the book is out of date, or your context is different, or you are wrong. All three conclusions are useful and all three require you to write down the reasoning.
• Turn every reading session into a verifiable change or an entry in PIPELINE.md. If a book produces neither, either you read it without a question or it was not the right book.
• Take the date into account. A book from 2010 about continuous delivery gets the principles right and the tools wrong. One from 2021 about Kubernetes can get both wrong. The rough rule: the closer to the hardware and to a specific API, the sooner it expires; the closer to people and to the workflow, the longer it lasts.

There are four because these are the ones that hold up the scaffolding of everything you have done across seven modules. If you only ever read four books on this subject in your career, make them these.

What it argues. That software must always be in a deployable state, and that the way to get there is a deployment pipeline: an automated sequence of stages that progressively increases confidence in one and the same artifact until deploying it stops being an event. It is the book that gave a name and a structure to almost everything this course has made you build.

Which chapter matters most right now. The one on the deployment pipeline and the one on configuration and environment management. There you will find, in far more detail than fitted into 02-06 and 03-01, the justification for two rules that were treated here almost as dogma: build once and promote the same binary, and separate configuration from artifact. If at any point in the course the emphasis on the digest felt excessive, that chapter is the long-form reason.

What has aged. The specific tools and a good deal of the operational vocabulary: the book predates the standardisation of containers, ephemeral runners, environments as code in the cloud and image registries. You will find pages on managing build machines for something a GitHub Actions runner solves today in one line of YAML. It also assumes a world where deployment is more expensive than it is now.

What is missing. Everything that came afterwards: supply chain security (module 4), modern observability and SLOs (03-06), feature flags as a central practice (03-05) and the DORA framework as empirical validation — which arrived with the very next book.

When to read it. Now, and in consultation mode. It is the reference book you keep returning to, not the one you read in a single sitting.

What it argues. That continuous delivery practices are not ideology, they are measurable, and that there is a strong correlation between technical capabilities (automation, trunk-based development, decoupled architecture, monitoring) and business outcomes. It is the source of the four DORA metrics you defined in 01-05 and used to measure your progress in 07-04.

Which chapter matters most right now. The one on technical capabilities and the one on architecture. And, very especially, the methodological part: how the survey was built, what "correlation" means here and what it does not mean. That is the chapter most people skip and the only one that protects you from using the book as a hammer.

What has aged. The specific performance figures for each category. The "elite" thresholds have moved across successive editions of the DORA report and will keep moving; using the ones in the book as a target today anchors you to an old snapshot. Use the annual report for the numbers and the book for the reasoning.

What is missing. Honesty about its own methodological limitations beyond what the technical chapter acknowledges: it is a self-report survey, with a selection bias towards organisations already interested in the subject, and correlation is not causation however much the structural equation model suggests a direction. This does not invalidate it — it is the best evidence we have — but it is worth citing with that caution, especially in front of somebody like Diego, who will ask exactly this.

When to read it. Now, and above all before the conversation in which you have to justify investment in the pipeline. It is the book that turns "I think this is better" into "there is data pointing this way".

What it argues. It is the operating manual for DevOps culture, organised around "the three ways": flow (from development to operations), feedback (from operations to development) and continual learning. Where Continuous Delivery is technical and Accelerate is empirical, this one is organisational: how you introduce all of this into a company where there are people, politics and fear.

Which chapter matters most right now. The second way, feedback: telemetry, peer review, "stop the line" and a culture of psychological safety. It is the foundation of 02-01 (the assembly line that stops) and of 03-05 (the blameless post-mortem). And the learning chapter: why a post-mortem with a culprit guarantees that the next incident gets hidden.

What has aged. The set of case studies, very much centred on the 2010-2016 wave and on large companies. And a certain manifesto tone that was necessary when people still had to be convinced and today sounds like preaching to the converted.

What is missing. The book is long and sprawling; you can get 80% of it by reading the chapters that apply to you and skipping the rest with no remorse. It is not designed to be read linearly even though it looks like it is.

When to read it. When your problem stops being technical and becomes human. That is: as soon as you try to introduce anything from this course into a team that did not ask for it.

These are two books from Google and it is worth treating them as a pair. The first, Site Reliability Engineering, defines the discipline: SLIs, SLOs, error budget, toil, on-call, incident management. The second, The Site Reliability Workbook, is the one that grounds those ideas with concrete examples, templates and counter-examples.

What they argue. That reliability is a negotiable, measurable objective, not an infinite aspiration; that 100% is the wrong target; and that the error budget is the mechanism that turns an argument about opinions ("do we deploy today?") into a decision about data.

Which chapter matters most right now. From the Workbook, the one on implementing SLOs and the one on alerting on SLOs. They are the natural and far deeper continuation of what 03-06 reduced to the bare essentials: there you defined an availability SLO and an error budget, and alerted on symptoms rather than causes. The Workbook explains how SLIs are chosen when the service is not a simple GET /health, how multi-window burn rates work, and what to do when the budget genuinely runs out.

What has aged. Little in the principles. Quite a lot in the implicit scale: the books describe operating Google, with dedicated teams, internal tooling and volumes that look nothing like Reservalia. The Workbook is aware of this, which is why it is the more useful of the two for you.

What is missing — and this is the most common mistake. It is not a manual for three-person teams. Applying SRE literally in a small team produces a mountain of ceremony with nobody to sustain it. What does scale down: SLI/SLO, error budget, symptom-based alerting, blameless post-mortems and the idea of toil. What does not: formal on-call rotations, separate SRE teams, production reviews as a gate.

When to read it. The Workbook, now. The SRE Book, when reliability is your job rather than a part of your job.

What not to expect from this group. None of them talks about pipelines. They talk about what makes a green pipeline mean something. If your problem is "my suite takes 40 minutes", this group will not help you: that is 04-04.

On Release It!. It is the book on this list that most changes how you look at production code, and the most underrated. Its implicit thesis: software fails in ways the design never considered, and there is a finite catalogue of those ways. If in 03-05 automatic rollback on metrics felt like a sufficient safety net, this book will teach you how many failures produce no clear metric before they take your service down. It has aged in its platform examples (mid-2000s enterprise Java) and not one bit in its patterns.

The important warning. Newman is notably honest about the costs of microservices — he devotes pages to saying you probably do not need them — but the genre as a whole is not. If you read these books itching to break Reservalia apart, remember the conclusion of 05-03: the cost of microservices is paid in the pipeline and in operations, and a three-person team pays that cost in full without receiving the benefit, which is autonomy between teams it does not have.

Infrastructure as Code — Kief Morris.* This is the long version of what 03-03 condensed into a single lesson. It supplies the vocabulary and the patterns: immutable versus mutable servers, how to structure infrastructure code so that it can be tested, state management, environments as code, and the very real and very rarely addressed problem of how you test infrastructure.

• What it illuminates in the course: why 03-03 insists that Terraform state is the most fragile asset in the system, and why environments must come out of the same code with different variables.
• When to read it: when your Terraform goes from one directory to several modules and the question "how do I organise this?" appears. Before that moment it is theory without an anchor.
• What not to expect: recipes for a specific cloud. It is deliberately agnostic, and that means you still have to look up the exact syntax in the official documentation.

Team Topologies — Matthew Skelton and Manuel Pais.* It proposes four team types (stream-aligned, platform, enabling, complicated subsystem) and three interaction modes, and above all introduces cognitive load as a criterion for organisational design. It is the book that explains why "let's set up a DevOps team" usually produces a new bottleneck with a modern name.

• Link: lesson 08-04 talks about platform engineering as a career direction; this book is the conceptual framework for why that function exists and when it makes sense to create it. It also explains, in hindsight, why at Reservalia the pipeline is maintained by the same team that writes the product: with three people, any other topology is over-design.
• When to read it: when you have influence over how people are organised, or when you are suffering from a badly designed organisation and want the vocabulary to name the problem.
• What not to expect: a reorganisation plan. It is a language, not a procedure, and it has been fairly heavily abused as a PowerPoint label.

The Phoenix Project — Kim, Behr, Spafford.* A novel. An IT manager inherits a disaster and gradually discovers, with the help of a Socratic mentor, the principles of flow, bottlenecks and unplanned work.

• What it is genuinely useful for: not for you to learn from — the concepts are better explained in The DevOps Handbook — but for somebody else to read. It is the book you hand to the product manager, to senior management or to the sceptical colleague, because it reads in a weekend and produces the conversation you have been trying to have for months. As a tool of organisational persuasion it is worth more than the three fundamentals put together.
• What not to expect: rigour. It is a parable, with cardboard antagonists and a resolution that is far too clean. Its sequel, The Unicorn Project, tells the same story from the development point of view and has the same vices and virtues.

Software Engineering at Google — Titus Winters, Tom Manshreck and Hyrum Wright.* The book's thesis fits in one sentence: software engineering is programming integrated over time. What works for a program that lives a week does not work for one that lives a decade with a hundred people touching it.

• What it illuminates: the testing chapters (large, medium and small, and why classifying by size beats classifying by type), the CI one and the dependencies one. Especially the dependencies chapter: it is the best explanation in existence of why 04-02 insisted so much on the lockfile and on update discipline, and of the idea that depending on something means taking on a future obligation.
• When to read it: chapter by chapter, when the problem appears. It is a 600-page book written by many hands and of uneven quality.
• What not to expect: direct applicability. Google has a monorepo, in-house tooling and a scale that makes some of its solutions absurd anywhere else. Read the reasoning, ignore the implementation.

Books provide the foundations; living sources provide currency. A serious professional consumes both and knows what each is for.

What it is. An annual report, based on a survey of tens of thousands of professionals, that measures software delivery capabilities and their outcomes. It is the continuation of the work behind Accelerate and the source of the current thresholds for the four metrics you used in 01-05 and 07-04. It is published freely at dora.dev.

How to read it with statistical scepticism — this is the important part:

1. It is self-reported. Nobody measures anybody's lead time: people estimate it. The optimism biases are enormous, especially on the time-to-restore question.
2. There is selection bias. The people who answer are the people who hear about the survey, and the people who hear about it are those already in this conversation. The population is not "software worldwide".
3. The clusters change from year to year. The number of performance categories, their names and their thresholds have shifted between editions. Comparing your "elite" this year with the "elite" of three years ago is comparing two different things.
4. Correlation with a suggested direction is not demonstrated causation. The report is careful about this; its readers are not always.
5. The most valuable part is not the thresholds, it is the themes of the year. Each edition explores specific capabilities — documentation, internal platforms, AI, supply chain security — and that is where you will find content you will not get anywhere else.

How to use it well: to orient yourself and to argue your case, never as a target. Your target is the trend of your own four metrics, as you did with Reservalia (from 1.5 deployments per week and 68 hours of lead time to 12 and 3.5 hours). Comparing yourself with yourself six months ago is an honest measure; comparing yourself with a percentile from a global survey is theatre.

Martin Fowler's site is probably the best free source of precise vocabulary on these subjects. The articles on continuous delivery, feature toggles, branching and deployment patterns are canonical references: when somebody argues with you about whether "that is real CI", what they are quoting — knowingly or not — usually comes from there. The long article on feature toggles is the best publicly available extension of 03-05 in existence, with the full taxonomy (release, experiment, ops, permission) and the life cycle of a flag.

What to expect: clean, well-argued definitions with the trade-offs made explicit. What not to: complete neutrality. There is a clear position — trunk-based, tests first, simplicity — which this course shares, but which is worth recognising as a position.

This is the habit change with the best effort-to-benefit ratio in the whole lesson. Most people treat official documentation as a last resort: they try a blog tutorial first, then a forum answer, and only when nothing works do they open the documentation. Reverse the order.

The documentation for GitHub Actions (docs.github.com), Terraform, Docker, Kubernetes (kubernetes.io) or Prometheus is today of a quality it did not have ten years ago, includes the exact semantics a blog summarises badly and — crucially — is up to date. Half the problems in 06-06 with contexts, permissions and workflow_run are solved on the corresponding reference page, and no forum answer from 2021 is going to tell you that the behaviour changed.

Read it the way you read a book, at least once per core tool: the complete reference page for the workflow syntax, not just the fragment you were looking for. Two hours invested there save weeks of guesswork.

Some companies publish detailed analyses of their serious incidents. For operations they are what autopsies are for medicine: the only way to study how systems really break, names, timings and wrong decisions included.

What to look for in them, with the 03-05 template in hand:

• The complete causal chain, not the single "root cause". There are almost always between three and seven conditions that had to coincide.
• How long detection took versus how long the fix took. It is common for detection time to exceed repair time, which says a great deal about where to invest.
• Which piece of automation made things worse. It is a recurring pattern and a vaccine against overconfidence in the automatic rollback from 03-05.
• The tone. Good public post-mortems have no culprits, and it shows in how they are written.

There are community-maintained collections of public post-mortems on GitHub; search for "postmortems" and you will find years of material. Reading one a month for a year teaches more about operations than any course.

Reading the specification instead of the summary is one of those habits that separate the people who know from the people who repeat. Almost all of them are short.

The rule: when a tool forces you to choose between two options you do not understand (CycloneDX or SPDX?), the specification settles it in twenty minutes and settles it for good.

Realistic means: between 30 and 45 minutes, three days a week. No more. A plan that demands two hours a day gets abandoned in week three and produces guilt instead of knowledge.

Months 1-2 — Continuous Delivery, in consultation mode. Do not read it cover to cover. Read the deployment pipeline chapter, the configuration management one and the deployment strategies one, and after each of them go back to your PIPELINE.md and note a discrepancy. Deliverable: three new entries in that document.

Month 3 — Accelerate, complete. It is short. Read all of it, methodological section included. Deliverable: one page with the arguments you would use in front of somebody like Diego, with the limitations of the study included and anticipated.

Months 4-5 — The Site Reliability Workbook, SLO and alerting chapters. Deliverable: review the SLO you defined in 07-04 and decide whether the SLI you chose really measures what matters to the user. It probably does not.

Months 6-7 — Release It!, complete. It is the book you will most enjoy with production already running. Deliverable: identify at least two of the catalogue's antipatterns in your system, and decide whether they are worth mitigating.

Months 8-9 — Choose a branch depending on where you are heading (lesson 08-04 will help you decide): Feathers if you work with legacy, Newman if there is pressure to split things up, Morris if the infrastructure is growing, Team Topologies if you are moving towards coordination.

Months 10-12 — The DevOps Handbook chapter by chapter + the DORA report of the year. By this point you will have real implementation experience and the book will stop seeming obvious.

In parallel, all year round: one public post-mortem a month and the complete official documentation for the two tools you use most.

If at some point you fall behind, do not speed up: skip. One book read properly with the pipeline in front of you is worth more than three skimmed.

• Collecting books instead of reading them. Buying five at once is a way of putting things off. One open, with a written question, and no next one until it produces a change.
• Reading reference material from cover to cover. Continuous Delivery, the SRE Book and Software Engineering at Google are designed to be skipped through. Treating them like novels is the most efficient way to abandon them.
• Confusing a book's date with its validity. A book from 2010 can be accurate on principles and obsolete on tools. Always separate the two layers as you read: "is this an idea or an instruction?".
• Using Accelerate as a hammer. Quoting "elite teams deploy on demand" in a meeting convinces nobody and exposes you to the methodological question, which is a legitimate one. Quote the mechanism (small batches, less risk per deployment) and back it up with your metrics, not with a survey's.
• Ignoring official documentation because it looks boring. It is the source with the best signal-to-noise ratio there is and the only one guaranteed to be current. Start with it.
• Looking for the book that tells you what to do. It does not exist. Books give you models; the decision is still yours and depends on a context no author knows. A book that tells you exactly what to do without knowing your context is selling you something.
• Tip: write one-page reviews for yourself. Three sections: what it argues, what I changed because of it, what did not convince me. In two years' time that page will be worth more than rereading the book.
• Tip: read at least one book you disagree with. Thinking in this discipline has strong fashions, and this course has a position. Reading a serious defence of long-lived branches or of scheduled deployments will force you to know why you do what you do.

Choose two books and one living source for each of these three profiles, and justify in each case which specific problem the choice solves and what you have ruled out and why:

a) Nuria, frontend/QA at Reservalia. She writes E2E tests with Playwright, the suite takes 25 minutes and has had three tests in quarantine for a month. She wants tests to stop being a tax.

b) Diego, backend, sceptical about costs. He accepts the pipeline but questions every runner minute. He is going to have to defend the infrastructure budget in front of management next month.

c) A junior developer joining Reservalia, who programs well but has never deployed anything to production nor been on-call.

A colleague finishes this same course and tells you: "I've bought the four fundamentals, I'm going to read them back to back in three months". Write the reply you would give: what is wrong with the plan, what you propose instead, and one specific question they should bring in writing to the first book so that the reading is worth something.

Choose a chapter of Continuous Delivery or of the SRE Workbook that touches on a decision you made in module 7. Write half a page in the format: what the book says / what I did / why they differ / what I would do differently. "I would change nothing" is a valid answer, but only if the reason is written down.

Solution 1

There is no single correct combination; what is being assessed is whether the choice attacks the stated problem and whether the rejections are reasoned.

a) Nuria. Growing Object-Oriented Software, Guided by Tests and Software Engineering at Google (testing chapters), plus the official Playwright documentation read in full.

Nuria's real problem is not "writing more tests": it is that her tests are slow and brittle, which are two symptoms of the same design. Three tests in quarantine for a month is exactly what 02-04 described as normalised test debt. Freeman and Pryce attack brittleness at the root — how indiscriminate use of doubles couples the test to the implementation — and Google's testing chapter gives her a framework of sizes that will let her justify moving work from E2E towards cheaper levels, which is the only real way to get below 25 minutes. The Playwright documentation, all of it, because almost every slow E2E suite is slow through not making proper use of the waits, isolation and parallelisation the tool already offers.

Ruled out: Release It! — an excellent book, but its problem is production, not the suite. Ruled out: Accelerate — it would give her arguments, not solutions.

b) Diego. Accelerate complete and Software Engineering at Google (dependencies chapter), plus the current year's DORA report.

Diego needs ammunition for a conversation with management, and that conversation is not won with technical arguments but with evidence and business language. Accelerate is literally the book written for that, and the methodological section serves him twice over: as a sceptic, he will be the one who spots the holes in the study, and it is far better that he spots them before his counterpart does. The current year's report gives him today's numbers instead of the book's. Google's dependencies chapter fits his concern with cost because it explains the cost accumulated over time of decisions that look free today, which is the hardest argument to make and the one he most needs.

Ruled out: The Phoenix Project — it is the book to give to management, not for Diego to read, since he is already convinced on the technical side. Although an equally valid answer would be to recommend that he gives it as a present to his counterpart.

c) The junior. The Phoenix Project and Release It!, plus one public post-mortem a month.

Here the criterion is inverted: the junior has no context, so they need narrative before technique. The Phoenix Project gives them, in a weekend, the map of why all of this exists, which is exactly what a good programmer without production experience lacks. Release It! teaches them that correct code and a stable system are different things — the most expensive lesson to learn through experience. And public post-mortems are the most efficient substitute for the on-call shifts they have not yet done.

Ruled out: Continuous Delivery — without having suffered a manual deployment, its arguments will sound obvious and they will learn nothing. Ruled out: Accelerate — they need to understand the problem before the data about the problem.

Solution 2

What is wrong. Three things.

1. An unrealistic pace. The four add up to more than 1,500 dense pages. Three months is about 13 weeks: 115 technical pages a week, sustained. It gets abandoned in week four.
2. The wrong mode. At least two of the four (Continuous Delivery and the SRE Workbook) are reference material. Reading them linearly maximises effort and minimises retention.
3. And the underlying error: there is no question. Reading "the four fundamentals" is an accumulation goal. Nothing in that plan produces a change in any system, so six months later they will have four titles on the shelf and no new judgement.

What you propose. One book every two months, ordered according to their current problem: if they have just set up a pipeline, Continuous Delivery chapter by chapter; if they have to justify the investment, Accelerate first; if they already operate something in production, the Workbook. And one hard rule: no moving to the next chapter without having written an entry in their PIPELINE.md, whether a change or a reasoned rejection.

The written question. It must be specific and about their system. For example: "Does my production promotion step rebuild anything, or does it deploy exactly the same digest that was verified in staging? If it rebuilds, what am I risking?". With that question, the deployment pipeline chapter reads in 40 minutes and produces a decision. Without it, it reads in four hours and produces the feeling of having read something.

Solution 3

An example of a valid answer, on the deployment strategies chapter versus the decision taken in Mini-Reservalia:

What the book says. Continuous Delivery argues for blue-green as the default strategy for stateful services, because of the near-instantaneous reversibility and because it allows you to verify the new environment with real traffic before switching over.

What I did. In Mini-Reservalia I used rolling with health checks and a manual rollback.yml by digest, with a measured recovery time of about 4 minutes.

Why they differ. Blue-green doubles the infrastructure during the switchover window, and Mini-Reservalia's cost constraint (zero budget) makes that unviable. Besides, the book predates modern orchestrators: it assumes a manual rolling deployment is risky, whereas today the health check and gradual replacement are primitives of the orchestrator itself, not something I have to build. The risk blue-green mitigates is partly covered already.

What I would do differently. Nothing today, but with one written condition: if the SLO starts consuming error budget because of failures detected in the first few minutes after a deployment — that is, if rolling lets through problems a blue-green would have contained — the decision gets revisited. That goes into PIPELINE.md as a decision with a date and a review condition, which is the format 07-06 required.

What makes this answer valid is not the conclusion but the fact that the discrepancy is named, explained by context, and given a condition that reopens it.

You now have two things you did not have seven modules ago: a real system on which to test ideas, and the vocabulary to understand what the books say about it. That combination is what turns a bibliography into a tool.

Recapping the essentials:

• You read to decide, not to accumulate. A written question before opening the book, and a change or a reasoned rejection after closing it.
• The four fundamentals cover the technical foundation (Continuous Delivery), the empirical evidence (Accelerate), organisational implementation (The DevOps Handbook) and measurable operations (The Site Reliability Workbook). None of them is a manual; all four have parts that have aged, and knowing which is part of reading them well.
• The topic books get opened when the problem appears, not before: Feathers when the legacy arrives, Newman when the pressure to split up arrives, Morris when the infrastructure grows.
• Living sources — the DORA report read with statistical scepticism, martinfowler.com, official documentation as first stop rather than last, public post-mortems, short specifications — age far better than books and cost less time.
• A realistic 12-month plan is 30-45 minutes three days a week, with verifiable deliverables. If you fall behind, you skip; you do not speed up.

Books give you the foundation and specifications give you the precision, but there is a class of knowledge that neither of them contains: the kind that depends on context. Why in your specific company, with your specific cloud and your specific version of a tool, something that should work does not. That is not written down anywhere because it changes too fast to be worth writing, and it lives solely in the heads of people who have already run into it.

Finding those people, knowing how to ask them and giving something back in return is the next lesson: 08-02, Communities and Forums.