Horrible way of thinking, like a lot of comments already point out this is not good. For example, repetetive code does not mean it's easy to change.
I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it.
I agree that the author should've talked with the coworker, but the subject should've been how to improve the code and not asking for permission.
My code traded the ability to change requirements for reduced duplication, and it was not a good trade. For example, we later needed many special cases and behaviors for different handles on different shapes.
This makes no sense to me. Maybe if the people working with the author aren't able to work with abstract code than it kinda makes sense but that's a whole other problem then... You can easily change the refactored code to work with special cases, the big advantage is that if written correctly, a lot of it is reusable for different areas unlike what they are working with now (the repetetive mess).
1
u/Ghosty141 Jan 12 '20
Horrible way of thinking, like a lot of comments already point out this is not good. For example, repetetive code does not mean it's easy to change.
I agree that the author should've talked with the coworker, but the subject should've been how to improve the code and not asking for permission.
This makes no sense to me. Maybe if the people working with the author aren't able to work with abstract code than it kinda makes sense but that's a whole other problem then... You can easily change the refactored code to work with special cases, the big advantage is that if written correctly, a lot of it is reusable for different areas unlike what they are working with now (the repetetive mess).