Engineering Is Not About Getting Every Decision Right

If SDLC sounds familiar, you probably know that a product isn't built in one step.

A product is built through a whole set of processes, decisions, iterations, and feedback loops.

This becomes even more important when you're building something from 0 to 1.

You need to stay focused on what you're building, be conscious of the decisions you're making, and stay alert to potential technical debt.

Imagine You Need to Ship a Feature

You have the requirements.

You know the expected outcome.

You have a deadline.

But a feature is rarely just one thing.

It can connect with other services, components, repositories, databases, APIs, and different states of the system.

There are always edge cases and possibilities that you can't see at the beginning.

So you choose an approach.

Maybe Approach A looks like the best fit at that moment.

You implement it, connect it with the rest of the system, test it, and ship the feature.

Done.

You move on to the next thing.

Then You Discover Approach B

A few weeks later, you're working on another feature.

And suddenly, you realize:

"Wait... if I had used Approach B, both features could have been designed in a much better way."

Looking back, Approach A might not seem like the best decision anymore.

But does that mean the decision was wrong?

I don't think so.

At that point in time, you were making a decision based on the information, requirements, constraints, and experience you had.

You made what you thought was the best decision at that moment.

Later, you gained more context.

And with that new context, you found a better solution.

Engineering Isn't About Proving Every Decision Was Right

I think this is one of the interesting parts of software engineering.

We're not trying to prove that every decision we made was correct.

We're trying to stay in the loop:

Build → Observe → Learn → Improve → Build again

Every time we go through that loop, we gain more understanding.

Maybe we understand the product better.

Maybe we understand the architecture better.

Maybe we understand the users better.

Or maybe we simply understand ourselves as engineers better.

And that changes the decisions we make next time.

Sometimes Refactoring Feels Frustrating

Of course, improving an existing implementation isn't always fun.

Sometimes you have to refactor something that already works.

Sometimes you need to rethink an architecture you were once confident about.

Sometimes you look at code you wrote a few months ago and think:

"Why did I build it this way?" 😅

It's easy to see this as wasted effort.

But I think there's another way to look at it.

The implementation improved because you improved.

The code changed.

The system changed.

And more importantly, you changed.

You Don't Need to Know Everything From Day One

Especially when building something from 0 to 1, there will always be things you don't know yet.

You can't predict every future requirement.

You can't see every edge case.

You can't always know which abstraction will work best six months from now.

That's okay.

What matters is being conscious about the decisions you're making today and staying alert to the problems that might appear tomorrow.

Don't ignore technical debt.

But don't be afraid of making decisions either.

You need to build something before you can learn how to build it better.

The Beauty of Engineering

Maybe that's one of the things I like most about engineering.

We're not expected to know everything from the beginning.

We're expected to keep learning and make better decisions as we gain more context.

An implementation that seemed reasonable yesterday might not be the best solution today.

And that's not necessarily failure.

It can be a sign that you've grown.

So let's keep building.

Let's build some things that might look "bad" in hindsight.

Maybe one day, they'll become the reason we know how to build something better.

Happy coding, happy Monday ☕️