AmIAnElitist

I knew what I was getting into - It'd be silly to blindly accept an offer. My general cost-benefit analysis was that if it turned out to be a horrible experience, at the very least I'd have Amazon on the resume. It actually turned out to be a great experience, despite the issues I mentioned.

Also, behemoth companies like Amazon cannot possibly be generalized.

> then let me tell you that the issue is that you need more humility.

Perhaps this is exactly the criticism I need to hear.

> For example, when you see that there are compile time errors in the main branch, you need to get your team together and talk about why that is bad.

One slightly tangential thought that this lead me to was that currently, I get a new team multiple times a semester. There simply isn't time for this overhead every single time. Teaching takes time, gaining trust takes time - this might be one of the causal factor for the poor quality.

I try hard to not be part of the problem, but you're right that there's always more that I can do and every moment can be a learning experience - I can think about a couple times I had the potential to be a much more positive impact.

Thanks for the advice, I really appreciate it.

Which book in particular? Are you talking about "The Basic Laws of Human Stupidity" ?

I'll happily tack a book on the reading list, but he's written much more than one book!

Thank you for the advice. I generally try to silence the cynic in me, thank you for reinforcing that.

> ONLY judge yourself

This is great and very useful advice.

I'll take this viewpoint into consideration, thank you.

My previous philosophy was that few projects past MVP stage are deploy and done, and it's a major long run time sink to have to deal with the problems not having the basic tooling creates.

I like to think about it like this: A project looks like y = mx + b, where b is the overhead of inital setup, y is the output, x is dev time and m is the efficiency of devtime. If you skip the setup, you lower the b to 0, but with enough required y you actually end up paying more cost (and time = money since someone is cutting devs a check) than a project with more efficient dev time (lower m).

I had thought that in general testing + automation is worth it in the long run. Thanks for your input, perhaps my previously held philosophy is based on the flawed idea that all projects have some degree of maintenance required.