Subjects·10 topics·177 terms
Architecture & practice
Tradeoffs, risk, teams, delivery, estimation and incidents — the words senior engineers argue in.
Start with these 57, in order
The words senior engineers argue in: structure, complexity, risk, decisions, migration and the shape of the team underneath it all.
Read in order · tick what you already know
- 01
the meeting spent five minutes on the data retention policy and thirty-five on the button label.
Bikeshedding
- 02
you shipped the quick version to make the date, wrote down what you skipped, and paid for it every sprint after.
Technical debt
- 03
the design covered what happens when it works and the review found nothing about what happens when the vendor is down.
Happy path thinking
- 04
you changed the order of a JSON response and a customer's integration broke, and nowhere did you promise an order.
Hyrum's law
- 05
you deleted the odd-looking retry, and a week later found out which flaky vendor it was for.
Chesterton's fence
- 06
you built the plugin system for the second provider, and two years later there is still only one provider.
YAGNI
- 07
you changed one module and three tests in a directory you had never opened went red.
Coupling
- 08
the code for one job is spread over four files, and each of those files also does three unrelated jobs.
Cohesion
- 09
you wanted to change the retry policy and had to read a HTML template to find where it was set.
Separation of concerns
- 10
the function reads like a sentence for three lines and then drops into byte offsets.
Level of abstraction
- 11
the ORM hid the SQL right up until you had to read the query plan to fix a timeout.
Leaky abstraction
- 12
the rules really are that fiddly, because tax law is that fiddly, and no rewrite will make them simpler.
Essential complexity
- 13
half the file is there to work around a framework decision that has nothing to do with the feature.
Accidental complexity
- 14
the design handles ten thousand requests a second and the product has forty users.
Over-engineering
- 15
you asked where the pricing logic lives and were told it depends which of five places you mean.
Big ball of mud
- 16
everything ships together, so one bad line in someone else's feature blocks your release.
Monolith
- 17
you kept the single deployable and made a module boundary something the build fails on when crossed.
Modular monolith
- 18
the service you own deploys on its own schedule and you have never waited for another team's release.
Microservice
- 19
you split it into six services and still have to deploy all six together, in the right order.
Distributed monolith
- 20
'customer' means one thing to billing and something else to support, and the shared table forces one of them to be wrong.
Bounded context
- 21
one region went down and you found out which of your services quietly lived only in that region.
Failure domain
- 22
you ask how much of the product breaks if this one component dies, and design so the answer is not "all of it".
Blast radiusBackend
- 23
you trace the dependency graph and find one component whose failure takes everything else down with it.
Single point of failureBackend
- 24
you picked the customer-facing URL scheme, and two years of links mean it is never changing.
One-way door
- 25
you argued for a week about a library you could have swapped out in an afternoon.
Two-way door
- 26
you shipped it because you knew exactly how you would undo it, not because you were sure.
Reversibility
- 27
someone asked whether this needed a written decision, and the answer was whether it would be expensive to change later.
Architectural significance
- 28
you presented the design and spent forty minutes on a question you had not thought to ask yourself.
Design review
- 29
you wrote up the plan and left it open for a week so people could argue in the margins before you built anything.
Request for comments
- 30
you asked why the queue was chosen and someone found a one-page file in the repository from 2023.
Architecture decision record
- 31
everyone agrees it should be replaced, and everyone also agrees it is the only thing that knows the pricing rules.
Legacy system
- 32
you put a router in front and moved one endpoint at a time until the old service had no traffic left.
Strangler fig
- 33
you decided to start again, and the old system kept receiving feature requests the whole time.
Rewrite
- 34
the replacement was blocked for two months on a report that four people run once a year.
Feature parity
- 35
the rewrite is going to fix every compromise in version one, all at once, and it is nine months late.
Second-system effect
- 36
the system has four services and the company has four teams, and nobody planned that.
Conway's law
- 37
the team owns nine services and can explain four of them.
Cognitive load
- 38
one person was on holiday and the release could not go out until they got back.
Bus factor
- 39
you opened a pull request against another team's repository and it sat there for eleven days.
Code ownership
- 40
you were asked for a date before anyone had opened the vendor's documentation, and gave one.
Cone of uncertainty
- 41
you estimated the happy path, which is the only version of the work you pictured.
Planning fallacy
- 42
the team sized it a five, and someone in a status meeting asked how many days a five is.
Story point
- 43
you sorted twelve ideas into small, medium and large in twenty minutes, which was all the decision needed.
T-shirt sizing
- 44
the request was made in March and reached customers in June, and the coding took four days.
Lead time
- 45
the work took four days once someone started it, and it had been sitting in the backlog since March.
Cycle time
- 46
you were told to finish one of the four things you had started before picking up a fifth.
Work-in-progress limit
- 47
each addition was reasonable on its own and the project is four months longer than it was in January.
Scope creep
- 48
you sat down a week later with the timeline and worked out why the wrong dashboard was the obvious one to check.
Incident review
- 49
you write up what happened focusing on why the system allowed it, not on who typed the command.
Blameless postmortemBackend
- 50
you asked why five times and ended up at a deploy process nobody had questioned in two years.
Five whys
- 51
the deploy triggered it, and the missing alert, the stale runbook and the one-person rotation all had to be true as well.
Contributing factor
- 52
the migration has taken eight months, so the argument for continuing was that it has taken eight months.
Sunk cost fallacy
- 53
you believed it was the cache and read the logs looking for the cache, and found something.
Confirmation bias
- 54
the team was measured on tickets closed, and the tickets got smaller.
Goodhart's law
- 55
the room had agreed until the director said what they preferred, and then everyone had a new opinion.
HiPPO
- 56
you argued a position firmly, someone produced a number, and you changed your mind in the same meeting.
Strong opinions, weakly held
- 57
you argued hard against it, lost, and then did the work properly instead of relitigating in every standup.
Disagree and commit
All of architecture & practice
Every term in this subject, 177 of them, grouped into 10 topics. Each topic is a track of its own.
Design, structure and tradeoffs
01 · 25 termsThe words for why one arrangement of the same code is better than another. Almost every design review disagreement is one of these ideas being felt by one person and named by nobody, which is why the argument goes in circles until someone says the word.
- Coupling
- Cohesion
- Temporal coupling
- Separation of concerns
- Single responsibility
- Encapsulation
- Law of Demeter
- Command-query separation
- Principle of least astonishment
- Affordance
- Leaky abstraction
- Level of abstraction
- Indirection
- Layered architecture
- Dependency inversion
- Seam
- Orthogonality
- Composability
- Composition over inheritance
- Bounded context
- Ubiquitous language
- Monolith
- Modular monolith
- Microservice
- Distributed monolith
Complexity and how it accumulates
02 · 18 termsNobody decides to build a mess. It arrives one reasonable decision at a time, and the vocabulary here exists to make a single one of those decisions arguable while it is still being made rather than two years later.
Risk, blast radius and change
03 · 15 termsSenior engineers are not more cautious than everyone else; they are more specific about what could go wrong and how far it would spread. These are the terms that turn 'this feels risky' into a claim someone can agree or disagree with.
Making and recording decisions
04 · 15 termsHow a group of people who disagree arrive at one design and leave a trail explaining why. Most of the pain of joining a codebase is that these documents were never written, so the reasons are gone and only the consequences remain.
Legacy systems and migration
05 · 14 termsAlmost nobody starts from nothing. This is the vocabulary of changing something that is already running and already has users, where the hard part is never the new code but the six months where both versions exist.
Teams, ownership and Conway's law
06 · 17 termsThe architecture and the org chart are the same drawing. Once you can name the shapes teams come in and what each one is for, half of the arguments that looked technical turn out to be arguments about who owns what.
Delivery, flow and technical debt
07 · 20 termsHow work moves from someone's head to production, and what slows it down. The measurements here exist because 'we are moving slowly' is not actionable and 'a change takes nine days to reach production, of which eight are waiting' is.
- Trunk-based development
- Feature branch
- Long-lived branch
- Continuous integration
- Continuous delivery
- Continuous deployment
- Batch size
- Work-in-progress limit
- Flow efficiency
- Lead time
- Cycle time
- DORA metrics
- Deployment frequency
- Change failure rate
- Mean time to restore
- Shift left
- Definition of done
- Toil
- Technical debt
- Debt quadrant
Estimation and planning
08 · 18 termsThe part of the job where engineers are asked to say something confident about the future. These terms will not make your estimates right, but they will let you say precisely why they are wrong, which is what the conversation actually needs.
Incidents and what happens after
09 · 19 termsThe vocabulary of a bad afternoon and the review that follows it. Most of it exists to keep two things apart: stopping the bleeding and understanding the cause, which are different jobs done by different people at different times.
Judgement and reasoning traps
10 · 16 termsThe named ways that competent people talk themselves into the wrong answer. Knowing them is not about winning arguments; it is about noticing, mid-sentence, that the thing you are about to say is one of these.