3 ms·
After reading these, I am wondering how anyone could've thought differently, as I agree with them all and it seems to me that to disagree with any of them doesn
by cercatrova 6y ago
After reading these, I am wondering how anyone could've thought differently, as I agree with them all and it seems to me that to disagree with any of them doesn't seem to be reasonable. For example, typed languages are of course better than untyped ones, especially for large codebases with multiple levels of experience of the people who write them.
In other words, these seem to be exactly the opinions that the majority of HNers would agree with, and it is one of the least controversial lists I've ever seen.
- sa46 6y agoI 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.