As a kid (I must have been 13-14 years old), I actually saw one of my friends getting hit by his own boomerang from behind while he was searching the sky (ahead of him, ignoring 180 degrees of his surroundings) where it had gone. In addition, he ignored our warnings…
Almost all the time delays in coding are the result of some short cut that I took before and did not bother to fix.
I learned the same the hard way in my early days at McKinsey as an analyst, when I was building spreadsheet models. Just before the presentation, your manager would come and require a quick change in the numbers to reflect a new insight (or complication). In the end, the numbers that count are the ones on the PowerPoint slide, not in your model, so the changes were easily made.
But after the presentation, the adrenaline levels dropped and there was no immediate need to mop up that spreadsheet. Mistake, because by the time the next presentation came along you had no way to get everything consistent again.
So, quick fixes are fine, just clean things up quickly afterwards to be ready for future changes. As an analyst, you control the numbers with your model. If people don’t agree with the outcome, and/or feel it does not makes sense (unfortunately senior people have a good nose for this), something inside the model has to change, to reflect that insight. Simply overriding the output cells will work for one presentation only.