Software Developers: Don’t Do it Later. Do it Now-ish.

We all do it. Sometimes things come up that we don’t feel like dealing with in the moment, so we say we’ll do it later. Maybe you actually mean that at first, but then time passes and priorities change. Then, the next thing you know, it’s been days, weeks, months, and that thing we said we would do still isn’t done. Often, to make ourselves feel better about procrastinating, we create this narrative about how busy we are with other important things. Yes, that’s true sometimes, but that doesn’t change the fact that our task was never completed.

For me, that lingering feeling of a task being on the backburner takes up too much mental real estate. So recently, I’ve started challenging myself not to do it later, but to do it now-ish.

When is Now-ish?

Well truthfully it’s not now, but it also isn’t later. Now-ish comes after what you’re doing now, but don’t let it fall into your understanding of later (because you won’t ever get around to it).

I know, that’s vague and confusing, but hear me out.

Three Types of Actions

There are three types of actions that impact whether or not you will actually “do it later.” They are as follows:

1. You write it down – Use a planner, sticky note, or an app on your phone.
2. You have faith in your memory – You genuinely believe the task will not slip your mind over time.
3. You simply say it aloud – You are likely indicating the de-prioritization of the task and probably won’t do it at all, honestly.

In this framework, I’ve ranked actions from top to bottom by the task’s visibility. In my opinion, the odds of any task being fulfilled are directly tied to how visible the task and its outcomes are. When work is visible, it’s harder to push off. That’s because there are more opportunities to be reminded (and annoyed) that the task has not been completed.

Some people truly have a great memory and will follow through – but our memory is a resource, and it is subject to limiting factors. Things like cognitive load, age, stress, and fatigue are simple, everyday factors that can strongly influence our ability to remember and be motivated to do anything.

Simply put: The longer a task lives in your head, the worse the odds of it becoming visible are.

Technical Scenarios

In software, I see these actions most often arise in two scenarios.

Technical Debt

It’s almost impossible to avoid technical debt in a project ecosystem. The term has a negative connotation, but I would argue that technical debt itself isn’t always the issue – it’s the way we treat it.

When we cast technical debt aside, or believe it’s something we’ll simply remember to address later, no course of action is formulated. Over time, as the debt compounds, the amount of effort it takes to make a noticeable difference has significantly increased. When we deprioritize technical debt, we give it the potential to become our worst case scenario – doing it never.

A more intentional approach will better your odds of decreasing technical debt and avoiding some of these issues altogether. Aim to take action now-ish. Technical debt won’t dissolve overnight, but intentional actions will help to expedite the process.

When you notice technical debt, make a physical note and mention it to your team. Build a team habit of doing this, and identify a meeting space where everyone can share thoughts or findings. In the end, any artifacts from this meeting can make it into sprint planning, allowing debt to be tackled more intentionally.

For large efforts such as reducing technical debt, act now-ish to build momentum and make the work more manageable for yourself and the team.

Documentation

This is something we generally put off as developers. It’s boring work, and we generally don’t have to feel the effects of not having documentation…until someone really, really needs it.

I would be lying if I said I wasn’t a perpetrator of this behavior. When I hit flow state, I’ll go back to write those inline comments…right? Surely updating the README can wait, our team rarely ever changes that much…right? Everyone on the team still remembers exactly why this feature is in development because they were at the meeting a few weeks ago…right?

Wrong. The truth is, you can never really have too much documentation. In my opinion, it’s the one of the ultimate safeguards for software development.

You might remember everything now about the code you’re writing and why you’re writing it, but one day you won’t. The context will be lost as the project evolves – unless it’s written down somewhere. Project team members may need that context for onboarding or understanding the work in specific areas of the project ecosystem.

The last thing you want is to build out an entire feature or application and then spend time going backward to write documentation for areas of the application that you lost the context to. Just do it now-ish, and avoid the headache.

Take Initiative Now-ish

You might not have the capacity to take action immediately, and that’s okay. Just don’t let yourself fall into the trap of “I’ll do it later.” Make the work visible, and give it some good old-fashioned pressure from the calendar.

If you want something to get done, act on it now-ish.