I’ve written plenty of code thinking, “I’ll clean this up later”. Sometimes I do. Sometimes I never get back to it because something else becomes more important. That’s just how real projects work. You fix what needs fixing, ship what needs shipping and move on.
I don’t think that’s automatically bad development. Not everything needs to be perfect from day one. In fact, spending too much time polishing something that might completely change next week can be just as wasteful. The problem starts when that temporary fix stays there for a year and nobody remembers what problem it was solving.
That’s when things get annoying. You find a strange condition, a duplicated query, a bit of logic that makes no sense. You remove it because it looks useless, then something somewhere else suddenly stops working. Now you’re digging through old commits trying to understand what happened six months ago.
This is why I care more about context than clever code. Most of the time I can understand what a function does by reading it. What I really want to know is why someone chose that approach. A short comment or a decent commit message can be far more useful than another layer of abstraction.
AI makes this even more relevant. It’s very easy now to generate code that works, but that doesn’t mean you understand it. If I put something into a system I expect to maintain, I still want to know what’s happening in the important parts. Otherwise I’m just creating a problem for future me.
I don’t care much about perfect code. I care about code that I can come back to after a year and still understand without swearing at the screen for half an hour. Temporary fixes will always exist. That’s fine. Just leave enough context behind so they don’t become mysteries.
