Simplicity Comes from Reduction
Paul W. Homer
“DO IT AGAIN…,” my boss told me as his finger pressed hard on the Delete key. I watched the computer screen with an all-too-familiar sinking feeling, as my code—line after line—disappeared into oblivion.
My boss, Stefan, wasn’t always the most vocal of people, but he knew bad code when he saw it. And he knew exactly what to do with it.
I had arrived in my present position as a student programmer with lots of energy and plenty of enthusiasm but absolutely no idea how to code. I had this horrible tendency to think that the solution to every problem was to add in another variable some place. Or throw in another line. On a bad day, instead of the logic getting better with each revision, my code gradually got larger, more complex, and further away from working consistently.
It’s natural, particularly when you’re in a rush, to just want to make the most minimal changes to an existing block of code, even if it is awful. Most pro- grammers will preserve bad code, fearing that starting anew will require sig- nificantly more effort than just going back to the beginning. That can be true for code that is close to working, but there is just some code that is beyond all help.
??150 97 Things Every Programmer Should Know
?
???????????????More time gets wasted in trying to salvage bad work than it should. Once something becomes a resource sink, it needs to be discarded. Quickly.
Not that one should easily toss away all of that typing, naming, and formatting. My boss’s reaction was extreme, but it did force me to rethink the code on the second (or occasionally third) attempt. Still, the best approach to fixing bad code is to flip into a mode where the code is mercilessly refactored, shifted around, or deleted.
The code should be simple. There should be a minimal number of variables, functions, declarations, and other syntactic language necessities. Extra lines, extra variables…extra anything, really, should be purged immediately. What’s there, what’s left, should be just enough to get the job done, completing the algorithm or performing the calculations. Anything and everything else is just extra, unwanted noise, introduced accidentally, obscuring the flow, and hiding the important stuff.
Of course, if that doesn’t do it, then just delete it all and type it in over again. Drawing from one’s memory in that way can often help cut through a lot of unnecessarily clutter.