How to code for the future

Most mid-level engineers make the same mistake when coding for the future: coding at all. The trick to coding for the future is to not code at all.

Why code for the future?

Taking a big step back, when we code for the future, it’s because we want to make sure our future selves don’t have more work because of bad decisions today. We’ve all accidentally made technical debt that made extra work for ourselves. But many times, we’re so worried about the future, we overcorrect. We make the mistake of trying to predict the future so correctly that we code today so that tomorrow is less work because of good decisions today. That’s way more than we need to strive for, and it’s extremely difficult. Instead, let’s just shoot for “not more work” by not making tech debt.

How to not code for the future

This means, we should write code that doesn’t box ourselves in and STOP. You don’t need a general framework or abstract class or generalized method with 10 parameters. Don’t write code that tries to predict. Instead, just avoid spaghetti code. Make sure interfaces, protocols, and data formats that are upgradable to handle future reqirements. Make code easy to change, cause you’ll need to change it as you get feedback from users. Don’t use hard limits that can be reasonably hit(like ipv6 which has 2^128 addresses). Don’t intercouple the code, don’t abuse global variables.

Reusable programs

You’d think there’s an exception to the rule of not trying to make tomorrow easier: building reusable programs. When we solve today’s problem by writing a reusable program, then obviously, when another similar problem appears, we don’t have to rewrite, we can reuse! So, we might think, when writing a program, we should try to break out the reusable parts into independent programs, or at least indepedent libraries that we can reuse from the beginning.

But usually, no. We should focus on shippping the first program.

Instead, we should first solve the problem, and then if another similar problem occurs (or we want to share the reusable program with others), only then, we should refactor the first program, extract out the reusable program, and use it in both places. Just make sure the code is written so that this is easy (see this blog post on how).