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.
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.
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.
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
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.