The Three Questions That Define Your Engineering Career

Early in my career, I remember staring at a codebase in a French startup, trying to get a feature to work. Any solution would do. I didn't care about elegance, maintainability, or trade-offs — I just needed the thing to compile and pass the basic tests. The only question in my head was: "How can I make this work somehow?"

A few years later, working in Germany, I found myself in a different kind of conversation. A colleague proposed using a message queue where I would have reached for a REST call. Instead of just making it work, I wanted to understand why one approach was better than the other. The question had shifted: "Why is approach A better than approach B here?"

Today, when I walk into a new problem, the first thing I reach for isn't a technology at all. It's context. Who are the users? What does the business need in three months vs. twelve? Where does this system sit in the broader architecture? The question is now: "What is the business context and use case we need to optimize for?"

These three questions aren't just milestones — they're a progression in how you think, and each one changes everything about how you work.

Stage 1: Making It Work

Every engineer starts here. You're building your toolkit — learning languages, frameworks, patterns — and the sheer volume of what you don't know is overwhelming. Your planning horizon is days, maybe weeks. You work mostly alone or in a pair, and success means shipping something that functions.

This stage is humbling, but it's also the most important time to be intentional. The engineers who grow fastest are the ones who resist specializing too early. Learn a backend language and a frontend framework. Write mobile code and infrastructure scripts. Your brain is a sponge at this stage — use that.

Stage 2: Understanding Why

At some point, "it works" stops being satisfying. You start noticing that some codebases are easier to change than others. You develop opinions about testing strategies, API design, and deployment pipelines. You start asking why before how.

This is where industry best practices become your compass. You learn that there are names for the patterns you've been reinventing — and that smart people have already mapped out the trade-offs. Your planning horizon stretches to weeks and months. You collaborate with a team, and your influence starts extending beyond your own code.

Stage 3: Solving the Right Problem

The final shift is the most subtle and the most valuable. You stop optimizing for technical correctness and start optimizing for impact. You realize that the "best" architecture depends entirely on context — team size, business stage, timeline, budget, risk tolerance.

At this stage, you're working across teams and functions. You're in the room with product managers and stakeholders, not because someone invited you, but because the problems you're solving require that perspective. Your planning horizon is quarters, sometimes longer.

The Cross-Pollination Effect

One thing that accelerated these transitions for me was alternating between startups and larger organizations. Startups gave me autonomy and forced creativity — you ship or you sink. Larger companies taught me how to think about scale, process, and organizational dynamics.

The real magic happens when you bring lessons from one world into the other. Startups need the operational maturity that big companies take for granted. Big companies need the scrappy pragmatism that startups live by. If you can be the person who bridges those worlds, you become remarkably versatile.

The Framework

The progression isn't strictly linear — you'll revisit earlier questions whenever you enter a new domain or pick up a new technology. But the center of gravity shifts. And once you start asking the third question by default, you'll notice that the first two become almost automatic.

The real career evolution isn't about learning more tools. It's about asking better questions.