I understand this perspective, and I've succumbed to the same sort of pressure in the past, but doesn't it feel like you actually end up losing net time in the

I understand this perspective, and I've succumbed to the same sort of pressure in the past, but doesn't it feel like you actually end up losing net time in the long run by doing this? I mean, you save a bit of time up-front to hit a deadline but then you have to spent hours of frantic debugging when you should be sleeping to rerun a slightly modified benchmark for some other deadline. Or somebody suggests a good idea that you can't test quickly because the code is a mess. And then you either spend a bunch of extra time on it or pass on something that should have been easy because it wasn't. I only worked on a CS research project as an undergrad, but there we had the same dynamic. On the one hand, it made sense not to spend too much time writing good code, automating benchmarks... etc. On the other we spent too much time chasing down stupid bugs as the project went on. I wouldn't be surprised that, had we been slightly calmer and more methodical up front, we'd have saved time overall that month if not in the same week. And that's not counting how code like that makes research worse. Like, I see why writing a framework to optimize your benchmarks could be a waste of time, but it could also be the difference between running a bunch of tests to evaluate the project instead of just shoving the first ones we thought of into the paper because running more would take too much effort. It's not unique to research either: I ran into exactly the same sort of tradeoff working at an early stage startup. We care about putting out features above all until things came tumbling down. Spending a week or two chasing down bugs and making new features more expensive was bad, but then again we did need to test things and establish product/market fit quickly... My intuition is that this sort of pressure-based decisions end up a net loss of time even in the medium term, maybe even on the scale of weeks. But I don't know how to actually measure this sort of thing: we never measured how much time we spent on different tasks, and time is probably the wrong thing to measure anyhow. Debugging stupid code saps creative energy and lucidity even more than time, and how do I know what potential things didn't get done because the code was too ugly or, on the flip side, what things I could have had done in the time I spent making code better? How do you deal with this sort of trade-off? I'm not being rhetorical in the least, by the way: I genuinely don't know. But I really feel that incentives are geared towards short-term benefits in a way that is simply worse overall even across relatively short time horizons.