Reference · 44 terms

Glossary

Every short form used across the series. Inside a lesson, hover or tap any dotted term to see the same entry in place.

Thinking

assumptionAssumption: Something you believe is true but have not checked. Good thinkers say their assumptions out loud.Lesson 0 →
proof of conceptProof of concept (PoC): A small version that shows an idea can work. It is not production code.Lesson 0 →
reversible decisionReversible and hard-to-reverse decisions: A reversible decision is cheap to undo. A hard-to-reverse one (database, public API, core language) deserves more thinking.Lesson 0 →
spikeSpike: A short, time-limited experiment to learn something. You can throw the code away afterwards.Lesson 0 →
trade-offTrade-off: You get one good thing by giving up another. Faster to build, but harder to change later.Lesson 0 →

bus factorBus factor: How many people can leave before the project is in trouble. A bus factor of one is a risk.Lesson 1 →
decision recordDecision record (ADR): A short note with title, status, context, decision and consequences. It saves the 'why' for people who join later.Lesson 1 →
dependencyDependency: Code written by someone else that your project needs, like an npm package. A transitive dependency is one your dependency brings.Lesson 1 →
maintenanceMaintenance: The work to keep something working after release: updates, fixes and security patches.Lesson 1 →
transitive dependencyTransitive dependency: A package that one of your dependencies needs. You did not add it, but you carry its risk.Lesson 1 →

innovation tokenInnovation tokens: A small budget of new, unproven technologies a team can afford. Spend one only where it gives a real advantage.Lesson 2 →

nitNit (review comment): A small, optional review remark. Marking it 'Nit:' tells the author they do not have to fix it in this change.Lesson 3 →
refactoringRefactoring: Changing the inside of code to make it easier to understand without changing what it does.Lesson 6 →
SLOSLO (service level objective): A target for how well a service should work, such as '99.9% of requests succeed'. An SLI is the measure it uses.Lesson 6 →
technical debtTechnical debt: A shortcut that saves time now and costs time later, like a loan with interest.Lesson 3 →

DORADORA metrics: Four delivery measures: deployment frequency, lead time for changes, change failure rate and time to recover.Lesson 4 →
postmortemPostmortem: A written review after an incident. Blameless means it looks for causes in the system and process, not a person to punish.Lesson 4 →

design docDesign doc / RFC: A short written plan shared before you build: problem, goals and non-goals, proposal, alternatives, risks and rollout.Lesson 5 →
non-goalsNon-goals: Things the plan will not do, written down so the discussion stays focused.Lesson 5 →

bikesheddingBikeshedding (Law of Triviality): Groups spend too much time on small easy topics and too little on big hard ones.Lesson 7 →
Brooks's LawBrooks's Law: Adding people to a late project tends to make it later.Lesson 7 →
Chesterton's FenceChesterton's Fence: Do not remove or change something until you understand why it exists.Lesson 7 →
Conway's LawConway's Law: A system's structure tends to mirror the communication structure of the organisation that builds it.Lesson 7 →
Gall's LawGall's Law: Complex working systems grow from simpler working systems; a complex system designed from scratch tends not to work.Lesson 7 →
Goodhart's LawGoodhart's Law: When a measure becomes a target, it stops being a good measure.Lesson 7 →
Hyrum's LawHyrum's Law: With enough users, every observable behaviour of an API will be depended on by someone.Lesson 7 →

1:11:1: A regular private meeting between a lead and one person. It is the person's time, not a status meeting.Lesson 8 →
disagree and commitDisagree and commit: Say your view clearly before a decision; once it is made, support it fully even if you would have chosen differently.Lesson 8 →
nemawashiNemawashi: Quietly building support for a change with the people affected before you propose it formally.Lesson 10 →
onboardingOnboarding: The first weeks of a new person: setup, learning the system, meeting people and doing a first real task.Lesson 9 →
stakeholderStakeholder: A person or group who cares about the result or is affected by it: product, design, support, management, users.Lesson 10 →

career ladderCareer ladder: A company's description of levels and what is expected at each.Lesson 13 →
roadmapRoadmap: A plan of bets over time. Dates are best shown as ranges.Lesson 12 →
sponsorshipSponsorship: Using your influence to open doors for someone. It differs from mentorship, which gives advice.Lesson 13 →
technical strategyTechnical strategy: A short written diagnosis of the problem and the chosen approach and actions, not a wish list.Lesson 12 →

SECURITY.mdSECURITY.md: A file in a repository that says how to report a security problem.Lesson 14 →
threat modelThreat model: A short exercise to list what could go wrong and what you will do about it.Lesson 14 →

blamelessBlameless review: A review that asks how the system and process allowed an event, assuming people did their best with what they knew.Lesson 17 →
inverse Conway manoeuvreInverse Conway manoeuvre: Design the teams to match the software you want, instead of letting team shape decide the architecture.Lesson 16 →
psychological safetyPsychological safety: People believe they can ask, admit mistakes or disagree without being punished or mocked.Lesson 17 →
retrospectiveRetrospective: A regular meeting where a team looks at how things went and chooses one to three changes.Lesson 17 →
runbookRunbook: A short document with the steps to handle a known problem or alert.Lesson 16 →
service catalogueService catalogue: A list of services with their owner, purpose, docs, dashboard and on-call contact.Lesson 16 →
toilToil: Repetitive manual work that grows with the service and could be automated.Lesson 16 →