Learn First, Build Later

The best engineers don’t just write code in their teams, they actively participate in the product creation process. And that does not start with code.

When you are presented with an idea, or you and your team come up with a solution, your first job is to answer a much more uncomfortable question:

How confident are we this idea will actually work?

This is where you, as an engineer, need to engage with the discipline of product management. It doesn’t take much learning in this space to make you a much more effective engineer.

Learning Is the Goal

Writing code for production as your first move is often wrong. Many teams think their job is to build something, to deliver something. That’s the wrong mindset.

Building software that solves human problems is a process of continuous discovery, of learning. And scalable, resilient, production-grade code is the most expensive way to learn something.

This is where a lot of teams fall into the “architecture-first” trap:

• Carefully designing a system
• Planning for scale and “extensibility”
• Building it “properly”

This before they’ve proven the thing should exist at all. That’s how you end up spending months building something that dies on contact with reality.

The alternative is much simpler, but hard to accept if you’re not used to working this way. Don’t build the thing. Learn about the thing.

• Fake it
• Prototype it
• Simulate it
• Manually run it behind the scenes

Do whatever gives you signal without committing to the full cost of production-grade software. Because once you write the code, you’re not just testing an idea - you’re committing to maintaining it.

Reduce the Cost of Being Wrong

You are going to be wrong. All engineers, and software teams, are wrong - doesn’t matter how good they are. The thing that separates the good teams from the less good teams is how much being wrong costs:

• a few days
• a few weeks
• or nine months, a staff engineer, and a post-mortem nobody reads

Most engineering disasters are not caused by building bad software, they’re caused by building the wrong software. The goal isn’t “be right all the time” - the goal is make being wrong cheap.

This is where good teams separate themselves. They design their process so that mistakes surface early and cheaply. They don’t try to avoid failure - they run headlong into failure, aiming to fail fast enough that it doesn’t matter.

Because good teams understand their goal is to learn.

The Tracer Bullet Mindset

One common and powerful tactic for implementing this mindset in practice is the concept of the “tracer bullet”. You build a thin, end-to-end version of something first. It’s not a prototype of one piece, it’s not a perfectly engineered backend.

It’s a real slice that goes all the way through the system end-to-end - just with the complex logic left marked // TODO, and hardcoded or dummy data:

• input → processing → output
• user → system → result

This is your tracer bullet - it flies through the darkness of uncertainty and quickly lights up all the shenanigans you will inevitably have to deal with along the way. At first this feels like working backwards, but once you get the hang of it you will understand why it’s so powerful. In record time you will know:

• Where are the gaps?
• What assumptions break?
• What did you completely misunderstand?

You learn more from one rough end-to-end slice than from weeks of isolated “perfect” components.

Often, once you have that thin slice working, you can then start to fill in the blanks:

• Replace the // TODOs with actual logic
• Handle real edge cases
• Improve performance where it actually matters

Additionally, because this system is working end-to-end from day 1, you may even be able to release more frequently as you fill in these blanks, allowing you real world learnings from users right from the beginning.

Senior Engineers Are Guardians

As you grow in seniority as an engineer, your job becomes to protect you and your team from building the wrong thing. This can result in wasted time, poor impact, poor growth, architectural and technical debt, burnout, and so on. The best way to do that is to actively engage with the product creation process, by understanding how confidence is deliberately built in a solution.

Confidence, in this sense, I think is best described by Itamar Gilad - his confidence meter concept is a really useful tool for learning these ideas, even if you don’t use it exactly in your organisation.

Confidence in your solution roughly exists on a ladder:

• Self conviction is low
• Expert opinions add a little more
• Competitor research adds more
• User research even more
• Real test results much more
• Launch data with real users - that’s the goal

You can use this concept to know when it’s time to ask more questions, and what level of solution is appropriate based on the supporting data an idea is coming to you with.

If you have an executive, or a PM, or anyone coming to you with an pitch deck that sounds great and polished but has no other evidence you don’t have to say no - you just know where you are on the confidence ladder, and therefore how much is left to learn.

This means:

• Pushing back when confidence is low - suggest lighter, experiment-grade work
• Challenge assumptions that aren’t supported by evidence
• Refuse to “just start building” when the problem isn’t clear

You are not an order-taker. You are the guardian of effort and focus. Because software is expensive and every “yes” you give carries with it the implicit agreement you will not only build the thing, but that you will look after it, indefinitely.

If the team is about to spend 3 months on something with no validation, instead suggest something lighter, something cheaper - do it “by hand”, or with throwaway scripts - whatever you need to do to learn more about the solution before you build it. Once you and your team are confident the solution is the right one, then it’s time to break out the design docs and build something permanent.

From getting closer, faster, to the truth of:

• what users actually do
• what systems actually need
• what breaks under real conditions
• what facts were really assumptions

Every step should answer:

“Are we more confident than we were yesterday?”

If the answer is no, then you’ll be busy but you might not be making real progress.

How to Start

Next time you start a piece of work, ask:

• What’s the fastest way we could be proven wrong?
• How do we do that in days, not months?
• What’s the smallest thing we could build that touches real users?

This is not about building production-grade software faster - that takes time and care, and rightly so. It’s about building something smaller, lighter, cheaper first and then using that to learn what that production-grade software needs to be before you break out the Cherry MX Blues.

This is actually how you deliver valuable software, faster.