[tamsaraas]

I agree with the author. However, I need to do things that must be done now. Because best code is the enemy of good code. Easy to fall to refactoring and lost everything in the end.

Good code is code that works and solves a problem right now. Otherwise, we will not have clients waiting for a "well-polished" formatted product that is easy to read and maintain for us.

And that is the problem of the whole infrastructure. We needed solutions for X, Y, and Z just yesterday. And then, if it "shoot," we like idiots yearly fixing all problems that have been done earlier.

Speed is critical. More important than perfectionism or wish for well-structured, easy-to-read, maintained code.

Is that awful? Yes. I want my code to be good as it can be. But is it possible to do it in a limited time when an urgent problem must be addressed? Nope.

And over time, we increase complexity, multiply complexity, and then leave because not able to maintain it anymore. That's why we touch different things while fixing everyday problems because we do not want to fix them later. Balancing complexity in future. But this is fake. This future never happen in 99% cases.

The biggest problem is that if we do not rush right now, there will be no tomorrow for the product we develop.

[wtetzner]

> Speed is critical. More important than perfectionism or wish for well-structured, easy-to-read, maintained code.

The thing is, poorly-structured, hard-to-read, unmaintained code is the enemy of speed. I don't think it's ever a good idea to go too far in either direction. If you spend all of your time on refactoring/cleaning up code, you never get anywhere in terms of functionality. But if you never refactor, you're development speed slows to a crawl, and making meaningful changes becomes impractical.

[tamsaraas]

> The thing is, poorly-structured, hard-to-read, unmaintained code is the enemy of speed.

Sorry for debating with you. But any modern code editor has tools which solves the problem of "well-structured" code. What about "easy-to-read", this is depends on language, and the programmer.

I've seen so damn much beautiful code, with 1 character long vars. And such code extremely hard to understand. The code is compact and beautiful. But for understanding the code - required a lot of time.

I think, and my own experience proof that. If you not in rush for finishing things just in time while the things actual - you lose. Always. And there will be no second or third chance.

That's why need to write how you used to write. Only experience & practice give you ability to write good code.

Focusing on re-writting some code parts while fixing a bug - big problem. If this re-writting thing does not change anything instead of "better understanding and better ability to read" - this is bad time wasting.

If you not in rush in developing things and doing right actions in right time while the problem or request actual - you lose. Always. Without second chance.

That's why need compromise and write shitty code for winning competition in short run. And then, when you will have audience for your product, you can always fix here, and change there. Nobody will complain about bugs or issues until it leak personal data.

[wtetzner]

I'm not saying you should just do random refactorings. What I am saying is that if you are fixing something, and realize that you can fix it while improving the code at the same time, it is typically worth it. Obviously if the refactoring is a huge undertaking, it's not going to be a great idea to pair it with a bug fix. But if your are smart about it, you can usually keep the code base clean/well-factored incrementally.

The problem with "quick" fixes is that they often end up being slower, because hacking a fix into a complex code base often creates new bugs/problems, and you end up rolling back your broken "fix".

> Only experience & practice give you ability to write good code.

I agree, which means that always writing shitty code to get it out the door means that you will only practice writing shitty code.

There's a balance to be found.

[iopq]

Sometimes rewriting things allows you to fix things in multiple places at once instead of one at a time.

My coworker copy pasted a bunch of stuff into each page, so when I actually templated them I could fix the bug he had in every page, not just every time I find the bug