[sonjat]

Part of growing as a software engineer is knowing when things really matter and when things don't. When I first started out, in my mind there was a "right" way to do things (my way of course) and a wrong way. Sure, the wrong way could work, but it was ugly and bad code (in my mind). I would fight constantly to ensure things were done the "right" way.

Then I ended up being in charge of new engineers. I would shoot down their ideas, and essentially force them to do it my way. Eventually I realized that I was hampering their growth for stuff that didn't matter as much as I was thinking, so I relaxed a lot in how I approached things.

My guess is that a lot of what you consider important isn't really that important -- particularly at Amazon, where your co-workers probably have a better idea of where the priorities are. Also keep in mind that even the best of software tends to accumulate technical debt and fixing that rarely bubbles up to a high priority. Which isn't to say you shouldn't push to fix issues you see (indeed, that is often why interns are hired -- to take care of the stuff that regular staff doesn't have time for), just that you shouldn't automatically assume you know more.