Every design decision you make closes off something else, which is just how software works, so making tradeoffs consciously is key, rather than doing it accidentally by adding features that increase complexity or optimizing for performance in a way that adds latency
The tradeoff between functionality and performance is a common one, where implementing a feature in a clean and expressive way may make it slow, or making it fast may result in code that's hard to read, and the answer depends on what matters for your specific case
If the code runs once a day in a batch process, optimizing for readability makes sense, but if it's in a hot path that runs thousands of times per request, optimizing for performance is the way to go, and applying the same answer everywhere is a mistake
Flexibility versus simplicity is another big tradeoff, where building an abstraction to handle many scenarios may make the code harder to reason about, and the right approach is to write the simplest thing that works but structure it to be easy to extend if needed
Scalability versus cost is also important, where designing for current traffic and optimizing cost may require a painful rewrite later, and measuring growth rate and runway is crucial to making the right decision, such as if you're growing 20% month-over-month and only have capital for six months
Security versus usability is a constant tradeoff, where requiring multi-factor authentication and hardware keys may make the user experience pristine but also cumbersome, and most of the time the right answer is reasonably secure, not maximally secure
To make these decisions, be explicit about what you're optimizing for, understand the costs, measure instead of guessing, and iterate, starting with the simple solution and optimizing as needed, and document the decision and reasoning for future engineers
Technical debt and long-term thinking are also crucial, where taking a shortcut that makes the code harder to understand may cost you every time someone works on it, and thinking about the cost of getting it wrong and how likely it is can help make the right decision
Sometimes compromise is necessary, and getting specific about what matters most, such as optimizing for readability in one service and for throughput in another, and documenting the decision and reasoning is essential for future engineers to understand and change the tradeoff if needed
Treating tradeoffs as permanent is a mistake, and revisiting the decision periodically and measuring to see if what you optimized for still matters is crucial, and having a strategy and being intentional about tradeoffs is key to avoiding a system that's mediocre at everything