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, a pitch, a feature request - your first job is to answer a much more uncomfortable question:

How confident are we this is the right idea?

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 nobody uses, or 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. This means considering options like:

• rather than build a UI, can we use a spreadsheet?
• rather than refactor the backend, can we just use a local throwaway script?
• rather than integrating a new service, can we just call it “by hand”?
• rather than code, can we tweak data, or config?
• rather than suffer complex system integrations, can we “bolt this on”?

When the lift is light, then being wrong is not a problem, it’s a gift. It’s learning without the pain.

Empowered with these learnings you will either be able to a) confidently reject the idea; or b) confidently build the “real deal”. This is especially important where you need a large, coordinated effort with others - that additional data you capture through real-world learning will be much more valuable in persuading others to your cause than “trust me bro”.

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, technical or design 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.

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 is built on evidence, and that evidence exists roughly on a ladder:

• Self conviction is low - “I think this is a good idea”
• Expert opinions add a little more - “Our sales lead loves this”
• Competitor research adds more - “Competitors are already doing it”
• User research even more - “Our users are asking for it”
• Real test results much more - “Our users loved the prototype”
• 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 evidence an idea is coming to you with.

If you have an executive, or a PM, or anyone coming to you with a pitch that sounds great and polished but has no other evidence you don’t have to say no - you just need to establish where you are on the confidence ladder, and therefore how much is left to learn. The question then becomes “what’s the smallest solution that lets us learn more?”

This means:

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

You are not an order-taker. You are a guardian of complexity. Software is complex and every “yes” you give carries with it the implicit agreement 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 - whatever you need to do to learn more about the problem before you commit to building something permanent. Once you and your team are confident the problem is well understood, and your solution is the right one, then it’s time to flex your GO4 patterns and build the “real deal”.

Every step should get you closer, faster, to the truth of:

• what users actually do
• what systems actually need
• what breaks under real conditions
• what “facts” are really assumptions

This is how you build confidence that this is either the right idea, or the wrong one. Either answer is ok, because you’ve made being wrong cheap.

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 and cutting corners. Working, scalable, resilient software takes time and care, and rightly so.

This is 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 and get typing.

This is actually how you deliver valuable software, faster.