Value of Destruction

During the first year or so of my programming voyage, I bumped into many roadblocks. Some algorithms were broken, this method didn’t do everything that I wanted it to, that class needed refactoring, and other such hurdles were common. I was afraid to modify certain parts because I thought that that was the only way to do it, and if I changed or deleted it, I’d be wasting unnecessary time. But I always ended up with a better and more elegant solution when I just erased the darn thing and started over.

It’s not always about fixing what’s broken. It’s about starting over and forging something better.

I think the reason why I had this fear of deleting code and starting from scratch back in the day is because I thought only parts of my code were incorrect, and thus finding the erroneous portions and deleting them would do the trick. But, you see, that is the trick—find what’s broken, then fix it. But there’s a catch: previous code tends to cloud your perspective. Therefore, any headway you make is consequentially tethered by prior thinkware; past assumptions ultimately are not conducive to novelty. This is bad and you may very well end up at a worser place than you were already in. I cannot remember a time when destroying code and beginning anew hasn’t been beneficial.

I’ll provide a personal anecdote: when I first started designing API, I wanted to make it as good as possible without ever touching it again. But as anybody with experience in architecting API can attest to, it’s not an easy task—in fact, it’s almost impossible to get it right the first time! You’re bound to scrap and rewrite much of it. But as a stubborn rookie, I was relucant to start over. However, once I overcame my pride and rewrote it, it turned out much better. I just had to admit to myself that it sucked and needed to be discarded. 

So cast away the anchor of familiarity and don’t be afraid to start over from scratch once in a while. Ironically, you have more to gain than you have to lose.