There’s a greek proverb: “ουδέν μονιμότερον του προσωρινού” that roughly translates to nothing persists more than the temporary.

When Romans built arches two millennia ago, they didn’t leave wooden scaffolding up after laying the stones, but software, is a little different. Empires rise and fall in the span of months, and temporary often means forever.

• That quick 30-second demo you recorded with wobbly audio? Will be played again and again and again in customer meetings, helping close million-dollar deals.
• That one-off installation Bash script you wrote as a PoC? It will run on thousands of customer machines, usually as root.
• That architectural diagram you sketched on a napkin? Will be repeated in slides and conference talks for years to come.
• That one-off cronjob? Will quietly run for more than half a decade with no complaints.

I’m not defending the practice, but the realization is that priorities change a lot, and oftentimes, 80% of the way is deemed enough — or at least the remaining 20% will unfortunately never be prioritized.

So, what can you do about it? This is not yet another post complaining about tech debt, trying to be a purist, or mocking development practices, but it goes hand-in-hand with one of my core philosophies that caring, even a tiny little bit, is a superpower.

Next time there’s pressure to deliver a quick “temporary” solution, go for a walk, make a fresh cup of coffee and spend 10% extra time on that task before you git push.

Nobody’s gonna bat an eye at that ‘delay’. You might find an opportunity to automate the demo for others to run, test out a new linter, smirk at what the flavor-of-the-month LLM has to say or write a kickass docstring that will be read by other engineers for years onwards. But more likely than not, it will be time well spent on that temporary solution.