I found an article - https://qntm.org/clean - reviewing the Clean Code book, and really enjoyed it. Two paragraphs in particular jumped out at me:
So... imagine that someone enters a kitchen, because they want to show you how to make a cup of coffee. As you watch carefully, they flick a switch on the wall. The switch looks like a light switch, but none of the lights in the kitchen turn on or off. Next, they open a cabinet and take down a mug, set it on the worktop, and then tap it twice with a teaspoon. They wait for thirty seconds, and finally they reach behind the refrigerator, where you can't see, and pull out a different mug, this one full of fresh coffee.
...What just happened? What was flicking the switch for? Was tapping the empty mug part of the procedure? Where did the coffee come from?
That real world analog nearly perfectly captures the kind of side-effect-ful and hard-to-follow code that is pervasive in industry.
So what is the takeaway?
I think the application is this: everyone has written garbage like that before, and I think the way you fix it is that you (1) take more time to plan and design your implementation than you otherwise might, and (2) closely review each module and function for any cruft and remove it when you find it.