“Later” Does Not Exist

All of a sudden, an idea hits you. For example, writing an article about why the concept of “I’ll do it later” does not exist in the contemporary world. Then you decide to do that “later.” Then, you realize “later” is a synonym for “* never*” and start typing on your mechanical keyboard just 20 minutes before midnight.

Why? I’ll get to that later real soon.

But before that, let’s think about what “later” is.

What Does “Later” Mean?

What is “later”?

Maybe it’s adding a “temporary hack” to be removed later. Perhaps it’s removing a bug, introducing a lower-priority bug, and deciding to deal with it “later.” Maybe it’s temporarily breaking some test cases to deliver an urgent hotfix. Or maybe it’s stashing away your current work, to hack together a last-minute customer proof-of-concept, knowing that you’ll have time to get back to your work “later”.

Consider the actual consequences of your decisions: Are you honest with yourself? Are you going to get back to that “later”? What if other emergencies arise and you don’t? What kind of risk are you introducing?

“Later” Has Many Forms

There are other forms of “later,” too:

  • The most popular one: “I’ll fix it later.” Srsly?!
  • Or, “just add a quality gate exception; I’ll add the unit tests later.”
  • Or “I’ll discuss this feature with a greater audience later.”
  • Or “We can worry about security/performance/reliability later.”
  • Or “The code is working as is; we can make it more readable later.”
  • The list can go on and on…

Yet, more often than not, what you mean by “later” is “never.”

Because when you cut corners and create an illusion of making things faster, you are giving the upper management, project managers, product owners, and your customers a false sense of how quickly you deliver.

Rest assured, knowing how awesome you are at things, they will be expecting * more* of it—that is a self-feeding cycle: There is remaining work, and you need to talk about it. Yet you do not. Hence comes more work!

In essence, you are effectively lying to your stakeholders ad infinitum: Next time, you’ll be overloaded with more work; you’ll cut more corners. You’ll deliver much faster and be overloaded with even more work.

Later will NEVER come: You will start accruing a $#!% ton of technical debt.

Set Realistic Expectations

The best way to reduce technical debt (and, by extension, increase technical wealth) is, to be honest, and set realistic expectations.

You are not finished with a feature until it meets the “definition of done.” A definition of done can include things like:

  • Is the feature tested?
  • Do key stakeholders verify it?
  • Is there documentation?
  • Did we do a usability test?
  • Does it pass the performance benchmarks?
  • Is it peer-reviewed?
  • Is the code readable, duplication-free, and bug-free?

Time is Candy

You know what, that doesn’t only happen at work. It happens in your daily life, too: When was the last time you added an article to your “read it later” list, and you actually read it?

It all boils down to time.

Time is your most precious asset because you cannot recreate it: Once you spend it, it’s gone. So the only way to do enough things in the amount of time you have is to be selective and do less.

Have priorities. Review often.

☝️ That’s the only way to stay afloat.

Later 👋.

Section Contents