I work at a sort of start-up. We're pretty successful now so it's a little less about"move fast and break things" however I find that many times the reason to not write clean code or fix some is because it's too expensive to do so and the code doesn't matter that much. Many times if I want to do something the less clean way it'll take 1 day, however if I spend the time to make it awesome it'll take a week. That's a 5x increase in cost! Sometimes I've realized that I'm essentially polishing under the toilet in a cruise liner were no one will see, and even if they did they'll wonder why they didn't focus on the rest of the more important pieces. Sometimes it makes sense to polish, other times it's something that is very utilitarian and "just has to work". The business doesn't have the money or the time to have every piece of the ship polished, just the were it counts.
It's programming, so the answer is always "it depends".
Writing clean code is difficult in the beginning. Later it'll be natural. Say for instance, I don't write long methods anymore. If I do, then I can always click on Extract Method refactoring in my IDE.
Anyway, business is important. We always need to balance between up-front and maintenance costs.
Sorry, to be fair. I think perhaps the definition of "Clean Code" is causing us problems. I think if "Clean Code" means well-architected code that has a lot of upfront design, then this can be problematic. Especially because all that upfront design can be wasted when a new unexpected requirement comes along. However, if clean code means you modularize as things grow and become harder to grok, I think this is always a good practice and really doesn't require much time. Admittedly I often have had the problem in the past of looking beyond the goal and gold-plating things or making unneeded changes that were breaking changes because they felt cleaner. Often they weren't an improvement and at worst they introduced new bugs.
Your comment makes sense, totally. I don't think it was combative at all.
In the Working Effectively with Legacy Code, Michael Feathers wrote that programming requires good judgement. So I can't tell you from my seat how much polishing is enough for you. I don't know what kind of environment are you working in. I don't know if your employer can tolerate little more polishing in order to reduce maintenance costs. I don't know if you're working on an experimental feature.
We need to consider these, when we decide how much we should polish our code. Probably there are other aspects too.
So, in general: we should write clean code. In particular: it depends ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I work at a sort of start-up. We're pretty successful now so it's a little less about"move fast and break things" however I find that many times the reason to not write clean code or fix some is because it's too expensive to do so and the code doesn't matter that much. Many times if I want to do something the less clean way it'll take 1 day, however if I spend the time to make it awesome it'll take a week. That's a 5x increase in cost! Sometimes I've realized that I'm essentially polishing under the toilet in a cruise liner were no one will see, and even if they did they'll wonder why they didn't focus on the rest of the more important pieces. Sometimes it makes sense to polish, other times it's something that is very utilitarian and "just has to work". The business doesn't have the money or the time to have every piece of the ship polished, just the were it counts.
It's programming, so the answer is always "it depends".
Writing clean code is difficult in the beginning. Later it'll be natural. Say for instance, I don't write long methods anymore. If I do, then I can always click on Extract Method refactoring in my IDE.
Anyway, business is important. We always need to balance between up-front and maintenance costs.
Sorry, to be fair. I think perhaps the definition of "Clean Code" is causing us problems. I think if "Clean Code" means well-architected code that has a lot of upfront design, then this can be problematic. Especially because all that upfront design can be wasted when a new unexpected requirement comes along. However, if clean code means you modularize as things grow and become harder to grok, I think this is always a good practice and really doesn't require much time. Admittedly I often have had the problem in the past of looking beyond the goal and gold-plating things or making unneeded changes that were breaking changes because they felt cleaner. Often they weren't an improvement and at worst they introduced new bugs.
Overall I'm a huge fan of clean code.
Sorry if my comments came across too combatively.
Your comment makes sense, totally. I don't think it was combative at all.
In the Working Effectively with Legacy Code, Michael Feathers wrote that programming requires good judgement. So I can't tell you from my seat how much polishing is enough for you. I don't know what kind of environment are you working in. I don't know if your employer can tolerate little more polishing in order to reduce maintenance costs. I don't know if you're working on an experimental feature.
We need to consider these, when we decide how much we should polish our code. Probably there are other aspects too.
So, in general: we should write clean code. In particular: it depends ;)