What Trade Wars Taught Me About Decision-Making
What global policy and software development have in common: the danger of waiting for the “perfect” solution.
Perfection is the enemy of progress.
This quote has been stuck in my mind lately, especially in light of recent global developments.
It’s simple yet profound—and it's something that hits home for many of us. Let me explain.
Disclaimer: This article reflects personal opinions and observations. It is not intended as financial, political, or professional advice.
How Perfectionism Held Developer Back
As a software developer, Developer takes pride in writing clean, efficient, and scalable code. But sometimes, the pursuit of perfection becomes a silent productivity killer.
Developer has spent countless hours chasing the “right” way to do things.
In those moments, progress quietly dies.
Not because they’re lazy, but because they’re trying to protect themselves—from judgment, from failure, from releasing something that’s less than ideal.
That endless loop of ideation often leads to analysis paralysis.
Each week, there’s a need to write code to build new features—both small and large. And for every task, there are always multiple ways to solve the same problem and write the code.
Instead of shipping code and iterating quickly, Developer often falls into the trap of overanalyzing every approach.
This habit has slowed progress far more than any bug ever has.
What Trade Wars Taught Me About Decisions
Now, zoom out with me for a second.
Look at what’s happening around the world.
The U.S. wants to bring manufacturing jobs back. A noble goal. Jobs have been declining since 1979.
Why? Because manufacturing elsewhere is cheaper.
Not just due to wages, but because of macroeconomic forces like currency strength.
The U.S. Dollar is strong. So strong that paying in USD makes domestic production expensive.
Since the U.S. Dollar (USD) is the global reserve currency, it tends to have higher value compared to most other currencies. That makes it more expensive for companies to manufacture domestically.
It makes outsourcing an obvious business decision. To maximize profit, businesses often shift manufacturing to countries with less expensive currencies. High profit, lower cost.
Some nations even intentionally devalue their currency to stay competitive in global markets.
Overall, It’s a brutal game of chess—one where the pieces are people’s livelihoods.
The Tariff Dilemma
One approach the U.S. government has taken to counteract this trend is tariffs—making imported goods more expensive to encourage domestic production.
However, this strategy is controversial. Some support it, others oppose it.
Like many of you, I don’t have all the answers. I’m not an economist or a policymaker. But I believe it's a complex issue with no one-size-fits-all solution.
There’s no perfect solution.
Have thoughts? I’d love to hear your ideas in the comments.
Lessons From the Code Review Process
In my time at Amazon, I learned a powerful lesson: Don't get stuck chasing perfection.
When writing code, I now pick a strong solution, implement it, and submit it for review.
My team can suggest improvements or highlight flaws—and that’s okay. That’s how we evolve as developers.
The same applies to system design. I lay out multiple options, propose a recommended architecture, and invite feedback.
This collaboration accelerates innovation and avoids decision paralysis.
Nature Is the Only Perfect System
Here’s the truth no one tells you:
There’s no perfect version of anything you’ll ever build.
In reality—perfection doesn’t exist in software, business, or the world at large. Only nature seems to come close.
So if you have an idea, build it. Ship it. Learn from how people respond. Most things—like writing code—are reversible. You can always refactor, redesign, or rework later.
Final Takeaway
Most people are stuck in analysis paralysis.
Still waiting for the perfect time.
Still polishing the idea.
Still researching tools.
You? You’re different.
If you take one thing from this article, let it be this:
Start now. Build. Iterate. Improve.
Your product. Your code. Your blog post. Your new business idea.
None of them need to be perfect. They just need to exist.
You’ll be miles ahead of those still stuck debating the “perfect” way to begin.
Build first. Perfect later.
I send out Master Mentee 🎓 weekly with curiosity and a passion for growth. If you're enjoying it, I'd be grateful if you shared it with a friend who’d appreciate it too.
Not subscribed yet? Join the growing mentee squad of curious minds.
✨ Get the next issue in your inbox:
💚 If this resonated, tap the 💚—it's free for you, but it supports my work and helps Master Mentee reach more amazing people like you.
I really resonated with your point about avoiding perfectionism and shipping good-enough solutions. However, I’ve found that defining "good enough" is tricky and depends on the project’s context. For instance, in personal projects, I’m fine skipping automated tests to move faster, but at work, I invest time in writing them to ensure stability. My rule of thumb is: if a solution can evolve into something scalable and robust later without massive refactoring, it’s good enough. What do you think about balancing speed now versus technical debt later?