Trade-Offs All the Way Down
One common trait among early-career programmers is seeing technology choices in black-and-white. I've been there. "Redux is awesome!" "Nested ternaries are terrible!" As you advance as a programmer, for better or worse, you start to see almost everything as a trade-off.
Trade-offs at a low level, such as choices made within an individual code file, and trade-offs at a strategic level, such as which technology tools to invest in and people to hire. It often feels like it's trade-offs all the way down.
At the low level, in a React project, open up any file and you're going to see trade-offs. Perhaps the file is written in TypeScript, a type-safe superset of JavaScript. The trade-off: fewer bugs in exchange for a more complex development environment.
Moving down the file, perhaps we use memoization via useMemo and useCallback. React introduced these to improve performance, and we're using them heavily. The trade-off: better performance in exchange for additional code to understand and maintain.
Further down, we find styling via Tailwind CSS, a modular CSS tool. The trade-off: uniform, rapid design, in exchange for a generic look and code full of class names like "relative p-3 col-start-1 row-start-1 flex flex-col-reverse."
Let's zoom out. Hiring: what kind of engineers are we looking for? Clients: mobile application, web application, or terminal application (or all three)? Money: bootstrap or investors? It never ends.
My tradeoff-y worldview surfaces when I review code. I rarely say "This is bad" because I rarely think that. I think the choices I see are trade-offs, and I can explain them off the cuff or with some research. Most of the time one end of the trade is better for this situation, and that's what I'll push for. But I want to explain the complexity as often as I can to develop my team, so that you start to see it, too. And I've found it's more persuasive to build my critique, when feasible, from first principles.
So, how do you start seeing tradeoffs? The only path that I know is building and breaking stuff for years. I used modern tools like TypeScript, sometimes it worked and sometimes it didn't. I prematurely optimized and felt the power and pain. I used design libraries to build with speed and long class names. Over time, it starts to become second nature, and it influences how you approach everything. The sooner you start building and noticing, the sooner you'll start thinking like a senior engineer.