Why You Should Be Deleting Your Code

Programming is a very dynamic field for the most part. Hundreds of languages, hundreds of frameworks, millions of people. But essentially, it all comes down to the same thing. Typing relentlessly until the right side of the equation is balanced. Adding function upon function and if else upon if else until criteria A has been met. Some companies love it. But even more live by it. I've worked for companies that have based raises and salaries on the amount of code being produced monthly by a developer. Many of those companies are no longer in business. And that's because very few would ever put up with a developer deleting lines of code. We get stuck with these paradigms about programming sometimes and we can't see any other alternative. And maybe it's time we start to change that.

Code deletion is crucial for a stable and scalable software system. And the reason is very simple. Tomorrow you will be a better programmer than today (hopefully). You will have learned many a thing on your journey and it will undoubtedly replace knowledge from the past. And in a year, what you wrote today will be unusable. It'll probably be double the size of what your new found abilities have allowed for. And you won't be able to fix it with a line of code. You'll have to fight through the trenches to work your new code into the old. And that can be a costly and stressful endeavor to partake in.

And let us not forget that technology changes constantly. Just a few years ago I was using 4 jpg's to render corners on a div. Kids nowadays won't understand that. But it's something that plagued every single one of my sites. So what was the solution after CSS caught up? You guessed it. To start to delete code. But more than just code. Delete CSS that's unused. Delete JavaScript files that are ignored. Delete, delete, delete. If it's not being used, it's for a reason.

What do you do about it

When I say delete your code, I don't mean dive in to your repo and start to highlight and backspace repeatedly until you feel better. I mean delete your bad code. It's there. You just have to find it. Maybe you have a function that copies 90% of the functionality of another. Maybe (you do) you have unused code lying around cluttering up your thoughts when you begin to work. I had that recently on a very large and complex JavaScript application. It was about 1700 lines of pure JavaScript taking me on a wild ride whenever I wanted to make any changes. Just deleting unused functions, pushed me down to 1500 lines, and refactoring other functions got me down to about 1300. Still alot, but many times more manageable.

Knowing that you're going to be deleting your precious code one day, modularize as much as possible now. Separation of concerns is still an important concept that many programmers ignore due to their hectic schedules and deadlines. But when you have a RenderList() function, that calls RenderItem(), which in turn calls however many other functions, you're in a much better place to start to make changes in a black-box fashion. You can create a brand new RenterItem2() and play around with logic there, without yet touching your current code. And I'll get to that fear and uneasy down below, which is also a problem.

Don't take it personally.

When you write code, it's suppose to be amazing. Ideas are flowing and you zone out and minutes turn to hours and hours to day. And at the end you create a shiny new entity that performs some function. So when you delete said code, don't take it personally. If you like a function you wrote, centralize it somewhere and keep it. But don't leave it in your code unused, or comment it out so that you can stare at it for all of time to come. You're going to see that commented out one day, and start to wonder why it's commented out. And if it's needed anywhere. And you'll probably add a comment stating so, to remind your future self. And your future self will delete that comment.

and don't be afraid

I think every developer will face a challenge with this last one. No matter how many years of skill you have accumulated under your belt, it doesn't prepare you for thousands of lines of your old code. Where do you begin? Do you begin on top and work your way down? Probably not. That's not how you coded it probably. Same goes for going in reverse. It's daunting to say the least. And normally, you talk yourself out of stupid things and decide you'll go have coffee instead in lieu of the next few hours of torture. And all I can say here is, I don't blame you, but also don't be afraid.

Yes, you will break things in the process. But you will fix many more. And once you get over that initial fear, the code will make sense. Once you get rid of the clutter, you can then start to see the logic better and then you can start to work your way around the system, not from a top-down or down-top perspective, but from what a C -> B -> R -> D -> wherever else it needs to go perspective. This is a part of being a programmer. It's a fun and interesting part, and one that doesn't get much attention from either the workplace or from educational institutes.

Knowing that you will one day have to delete your code will also help you become better at programming. You'll stop seeing your code as perfect and the epitome of codedom, and you'll see it for what it is. For getting from point A to a point B taking an arbitrary road C. And one day you'll find your road R and realize it's a much smoother and faster ride.