I readily admit that I’m lazy.
In my younger days, I would typically grab a pate from the cabinet, serve myself lunch, then leave the plate abandoned in the sink afterwards. On top of discarded cereal bowls, coffee mugs, etc.
It was disgusting. In my laziness, I kept telling myself, “I’ll clean it up later.”
Sadly, “later” was “rapidly before guests come over in an hour.” I’d gotten so into the habit of leaving things to pile up that it became a bit of a sport. How high exactly could I stack things before a soggy slice of toast slid onto the floor?
Breaking a bad habit
Thankfully, this is one of the many habits I’ve grown out of. I’m still lazy – laziness is one of the best traits of any good engineer – but I prioritize cleanliness over comfort wherever I can as I’ve learned its inherent value.
Cleaning things up right now takes a few minutes. Waiting until the last minute snowballs these few minutes into an hour or more and causes further problems down the line.
Knowing how long the task would really take was one of the reasons I kept putting it off; this only made things worse.
Cleanliness is a lifestyle
I have yet to figure out how to make dishes that are automatically clean once they’ve been used – there will always be a mess to clean up later. Likewise, I have yet to figure out how to write bug free code that can ship without follow-up support or refactoring.
Like my college kitchen, many of my development projects have their own kitchen sink overflowing with moldy leftover logic trees or soaked in untestable code. A few are lucky enough to have teams supporting them as opposed to just me, so keeping the pile of putrid PHP from falling over and crashing the system is a bit easier.
All of us grumble about how much we’d like to go back and clean things up. None of us ever do. Instead we write workarounds to allow the program to function despite the heaps of month-old spaghetti at its core.
Cleaning up (or testing) our code in huge chunks isn’t a sustainable workflow. You can’t defer quality, smaller steps are required to keep things moving forward efficiently.
I once worked at a company that took almost 2 months off active development in the middle of a release cycle to find, document, and patch bugs in their codebase. It was an effective bug scrub (closing out several hundred potentially fatal issues), but that kind of effort is unsustainable.
Instead, take a more measured approach to bug scrubbing. Branches in Git are cheap – if a developer sees a bug during feature development, create a new branch and write a patch. This patch should be linked to a ticket, but you’ve effectively got a free bugfix ready to queue up for the next release.
Complaining about dishes overflowing the sink doesn’t get them clean. Griping about untested, unoptimized, or undocumented code in a project doesn’t refactor anything. Taking a few minutes here and there to clean up what you see covered with grime, though, will bring measurable progress to the project.
