During a software engineer career, everybody faces the problem of dealing with the code they’ve written a long time ago. So was I. And recently this happened to me.

So, at my job after working on a new project for a couple of months, I returned to the old one to add a new functionality. I’ve looked at my old piece of code and was shocked by how unskilled I was when writing this disaster. Immediately I noticed that it can be (somewhere should be) modified at every 10th line of code.

And at first, I did exactly this - I began to change every line where I observed some kind of slow-performance code, bad architecture design, misnaming of variables and functions, etc. So, when I finished doing it after 3 hours or so, I was truly glad that I “fixed” it. But after 10 seconds of pure satisfaction from done work, I thought: “Wait, was it my task? Why did I spend roughly half of a working day on refactoring the code just because I wanted or decided to do so?”.

Look, I mean that it’s not a problem to notice bad decisions in your old code. The problem is to fix it right away in cases when: 1) it takes too much time to refactor it and 2) you do it at will (without informing your colleagues/managers and without thoroughly reflecting on the priority of doing it now). Therefore, I think that it’s okay to refactor your old code only if: 1) it would take as little time as possible or 2) you discussed with your colleagues that it would be good to do so and you add refactoring as a task.

An important note, I look at this from the perspective of writing your old project solely. If an old project was written by you and some other programmer, and you noticed a thing to modify - it’s up to you alone whether to change it or first discuss it with him/her.

Growth - a topic that correlates with what I described above. Namely, the growth as a software developer/engineer (whatever you call yourself). I believe that looking at code (not only yours) and noticing different mistakes there (or wrong/inappropriate ways of achieving a desired result) will certainly improve you as a programmer. This process is required for growth.

If only we have a chance to indefinitely improve our code - we would do it forever because every time we look at the code we come up with (mostly better) new algorithms to solve the problem, new names for classes/functions, new architecture decisions, and so on. And it’s fine - it just means that we learn and become more and more proficient in our craft. But you should never stop on your one project or one piece of code. It’s vital to keep going, learn from your mistakes, and apply knowledge to new projects.