Analysis Paralysis

I spent ten years as a software engineer before actually building this blog. I had the idea at least two years ago. But indecision, constant redesigns, and the irresistible draw of shiny new tech destroyed my abilities to create.

It wasn’t laziness that caused my procrastination. The true culprit was overanalyzation. Every time I sat down and thought through exactly what I wanted, it would become more complex. The tech would shift from something reliable to something bleeding-edge. And then back. I couldn’t decide on an exact UI that I considered to be perfect. Despite the fact it was an incredibly simple task, it became an enormous mental blocker.

The Curse of Knowledge

Say one day you decide to build a website. Nothing fancy, just a place to post photos of your latest cat photos. You could throw something together immediately with online tools such as WordPress.

But if you’re a professional engineer, it’s easy to scoff at that. Why use a simple tool like a website builder or a static site generator when you have the skills to build something from the ground up? You need a properly designed web app, built from scratch, using only cutting-edge technologies. A well-built database schema, storing posts, comments, and handling users. It definitely needs some sort of admin panel to write and edit content. Which means it needs authentication, so we may as well invest in OAuth. And it should be hosted on a major cloud platform. Obviously with horizontal scaling. Kubernetes perhaps? And of course, you’ll want CI/CD for automated deployments. In fact we should define the infrastructure as code too. And then we could use Kafka to–

SEE WHAT JUST HAPPENED?!

In a heartbeat, our simple cat photo gallery became an enterprise-grade application, and I didn’t even mention everything that came to mind, like ads, analytics, or anything about the basic user experience. Now, this tiny problem has become a problem that could take a single developer weeks or months to build, before a single cat photo could be posted. Weeks or months that they could spend on something fulfilling, like hiking or playing videogames. Maybe even having a social life (doubtful).

And that is all assuming the plan doesn’t change, which we know it will. Maybe when you finally get a half-decent frontend running locally, you’ll hear about NextJS and decide to rewrite everything. This actually happened to me at some point.

Before you know it, you’ve designed a multi-tenant CRM. And worse—you’ve convinced yourself that if it isn’t flawless, it isn’t worth doing at all.

Is There a Point to Any of This?

Several actually. I had often wondered why I was extremely productive in my career, while being unable to finish most of my side projects. After all, I had all the information I needed in my head to actually complete a project. So why didn’t I? It boiled down to several lessons:

Stick To A Deadline

Just because there is no urgency, that doesn’t mean you can iterate on a singular aspect forever.

Give yourself a scoped unit-of-time, and stick to it. You can always refactor or rearchitect after the core functionality is in place.

Perfect is the Enemy of Good

Every time I came back to the project, I would obsess over minor imperfections, such as styles being rendered slightly different than I expected. Was it good enough? Yes. Would anyone notice it was a few pixels off? No. Yet I would spend hours trying to fix something trivial, when that time could instead be made making major accomplishments.

Learn to leave well enough alone.

Stop Turning Every Session into a Design Review

Every time I looked at my designs, I would rethink my current architecture. Once I had a standard EC2 instance running a basic server, I immediately started thinking about splitting it into microservices. Which led me to consider containerization. Which led to a choice between ECS and EKS. Which led to a choice between container registries. Did I gain anything from this rabbit hole? Knowledge, yes, but there was no tangible progress towards my objective.

It is easy to get entangled in all the recent tech trends, but at the end of the day, the goal is to deliver a finished product. If a suboptimal choice shaves an order of magnitude off of development time, perhaps it was the smartest choice available.

Stupid But Consistent Action is Preferable to Intelligent Inaction

This was my most cardinal sin: instead of just doing something, and improving it incrementally, I often found myself just sitting around and thinking. Locked in inaction. And even when I had a great approach in mind, I would often sit around, thinking of ways that it could be even better, without actually doing it. Would the result be perfect? Probably not. But it would be something. Which is infinitely better than nothing.

And this is the lesson that led me to finally create this blog. This is the reason we all have a low-IQ friend who makes more money than us.

Because instead of seeing every pathway, every option and every potential failure, they just saw the next step they had to take. In some ways, that makes them infinitely wiser than us. And so I decided to follow suit.

I couldn’t decide whether I wanted a space to document my adventures around the world, a tech blog to function as a portfolio, or a mind palace to enumerate my thoughts. But I built something anyway.

I was trapped in “redesign hell” every time I attempted to create the perfect web application. So I used a static site generator in a programming language I didn’t even understand and just hacked until it looked halfway decent.

And I couldn’t decide on anything intelligent to write for my first post. So I wrote this instead.