97 Things Every Programmer Should Know

Chapter 75. 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 programmers will preserve bad code, fearing that starting anew will require significantly 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.

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 ...