When Your Code Comes Back to You...

Go through your code and follow the business logic.

Whenever a question or doubt arises, there is potential for improvement.

Your Code May Come back to You for Various Reasons

• The infrastructure, environment, or dependencies have evolved
• You want to reuse your code or logic in another context
• You need to introduce someone else or present your work before a wider audience
• The business requirements have changed
• Some improvements are needed
• There is a functional bug; etc.

There are two, equally valid approaches here — either you fix the issue(s) with minimal effort and move on to the next task, or you take the chance to revisit what you have done, evaluate and possibly improve it, or even decide it is no longer needed, based on the experience and knowledge you have gained in the meantime.

The big difference is that when you re-visit your code, you improve your skills as a side effect of doing your daily job.

You may consider this a small investment that will pay for itself by increasing your efficiency in the future.

A Few Examples

• Why did I do all this, where can I find the requirements?

Developers often context switch between unrelated tasks — you can save time for onboarding yourself and others by maintaining better comments/documentation.

A reference to a ticket could do the job, especially if there are multiple tickets. If possible, keep the requirements together with your code, otherwise try to summarize them.

• Hmm, this part is inefficient!

In many cases this happens due to chasing deadlines, blindly copying code around, or not considering the real amount of data during development. You may find yourself retrieving the same data many times too.

Writing efficient code always pays off by saving on iterations to improve performance. When you revisit your code, you may find that there are new and better ways to achieve the same goal.

• Oh, this is brittle — my assumptions may not hold in the future!

"This will never happen" — you have heard it so many times at all levels of competence. No comment is needed here — a good reason why you should avoid writing brittle code is that you may want to reuse it in a different context.

It's really hard to make no assumptions, but when you revisit your code, you should do your best to make as few assumptions as possible.

Also consider that your code may run in different environments, where defaults and conventions may differ — never rely on things like date and number formats, order or completeness of data, availability of configuration or external services, etc.

• Oops, it is incomplete — it only covers a subset of the business requirements!

You have no one to blame — this is your own code. Don't leave it incomplete, because it will come back to you and that always happens at the worst time possible.

• I'm lost following my own logic ...

You definitely hit technical debt — and technical debt is immortal. As you develop professionally, you start doing things in more standard and widely recognized ways, so they are easier to maintain.

It is quite tempting not to touch something that works. However, remember that, even if it works, it is only useable in the present context. Unreadable code is not reusable, not to mention it is hard to maintain.

Fighting the technical debt pays by saving time and effort by allowing you to reuse code and logic.

• Uh, it's so big, it will take too much time to improve and I don't have enough time right now!

Yet another type of technical debt. In a large and complex piece of code, some parts may appear unreachable in the actual context, making the code even less readable.

• This could be a problem, but nobody complained so far, so let's wait...

Don't trust this line of thinking. The complaints will always come at the worst times.

Summary

Even when it isn't recognized by management or your peers, the effort of revisiting your own code makes you a better professional, which in turn gives you a better position on the market.

Additionally, keeping your code clean and high-quality is satisfying, without the need for someone else's assessment — and being satisfied with your work is a good motivation to keep going.

For myself, I would summarize all of the above in a single phrase — don't copy code but revisit it, especially if it's your own.

It's like re-entering your new password when you change it — it can help you memorize it better, even if it's easier to copy and paste the same string twice.

Nothing stops you from doing all this when developing new code too.