(^150) 97 Things Every Programmer Should Know
Simplicity Comes
from Reduction
Paul W. Homer
“DGAO iT A iN...,” 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.