This article is really conflicting for me. Their are valid points from both sides of the comment section. Against the writer: Since you were new to the company

This article is really conflicting for me. Their are valid points from both sides of the comment section. Against the writer: Since you were new to the company, of course people are going to be leery of your experience and input. Rampant in IT is the sense that seniority directly equates to skill, no one wants to listen to newer, younger employees. Now I've never worked with programming, I'm from the security sector but the same type of mindsets are in place here. People who have done the work and set up systems absolutely get offended when you critique their work. When experienced devs put time and effort into coding something, they aren't going to tolerate the new kid coming in and saying "This is all wrong, here's 50 minor changes to make it slightly better". >>"But I don't like to criticize without showing a better way, so I decided to immediately start fixing the most glaring issues...that involved quite extensive changes" ^ As others have pointed out, this was a huge factor in why things went the way they did. Although it's not ideal and I despise it, the mantra of "If it ain't broke, don't fix it" rules IT. If you were assigned to work on a security issue, the sole focus should have been on that. Sure you can take notes and document the sloppy surrounding code, but making the decision on your own to start correcting other peoples work will not sit well. It extends to you trying to help other teams as well, you made that decision on your own without trying to consult your own team first. In the end, this job just wasn't for you. It seems like it was filled with complacent, older employees who just wanted to do their job description and nothing more, as shown by new code not getting reviewed. For the writer: You come off as ambitious and confident(maybe too much so). This type of business isn't for you, you'd be much more successful at a startup filled with younger talent where everyone is striving to pump out code. That type of environment would be much more open to things like peer review and code cleanup. If you're going to work in a team, you have to work with the team, not for the team. Don't try an outdo your peers, work with them to achieve a common goal. Ultimately it seems you just drew the short straw on jobs. This is why it's always recommended to have an updated resume. I'd be in the same boat as you if I was a developer. I wouldn't want to wait around for months to gain respect, or have to just accept working with bad code. If something can be improved, why not improve it? Unfortunately that's just how the world is. It might be a bit hard to find a job that completely accepts your proactive nature, but eventually you will.