2 ms·
ugly hacks, assuming decent programmers, is usually a result of not knowing exactly what you are writing when you first start. This is common, and often it's no
by jshen 16y ago
ugly hacks, assuming decent programmers, is usually a result of not knowing exactly what you are writing when you first start. This is common, and often it's not worth refactoring it as in the example I gave.
You ignored all the points in my last comment. Let me be more explicit. Bad code is only an albatross if you have to work with it again. What I'm arguing is that it's usually wiser to leave it as it is until the next time you have to work on it, then fix it. It's only an albatross if you don't fix it, and you only save time by fixing it if you actually have to touch the code again. So wait until you're certain that you're going to have to touch the code again, and fix it when you touch the code again, and not before that.
- anthonyb 16y agoHow often have you written a piece of code and known ahead of time that you'd never have to touch it again? Even throw-away code, like data migrations, often gets revisited several times while you're writing it. So why is your supposedly decent programmer writing crappy code and assuming that they'll never have to touch it again? Which is my original point. Traditionally the expectation is crappy-fast-and-cheap vs. perfect-slow-and-expensive, but that rarely holds. Instead it's usually the crappy code that ends up being slow to write and expensive, stuck in endless code and bugfix cycles trying to get it right.