Really well written article with interesting points of view.
"1. Don't make it worse!"
Agree. Fixin everything can be impossible, but correcting something step by step, and not just putting quickfix even with my favorite TODO comment (which will never get to state DONE) will gradually make the code better.
"2. Improvement over consistency"
Unfortunatelly I noticed that developers sometimes confuse improvement with "doing it my way"
So I would suggest, if something can be done better - it's good to correct it BUT first it would be good to discuss this at least with other team member.
If the improvement is based on your knowledge it's good to share this knowledge with your team members. Sometimes it's just developer is not aware of other possible solution :)
"Leave the code cleaner then you found it."
One of my favorite rules :D
And I think the most important thing here in article is:
"if you don't change the habits within the team, the clutter will sneak in again"
I agree that it's very common for developers to focus too much on how to correct the code - not how to teach other writing it correclty :)
Thanks for this article :) It was really great to read it :)
Thanks for the response. I really like your point of confusing improvement with doing it their own way. This happens quite a lot. And as you can see with all of these things, communication is key, work together as a team. Sarah mentions that instead of focusing on the individual professional, we should focus more on the team. Although I don't agree with her vision on that, since I think part of being professional is looking at the team you are working in, I think we can all agree that how you work as a team is of great influence on your code base.
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.
Really well written article with interesting points of view.
Agree. Fixin everything can be impossible, but correcting something step by step, and not just putting quickfix even with my favorite TODO comment (which will never get to state DONE) will gradually make the code better.
Unfortunatelly I noticed that developers sometimes confuse improvement with "doing it my way"
So I would suggest, if something can be done better - it's good to correct it BUT first it would be good to discuss this at least with other team member.
If the improvement is based on your knowledge it's good to share this knowledge with your team members. Sometimes it's just developer is not aware of other possible solution :)
One of my favorite rules :D
And I think the most important thing here in article is:
I agree that it's very common for developers to focus too much on how to correct the code - not how to teach other writing it correclty :)
Thanks for this article :) It was really great to read it :)
Thanks for the response. I really like your point of confusing improvement with doing it their own way. This happens quite a lot. And as you can see with all of these things, communication is key, work together as a team. Sarah mentions that instead of focusing on the individual professional, we should focus more on the team. Although I don't agree with her vision on that, since I think part of being professional is looking at the team you are working in, I think we can all agree that how you work as a team is of great influence on your code base.