I’m a C++ Developer. Part of my job is to build things features, systems, fixes that solve real problems. Every sprint, I propose implementations, write design documents, and suggest architecture decisions. I explain why a certain approach might work better than another.

Over the years, I’ve often found myself in situations where I don’t have a very strong reason behind the code or design I’m recommending. That’s a tough spot to be in. Because if I say, “This is just a hunch, I don’t have a solid reason,” what others hear is, “I don’t know what I’m doing.” That doesn’t exactly inspire confidence.

But I don’t really have the luxury of doing nothing. A system needs to be built, a bug needs fixing, and that refactor isn’t going to write itself. “What do you mean you don’t have a plan?! You’re the developer figure something out!”

And it’s not just about code. Think about daily life: Why do I like a particular open source project and not another? Why did I use one design pattern and not a different one? Why did I spend my Saturday debugging something instead of going outside? Half the time, there’s no grand reason. We just do things.

But when someone asks why, we come up with the most reasonable-sounding answer that won’t raise red flags. It’s the same at work. I propose a technical approach, and I back it up with reasons that sound logical even if the real reason was a hunch, intuition, or experience-based guess. We need rationale to collaborate. That’s why post-implementation rationalization exists.

For a long time, I felt like an imposter. Was I misleading my teammates people who trust me to write robust, scalable code? Was I even good at this job? Everyone else seemed so sure, so confident. And here I was, trying to justify decisions I wasn’t even sure about myself.

But here’s what I’ve come to realize: conviction comes with experience or emotional investment. But those aren’t always available. Sometimes you’re thrown into a legacy codebase you’ve never seen before and asked to optimize something. Sometimes you’re asked to lead a rewrite when the current system kind of works.

What do you do then? You make the best call you can. You don’t need full certainty. You don’t need absolute confidence. You don’t need conviction. You need a plan. Not a perfect plan. Just a plan. Something to push things forward.

Your design might get torn apart in code review and that’s okay. That’s what review is for. If it’s flawed, it can be fixed. If it’s inefficient, it can be optimized. A rough start is better than no start at all.

In fact, too much conviction can be dangerous. You get emotionally tied to your approach and start ignoring feedback or alternative perspectives. But if you’re not overly committed, you stay open. You listen. You adapt.

The bottom line is this: you don’t need to feel 100% ready to take action. What matters is moving forward. Start coding. Start planning. Start building. Action beats inaction every single time.

Have a bias toward action. Always. Start somewhere. You’ll clean up the mess later.