I do understand it though, and when you're fresh in a project it's easy to go for the low hanging fruit like that. But, be subtle about it, ask if it's welcome, that kinda thing.
When you start work with a new codebase you spend some time to get acquainted with it. It only makes sense to take notes of bugs or possible improvements when you do it. A pair of fresh eyes will always find improvements to be made.
If you expect me to take on a project without looking at the previous code then you're simply a fool.
It would've made me reconsider the job I currently have. Upon saying that, I am enjoying the challenge of trying to eliminate as much tech debt as possible.
But being in leadership and spending time around a few hundred coders over the hears has taught me the value of someone who does this.
I hope this wasn't the reason the person was fired, because it's a missed opportunity for management: someone with that kind of drive and commitment to quality is valuable to have - and hard to find. I can count with my hands the number of developers with that kind of drive I've found.
With no further context - meaning: I'm making a lot of assumptions here - I think I'd've helped them schedule time to evaluate these opportunities for improvement (how much do they cost to fix? how much will they cost if not fixed? How can we prevent this from getting in new code? etc.), and when the numbers are right - schedule time for fixing them, too.
If non-agreeableness was their sole defect - it could've been worked on over time. That's what leaders are there for: to help their collaborators grow.
dafuq is that? The more eyes on a piece of code, the better.
Grandparent = the parent of the parent.