Things I now believe, which past me would've squabbled with:
- Typed languages are better when you're working on a team of people with various experience levels
- Standups are actually useful for keeping an eye on the newbies.
- Sprint retrospectives have their place so long as they're for actual course correction (i.e. "holy shit,?that?went poorly!") and not some god awful?'agile' / 'scum master' driven waste of everyone's time
- Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.?
- Java isn't that terrible of a language.
- Clever code isn't usually good code. Clarity trumps all other concerns.
- Bad code can be written in any paradigm
- So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot
- Designing scalable systems when you don't need to makes you a?bad engineer.
- Static analysis is useful
- DRY is about avoiding a specific problem, not an end goal unto itself.
- In general, RDBMS > NoSql
- Functional programming is another tool, not a panacea.
- YAGNI, SOLID, DRY. In that order.
- Pencil and paper are the best programming tools and vastly under used
- Trading purity in exchange for practicality is usually a good call
- Adding more technology is rarely a good call
- Talking directly to the customer always reveals more about the problem, in less time, and with higher accuracy
- The word "scalable" has a mystical and stupefying power over the mind of the software engineer. Its mere utterance can whip them into a depraved frenzy. Grim actions have been justified using this word
- Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers
- 90% –?maybe?93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
- After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.
- People who stress over code style, linting rules, or other minutia are insane weirdos
- Code coverage has absolutely nothing to do with code quality
- Monoliths are pretty good in most circumstances
- TDD purists are just?the worst. Their frail little minds can't process the existence of different workflows.
?We'll see which of these have flipped or changed at year 20.
