I’ve been thinking along these lines and a DNA type meeting as an informal place of leadership and sparring sound great. In our case, I think I’ll call it “Debt and Architecture”.
Slack has an interesting S-Curve based approach to adopting new technologies where they mention that getting through the trough of adoption is more like product-work than anything else.
There are a bunch of wrong ways to install Python 3 on your Mac unfortunately. Follow this guide and you’ll save yourself a bunch of pain.
The correct sequence is to start with a business goal, translate that into a technical strategy and have architectural initiatives follow from that.
A write-up how Dropbox rearchitected and broke up their monolith into pragmatic components. Nice to read that their base was a large Python code base, a bit similar to Instagram which is still running a branch of Django underneath.
I have long been skeptical of semver and especially of the dogmatic adherence to it by both producers and consumers.
I’m a big fan of the idea of RFCs to spread out and improve decision making in technical teams.
There’s going to be a need for operations in companies however much of their infrastructure they outsource and it’s going to be increasingly interesting and valuable work.
“I see operationally-minded engineers working cross-functionally with software development teams to help them grow in a few key areas: making outsourcing successful, speeding up time to value, and up-leveling their production chops.”
I immediately understand it but I’ve never seen it articulated as explicitly as here by the Singapore Civil Service College: “The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.”
When it comes to software development most of these are good opinions and you can take them as yours without spending the six years Chris Kiehl needed (or the many more I did).