Stop Coding What Already Exists

As developers we like to write code. Code becomes the tool for every job.

We’re opinionated about our code. We all have special ideas about what’s right and wrong. Some of these ideas are justified, while others, are just pet peeves and poor assumptions.

As such we tend write our own solutions for everything that doesn’t strictly line up with our personal standards. “There’s no good invoicing apps” is an example of a common phrase thrown around by devs everywhere. So, as developers, with an unlimited toolset we start on mission to build the perfect invoicing app.

As a business owner I can’t stand this part of myself. I want perfect tech but I also want to focus on the hard-hitting, high-level business tasks that will make my business grow.

As a technical founder, I can easily say that most of the time I could have spent growing my business, I often threw away on coding things that already existed.

A good friend of mine said: “All of the basic tools are already built, all you have to do is connect, integrate and patch them together.” This was an epiphany I had way too late. One that costed me a hundreds of hours, and in turn, money lost from not focusing on the business.

The Myth of Ugly

Of course, I can hear devs everywhere saying: “But I want a stable solution that doesn’t break constantly. Duck taping all of these services together is really ugly.” The assumption is that if we build it, it’s going to be perfectly tailored to our needs, well designed and not be an “ugly mess”.

The word “ugly” is used too freely with developers and instead of labeling something by appearances we need to focus on priorities. Ugly can mean ugly security-wise, ugly in terms of best practices, ugly in terms of “this will break every 5-minutes”, ugly as in “I don’t have full control over it.”

The greatest fear is that we’ll make a big mess and have to maintain it later. But it’s rarely the case in my experience.

I get flack for using Wordpress by other devs. But it’s saved me more time than all of the other CMSs I’ve used. I have literally 10s of thousands of plugins at my disposal that saves me 10s of hours of writing each feature myself.

Instead of maintaining an email server, I signed up for Mailjet (it only took 5 minutes).

Handling invoices and dunning emails are easily taken care of by integrations.

By spending a few dollars here and there I’ve saved myself years of stress and extra work.

I’m not picky about tech. As long as it does the job well. And because tech can be so complex, finding external services to handle deployments, CI is a no-brainer.

The Real Cost of Custom

When was the last time you built perfect software, and never looked at it again? Can I guess… never?

There’s always extra overhead for custom solutions. You have to host it, keep it updated, fix bugs and hope it doesn’t break on the next server upgrade. Oh..and also, this goes on for years. All of this translates into time and energy taken away from your core product. You know, the one that makes money?

How much does that run of the mill invoicing software cost? $50/mo? $100/mo? Mine costs around < $50/mo. I don’t maintain it, I don’t fix bugs in it and maybe once a year it goes down for 15 minutes for maintenance. Does that matter? Most of the time I don’t know it even exists.

No matter what business you’re in, you can easily see how an investment of $50, in return for even just a hand full of hours and years of on/off maintenance, is a no-brainer.

Writing code can take a few minutes. Maintaining that code can take years. Getting to the point of sleeping well at night, who knows?

99% of solutions out there are secure, cost effective and have excellent uptime. They’ve been built for tougher use cases than yours. What more are you looking for that’s worth the mileage of re-writing something that has already been done by companies that specialize in it?

Get to Good Enough

No solution is ever perfect. Especially in business. That said, there’s always a hack. The hack doesn’t have to be insecure, illegal or slow. It just has to save you more time than doing it yourself.

Good enough is way too underrated. OCD-driven devs don’t like to compromise. But let me tell you, everything you value depends on it!

Redefine Ugly

Ugly is not a scripting language you don’t like or too many dependancies. Truly ugly tech stacks are ones that fail to get deployed on time, that don’t allow developers to quickly deploy new releases to the masses, that promise but don’t deliver, that are too slow.

The most ugly software is the one that hasn’t yet been released, as it serves no purpose to anyone.

Tech Doesn’t Really Matter

100 years from now most of this tech will be outdated, depreciated and tossed out. Most of what you write right now is fluff. Not only because you’ll end up tossing most of your code, but because technology moves so fast what you write now will probably stay part of it’s era. The first lightbulb was built by hand and was garbage but it worked. Now days, lightbulbs are a commodity, but we still praise Thomas Edison (or Tesla) for being the genius behind it. They didn’t care about standards or upgrading to LED. They just needed to get it out. And it worked for their day and age.

Most of us aren’t inventors. But we are all trying to do something significant. Be it, build a profitable business, serve humanity in some way empower the future generations, build robots, whatever.

Sadly, a great many of us are not building anything grown-breaking, but rather re-building and re-building things that are worth pennies but necessary.

At the end of the day nobody cares if your site is done in CMS Y or CMS Z or if you used PHP or Python. They don’t care if you think Node.js is better than Erlang.

You aren’t paid or remembered for any of these things. The only things that matter are, 1) are you providing value to something besides yourself and 2) is your technology easy enough to continue deploying to the masses over and over again.

Build For The Customer, Not Yourself

We write unit tests so the customer doesn’t see a blank page, we use things like Kubernetes to avoid downtime for the customer. We choose our tech stack to be quick and agile so we can deploy new features to the customer. If the customer goes, we can hit `rm -rf *`on the whole damn repo.

If we build for the customer instead of ourselves the business aspect of what we’re doing makes a lot more sense. That way, we can make more money, invest it in things that save us time, which allows us to spend more time on serving the customer.

When we build stuff that already exists, we let down ourselves, our customers and everyone else involved in our business.

So let me once again drill down to my message: Stop rebuilding stuff that already exists! Stop hurting yourself and everyone else.