Tradeoffs, named out loud
Every design decision is a purchase. The skill is saying what you bought, what you paid, and at what price you would have chosen differently.
The sentence shape that marks out a senior engineer is: we chose X, which costs us Y, and we would choose Z instead if W were true. All three parts matter. Without the cost it is advocacy; without the condition it is dogma. "We denormalised the author name onto each post, which means a rename now needs a backfill, and we would normalise if authors renamed themselves more than rarely" is a complete thought and takes one line.
Watch for fake tradeoffs. Some choices are simply better, parameterised queries, structured logs, a lockfile, and pretending they have a serious downside to sound balanced wastes everyone's time. Real tradeoffs have a scenario in which each side wins. If you cannot describe the scenario where the other option is correct, it is not a tradeoff, it is a decision you have already made.
The other trap is the tradeoff you inherited without noticing. Every framework and platform default is somebody else's answer to a question you have not asked. Server components, edge runtimes, ORMs and managed queues each bought something and charged something, and finding out what at three in the morning is expensive.
You should now be able to
- State a decision with its cost rather than its benefit
- Identify the condition that would reverse a choice
- Recognise a fake tradeoff
Loading…