Brian Casel
Brian Casel

Tomorrow's problems can wait

by Brian Casel on September 27, 2019
See what I was up to that year · Subscribe

Refactoring in programming is when you take a bunch of code you’ve already written and rework it to make it more efficient. This makes it better at solving the problems you’ve uncovered while writing it the first time.

That’s the best practice. For code as well as for business.

In other words, don’t create too much too soon. Only create what is ready to be created.

So what’s “ready” to be created?

Solutions to known, felt, problems. Not solutions to problems that you think might reveal themselves someday in the future.

This is really hard.

Entrepreneurs tend to focus almost exclusively on the future. We find it difficult to reside in the present, and work only on what’s needed right now.

Mix that with the burst of creative energy that comes with a new idea or opportunity, and you’re bound to create too much too soon.

I’ve been there:

You wrote preliminary code that you think will make building those next 5 features in your software easier. Then you learned that 4 of those features never prooved worthy enough to spend development sprints on. Now you’ve got a bloated codebase that’s more difficult to maintain.

You mapped out detailed procedures for how your company would deliver a service at scale—all before you had any employees or clients. Then once those clients do come in and once you bring your first hires onboard, you realize the work calls for a completely different set of processes. So it’s back to the drawing board on getting things back on track.

It’s a paradox, really.

You think that you’re making the future easier by laying a ton of groundwork ahead of the things you plan to build later. But in fact, things rarely turn out the way you initially envisioned. And when things change, those things you thought would be useful later actually slow you down.

The irony is, you’re better off putting most things off.

Write your code in a simple way, so that you can ship your most important feature for your software. Refactor it later, if and when you’ve learned that you do need to add a second or third feature.

Serve your first clients in a way that enables you to figure it out as you go along. Then do it a few more times with other clients. Then identify the bottlenecks, the shortcuts, the efficiencies, and build those learnings into your processes, only once you’re ready to scale.

There’s plenty you can create right now. Just focus on creating solutions to problems you have, and feel right now.

Tomorrow’s problems can wait.