Myth of the JavaScript Refactor

It’s Christmas Eve, everyone around the office has gone home to be with their families, while you are struggling to finish up the pile of work that your boss has assigned you. You stare at the code having little to no idea as to what the heck the person before you was thinking when they write this code. You trace through one method call to the next learning as much as you can while trying to solve the problem so that you can go home to you family on time.

At last, you are finally able to debug the problem, so you whip up something together very. Finally, you found a solution to your problem and made it work. However, you realize though that in the last four hours, you made a complete mess of yourself. All those print statements and console logs and redundant comments, not to mention the hack you implemented which made the original code base even messier. So much for your New Year’s resolution for next year right?

The clock strikes 9, you haven’t eaten anything since lunch time, you are tired and you just want to go home. So you say, "F**k it, I’ll make a mental note of this and go back and clean the code up after I come back from New Year’s break. As long as it works now", a little mess can’t hurt right?

“At least I know that this code is "bad" and I am willing to go back to fix it. I’ll tidy this code up right after I’m back from break”. And that what they all say...

When have we ever said those exact words in your head? "I’ll clean this up later" or "I'll remember to tidy this up once I’m done". Let’s face it, when you are under pressure to do something, you just want to get it done and get it over with and never touch it again. When the next day comes, and your boss bombards you with another pile of work, you won’t have the time to refactor old code.

So when do we actually go back to "refactor" our code? The answer is almost never. Once the code is written and you’ve put off the refactoring to another time, the next time you see the code will be the next time your boss asks you to work on the same code base that you left off.

Those of us who work a normal day job at a regular company all go through this cycle. Your boss gives you task, you complete the task, only to realize that you tampered through 10 different files with little bits of debugging code and quick hacks that going back to clean things up could possibly break the functionality you worked so hard to make work. So why break something if it’s already fixed? Let’s just keep this spaghetti code in there, I know how it works so it’s all good.

And you know what I always hear everyone easy? "This code is garbage", "How am I supposed to work in this huge pile of junk?"", "What was this person thinking when designing this?". The funny thing is that most people who say those things do just that. I complain all the time about the mess that the previous guy who worked on the code before me made, when in fact I start making a mess myself when working on the code. I don’t know about everyone else, but there’s always a little bit of guilt when it comes to me leaving code off to the side for refactoring, only to know that I would never touch it ever again.

In conclusion, Refactoring is hard. Some would say it’s even a myth. But kids, think about the next person in line that has to deal with your sh*t. No one’s harping over you to make your code look pretty, but make it easy for the next person in line so they can go home on time.