Trade-offs — there is no free lunch in engineering

Junior engineering thinking often searches for the single "correct" or "best practice" answer to a design question. More experienced engineering recognizes that most real choices trade one desirable property for another — there usually isn't a strictly dominant option, only different combinations of trade-offs suited to different situations. The actual skill is naming the trade-off explicitly, then picking deliberately based on what this specific situation actually needs.

The "right" choice on any of these axes genuinely depends on the specific situation, not a rule that applies everywhere: a prototype validating whether anyone wants a feature at all should lean toward simplicity and speed, even at the cost of flexibility or long-term maintainability; a payments system handling real money should lean hard toward correctness, even at real cost to development speed. Treating either extreme as a universal "best practice" misses that the actual right answer moves depending on what's actually at stake.

The habit that turns implicit, easily-forgotten choices into deliberate, defensible ones: stating explicitly what's being optimized for and what's being given up, at the moment the decision is made — "we're choosing the simpler in-memory approach for now, accepting it won't survive a server restart, because we don't have enough real usage yet to know if this feature is even worth the investment for something more durable." This one sentence turns an implicit, easily-forgotten choice into something a teammate can evaluate, agree with, or push back on — and something future-you can understand months later without having to reconstruct the reasoning from scratch.

A trade-off nobody named explicitly doesn't disappear — it just becomes invisible until it causes a problem, at which point it looks like a mistake rather than what it actually was: a reasonable decision made for reasons that were never written down anywhere. This is exactly the same failure mode as undocumented technical debt from two lessons ago — the problem isn't making trade-offs (unavoidable), it's failing to record which ones were made and why.

Naming a trade-off in a comment or a conversation works for small, local decisions. Larger, more consequential decisions — the ones that affect how a whole system is built, or that a team will need to remember the reasoning behind for years — deserve a more durable, more visible record than a code comment, which is exactly the subject of the next lesson: writing decisions down as RFCs and ADRs.