Not breaking things
Mark Zuckerberg has moved away from ‘move fast and break things’
Moving fast = better product because you see what works and it gives you momentum
But there are things it’s not OK to break e.g. billing, permissions
You avoid breaking them by testing
But production can differ from your expectations and the test’s expectations – find weird edge cases – and it’s production behaviour you mustn’t change
So use parallel development – every time you get a request run the new code as well and compare the results e.g using github/dat-science – you give it control code (which runs every time) and candidate code

CI as code maintenance
e.g. test for removing CSS as well if you remove the element that uses it, or vice versa – “automates grunt work out of code review”
They even test their blog posts e.g. for over-used phrases

Process
annp – apple new product process
GitHub has equivalent, but at end of process – ship lists
All the hard discussion and thinking has been done by the time you get to checklists

Code ownership
Not throwing it “over the wall”. People who write the code know how to fix it.
“Chrome has owner files [that] tie code to writers” – “Makes mentors [people you can ask] visible” to people who are going to start working on code. GitHub writes team name in file so issues get assigned to the appropriate team.

Institutional teaching
“it’s just logic that someday we won’t be here.” – Ed Catmull. So you need to transfer knowledge.
“chatops: learning by osmosis” – at GitHub they do everything via chat. People can watch you fix things. Real-life debugging – people posting status updates. “debug in the open”.