Reading Time: 2 minutes

If you’re not a developer yourself refactoring probably doesn’t mean much to you, but read on because actually, it might be something you should embrace anyway!

Refactoring is essentially going back over your code and tidying it up, which I’m sorry to say from my experience is rarely something that gets factored into the time allocated to a project.

It’s no secret that when developing applications we cut corners, copy and paste code from stack overflow and generally do whatever it takes to get the damn thing working. That’s a very normal process and it’s unreasonable to expect the developer to do it any differently. However, what is very important is that the developer goes back over the code and at the very least understands how it works.

This is the bare minimum though, in fact, the developer should attempt to look at their code from an objective viewpoint as if they were sitting down in front of it for the first time if you ask the question “would this make sense to me if I’d never seen it before”, and the answer isn’t yes, you better rework it until it is.
At this point, you might be saying, but I’m a solo developer, nobody else is going to look at my code other than me so I don’t need to bother with that. I’d argue that by the time you look at it next, perhaps in a month, 6 months or a year, you will be a different person almost. There is nothing worse than looking at something YOU did and wondering “what the hell was I doing!?”.

If you happen to work as part of a team or collaborate on an open-source project or something, you need to pay extra attention to the refactoring of your code because you want to make other developers lives as easier as possible so that they will also make yours easy as well.

Should you be somebody who isn’t directly writing any code but instead you are a project manager, product owner etc and you work with developers you should be thinking about how to build in time for this crucial stage with each project. Yes, it will make things take longer and technically less output might be a factor, however, I’d be willing to wager than over the long term the benefit will far outweigh the cost as the developers will need less time to get back into an existing project to fig bugs or build new features.

Nobody writes clean code the first time and one person’s version of “clean” might not be the same as another’s, but if everybody made the effort things could only get better.