4 ms·

IME code quality only matters in the parts that require a lot of change. If you keep your mess contained and easy to replace, the inside doesn't matter in 90% o

by ToJans 5y ago

IME code quality only matters in the parts that require a lot of change. If you keep your mess contained and easy to replace, the inside doesn't matter in 90% of the cases. You do need to care about code quality in areas where code changes a lot, but you most likely do not know what these areas are upfront. I consider focus on code quality everywhere a form of premature optimization. Only focus on quality where it hurts... But if it hurts (f.e. you had to change it 3 times and it got messier each time), be very disciplined about refactoring to a better model: whiteboard, brainstorm etc and don't start refactoring until you found a better model.

afarrell 5y ago
Code quality also matters in the parts that a new joiner needs to read to make sense of the application and do their job.
soco 5y ago
If you have a problem somewhere in a mess, it will definitely hurt. What will you do then? Nevertheless, if the programmer know what they're doing I trust that the mess won't be extreme messy in the first place so maybe our argument is purely academic.
- ToJans 5y ago
  I have parts of code that are extremely messy, but I don't spend time on refactoring, because once it works it doesn't need any changes... The moment it starts requiring frequent updates I'll take the time to sit down and do a proper revision or rewrite. I do tend to be very careful with my API interface FWIW...
Verdex 5y ago
I have a similar philosophy. If you can solve it once and the seal it away in a box and never look at it again ... then who cares. Write some tests or better yet hit it with a property test and then move on with your life. I'm more worried about low quality code that takes the form of an api or object that everyone in the entire codebase has to use. Something where if it has a bug or if it needs to change, it will impact huge swaths of code. Meanwhile, the code that takes a double and returns a double ... yeah it can be full of spiders and work by literal earth magic and as long as the unit tests are stable, I'm not losing any sleep. If you have to change it just rewrite it from scratch and reseal away the evil.

by ToJans 5y ago

afarrell 5y ago

Code quality also matters in the parts that a new joiner needs to read to make sense of the application and do their job.

soco 5y ago

If you have a problem somewhere in a mess, it will definitely hurt. What will you do then? Nevertheless, if the programmer know what they're doing I trust that the mess won't be extreme messy in the first place so maybe our argument is purely academic.

ToJans 5y ago
I have parts of code that are extremely messy, but I don't spend time on refactoring, because once it works it doesn't need any changes... The moment it starts requiring frequent updates I'll take the time to sit down and do a proper revision or rewrite. I do tend to be very careful with my API interface FWIW...

Verdex 5y ago

I have a similar philosophy. If you can solve it once and the seal it away in a box and never look at it again ... then who cares. Write some tests or better yet hit it with a property test and then move on with your life. I'm more worried about low quality code that takes the form of an api or object that everyone in the entire codebase has to use. Something where if it has a bug or if it needs to change, it will impact huge swaths of code. Meanwhile, the code that takes a double and returns a double ... yeah it can be full of spiders and work by literal earth magic and as long as the unit tests are stable, I'm not losing any sleep. If you have to change it just rewrite it from scratch and reseal away the evil.