[rkwz]

Great points!

> Not having retros for engineering processes (e.g. does our 80% coverage rule still make sense, should Jenkins be our job runner, etc.)

How is this usually done? Is this suggested by the team and get prioritized based on popularity or some other criteria?

> Trying to solve problems by having engineers "do better", rather than designing and implementing better processes

Can you elaborate on this?

[camgunz]

One of my roles had an "Engineering Council" where this was done. I don't how well it worked--for example we were very Jenkins-dependent but everyone absolutely hated Jenkins. But, basically you get a cabal together and decide stuff.

---

I forget who I was watching, maybe Rich Hickey, but whoever it was was saying that as an engineer, your ceiling is lower than you think it is. You'll never get anywhere close to twice as smart, or twice as creative, or twice as careful. You might some days be 20% smarter, which would be wild, or maybe over a year you might do 6% over, but you'll probably balance that out with down days/years and over time you'll age and get worse, not better. So the only way you're really going to meaningfully improve isn't by thinking harder or being more fastidious, it's through processes and tools.

A lot of engineering managers don't internalize this. For example, they think they can just say things like "be more careful when pushing to prod", but in the history of software engineering that has never worked. What does work is CI/CD, testing, QA, design docs, etc.