I agree with most of the list. It's a good distillation of software development principles. In the spirit of HN, here's what I disagree with:
> Designing scalable systems when you don't need to makes you a bad engineer.
Creating overly scalable solutions is useful for learning, especially early on. I've done this.
> Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers.
This is true in almost every human endeavour. It's not a useful opinion. Most decisions don't matter that much so adding data is a waste of time.
> Code coverage has absolutely nothing to do with code quality
I don't buy there's no correlation between code coverage and code quality. I'd much rather take code with >80% coverage than 0 coverage. My revised take is that the value of code coverage rapidly diminishes past 80% (maybe log scale-ish). I also think code coverage metrics are not especially useful outside of library code.
> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
Google tried getting rid of managers. It didn't work. Establishing lines of communications in large orgs is hard.