For the past 20 years I’ve been building web and mobile applications on and off. This journey has brought me through numerous languages and projects.

Perl, PHP, Ruby (and Rails), Python, Objective-C, Javascript, and more. A social network, music commerce site, text book search engine, photo sharing site, note sharing application, mobile texting application, blogs, social media tracking system, email service provider, loan servicing platform, and more.

Each day of coding reveals just how much more there is to learn. It’s easy to feel like you aren’t learning anything when infinite knowledge remains.

That said, in 20 years of development, I’ve learned countless ways to build things the wrong way. In this short series I want to leverage these experiences to explore the concept of a “correct way” of building things. What truly makes “great code”?

This article is the first in that series.

And God Said, “Hello World!”

Fundamentally, coding is straight-forward. You take some inputs and generate an output. It’s from this formula, inputs -> code -> output, that an idea can manifest into something useful. Done correctly, code is pure magic.

This magical aspect of code inspires thousands of people each day to dive in and learn. From those, the most determined succeed at building something. A lucky few will produce a product or feature people actually use.

To join the elite club of product craftspeople who force a utility into existence is for many developers, the source of motivation and inspiration.

So for those who dare to dream, what does their code look like in the beginning?

In short, it’s ugly.

The individual behind the code should not be faulted for the disaster they’ll inevitably create. The outset of coding feels unnatural. Unless you think like a computer, which a surprising number do, any introduction to code tends to feel overwhelming. It’s as if you are being taught how to use Rockwell’s Retro Encabulator.

It all sounds like gibberish.

Yet given a desire to build something from the invisible, a few will persist. Fortunately for these individuals, the quality of code doesn’t matter at all. In fact, one should be slightly skeptical of a new project that contains 100% legible code.

All that matters is that the person writing the code can read and understand it. This is due to the majority of projects ending in failure. Even if you manage to get a product out the door, there’s no guarantee people will want what you built. The odds are that few people beyond your friends and family will have any interest.

The beauty of this whole scenario is that thanks to market forces, both novices and experts have similar odds of success. Granted, I’d prefer a 7% chance of winning versus 4% but both are awful odds.

In this glimmer of hope is where we begin our story.

“My Server Is Crashing!”

Last weekend in a moment of randomness, I received an alert for somebody looking for assistance with a new Ruby on Rails application. Overnight, the application they developed had gone viral and the popularity was taking down the site.

It was late in the evening when the creator, Dolf, who is based in Germany, hopped on a Zoom call with me. Soon after introducing ourselves I said with genuine enthusiasm “Congrats! Seems like you have a hit on your hands!”

Dolf, a full-time business consultant and self-taught coder, had created multiple passion projects in the past yet none had any measurable success. This was the first time and he wasn’t quite sure what to do. Hundreds of people were visiting the site and his clever game design was keeping people engaged.

Dolf was absolutely convinced that his code was awful and the source of the crashes. As I sat with him attempting to diagnose the problem, it became clear to me that the code was likely not the issue.

My hunch was not just based on an analysis of his “unoptimized” code but also based on experience. Even the worst code is surprisingly resilient. That’s because computers do everything we tell them to.

In the case of Dolf, it took me an hour of assessment, an hour of persuasion to use a different system, and about 20 minutes to switch to a more reliable and convenient platform.

For those who know web development, all I did was move Dolf’s Rails application from a convoluted AWS configuration to Heroku. For any new web developer, I always suggest using The Kamal Stack.

While Dolf is not a trained developer, he managed to read some tutorials and piece together a product that thousands of people enjoy.

Maximum Viable Product

I’d like to contrast this story with a more personal one.

9 years ago I started a mobile app company out of my apartment in San Francisco. I had just sold a company and was flush with cash and confidence.

At the time, I was ready to invest whatever was necessary to build a mobile application. As I jokingly told my friend Dan Martell at the time, we were going to build a “Maximum Viable Product”.

Ironically, there was nothing maximum about it. We managed to build a full fledged iOS application for under $60k. The majority of the budget was put toward the name of the application, Holler, and rent on an overpriced San Francisco apartment.

Not included in this cost was the time I spent developing things. I had purchased the “best hosting” and designed my “system for scale.” I spent weeks and months obsessing over the ideal way to structure my code.

In the end, none of that mattered! Despite attracting tens of thousands of individuals, we decided to shut it down as it didn’t meet expectations.

The “Right Way” To Code

I mentioned that this series is about the “correct way” of coding things and that this portion is about the beginning phase.

When all software projects start there is really only one thing that matters: speed. Personally, I’ve observed countless projects become encumbered by knowledge and experience. Without frameworks for rapid development, experienced programmers and teams become stuck on the things that matter far less in the beginning.

This is why I find that ignorance is actually an asset when you begin. This phenomenon is effectively articulated by Paul Graham:

My Y Combinator co-founder Jessica Livingston is just about to publish a book of interviews with startup founders, and I noticed a remarkable pattern in them. One after another said that if they’d known how hard it would be, they would have been too intimidated to start.

Ignorance can be useful when it’s a counterweight to other forms of stupidity. It’s useful in starting startups because you’re capable of more than you realize. Starting startups is harder than you expect, but you’re also capable of more than you expect, so they balance out.

Anybody who has made it through the trenches of building successful software products will attest to their difficulty. Yet the confidence found on the other side, when “success” has been accomplished, can easily backfire on subsequent projects.

All of the lessons learned through late stage projects get adopted into new ones, smothering them before they even have a chance.

With this knowledge, I can confidently present the “right way” to code when beginning a project. Code as quickly as possible, not in a way designed to scale.

In contrast to a maximum viable product, this approach will ensure you get something out the door and can test it with the market. If all goes well, you’ll make it to the next piece in this series.