jargon

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

  1. 01

    the meeting spent five minutes on the data retention policy and thirty-five on the button label.

    Bikeshedding

  2. 02

    you shipped the quick version to make the date, wrote down what you skipped, and paid for it every sprint after.

    Technical debt

  3. 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

  4. 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

  5. 05

    you deleted the odd-looking retry, and a week later found out which flaky vendor it was for.

    Chesterton's fence

  6. 06

    you built the plugin system for the second provider, and two years later there is still only one provider.

    YAGNI

  7. 07

    you changed one module and three tests in a directory you had never opened went red.

    Coupling

  8. 08

    the code for one job is spread over four files, and each of those files also does three unrelated jobs.

    Cohesion

  9. 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. 10

    the function reads like a sentence for three lines and then drops into byte offsets.

    Level of abstraction

  11. 11

    the ORM hid the SQL right up until you had to read the query plan to fix a timeout.

    Leaky abstraction

  12. 12

    the rules really are that fiddly, because tax law is that fiddly, and no rewrite will make them simpler.

    Essential complexity

  13. 13

    half the file is there to work around a framework decision that has nothing to do with the feature.

    Accidental complexity

  14. 14

    the design handles ten thousand requests a second and the product has forty users.

    Over-engineering

  15. 15

    you asked where the pricing logic lives and were told it depends which of five places you mean.

    Big ball of mud

  16. 16

    everything ships together, so one bad line in someone else's feature blocks your release.

    Monolith

  17. 17

    you kept the single deployable and made a module boundary something the build fails on when crossed.

    Modular monolith

  18. 18

    the service you own deploys on its own schedule and you have never waited for another team's release.

    Microservice

  19. 19

    you split it into six services and still have to deploy all six together, in the right order.

    Distributed monolith

  20. 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. 21

    one region went down and you found out which of your services quietly lived only in that region.

    Failure domain

  22. 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. 23

    you trace the dependency graph and find one component whose failure takes everything else down with it.

    Single point of failureBackend

  24. 24

    you picked the customer-facing URL scheme, and two years of links mean it is never changing.

    One-way door

  25. 25

    you argued for a week about a library you could have swapped out in an afternoon.

    Two-way door

  26. 26

    you shipped it because you knew exactly how you would undo it, not because you were sure.

    Reversibility

  27. 27

    someone asked whether this needed a written decision, and the answer was whether it would be expensive to change later.

    Architectural significance

  28. 28

    you presented the design and spent forty minutes on a question you had not thought to ask yourself.

    Design review

  29. 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. 30

    you asked why the queue was chosen and someone found a one-page file in the repository from 2023.

    Architecture decision record

  31. 31

    everyone agrees it should be replaced, and everyone also agrees it is the only thing that knows the pricing rules.

    Legacy system

  32. 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. 33

    you decided to start again, and the old system kept receiving feature requests the whole time.

    Rewrite

  34. 34

    the replacement was blocked for two months on a report that four people run once a year.

    Feature parity

  35. 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. 36

    the system has four services and the company has four teams, and nobody planned that.

    Conway's law

  37. 37

    the team owns nine services and can explain four of them.

    Cognitive load

  38. 38

    one person was on holiday and the release could not go out until they got back.

    Bus factor

  39. 39

    you opened a pull request against another team's repository and it sat there for eleven days.

    Code ownership

  40. 40

    you were asked for a date before anyone had opened the vendor's documentation, and gave one.

    Cone of uncertainty

  41. 41

    you estimated the happy path, which is the only version of the work you pictured.

    Planning fallacy

  42. 42

    the team sized it a five, and someone in a status meeting asked how many days a five is.

    Story point

  43. 43

    you sorted twelve ideas into small, medium and large in twenty minutes, which was all the decision needed.

    T-shirt sizing

  44. 44

    the request was made in March and reached customers in June, and the coding took four days.

    Lead time

  45. 45

    the work took four days once someone started it, and it had been sitting in the backlog since March.

    Cycle time

  46. 46

    you were told to finish one of the four things you had started before picking up a fifth.

    Work-in-progress limit

  47. 47

    each addition was reasonable on its own and the project is four months longer than it was in January.

    Scope creep

  48. 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. 49

    you write up what happened focusing on why the system allowed it, not on who typed the command.

    Blameless postmortemBackend

  50. 50

    you asked why five times and ended up at a deploy process nobody had questioned in two years.

    Five whys

  51. 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. 52

    the migration has taken eight months, so the argument for continuing was that it has taken eight months.

    Sunk cost fallacy

  53. 53

    you believed it was the cache and read the logs looking for the cache, and found something.

    Confirmation bias

  54. 54

    the team was measured on tickets closed, and the tickets got smaller.

    Goodhart's law

  55. 55

    the room had agreed until the director said what they preferred, and then everyone had a new opinion.

    HiPPO

  56. 56

    you argued a position firmly, someone produced a number, and you changed your mind in the same meeting.

    Strong opinions, weakly held

  57. 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.

The 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.

Nobody 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.

Senior 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.

How 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.

Almost 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.

The 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.

How 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.

The 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.

The 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.

The 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.