Thread by @allspaw

Software Engineers: at some point during this next week, some of you may make changes to production code or infrastructure.

This thread is for you.

You will do all the things you think are necessary to be confident that the change will do what you intend, and you’ll not do any more than that.

You’ll be as thorough as you believe you should, just like you have with every successful change you’ve made before.

When it becomes clear that the change didn’t do what you expected and triggers an incident, a shift in focus will take place amongst your colleagues and you might take part in it yourself.

There’ll be focus will be on what you *missed* in your assessment of how “safe” that change was before you pushed it.

What you didn’t see/realize, but should’ve
What was lacking.
Where you went ‘wrong’.
What was obvious but you didn’t pay attention to.
How you weren’t careful.

Even tho the tendency to take this stance is very strong, decades of research has shown it’s an entirely *unproductive* way to explain what happened.

“They should have tested better. They should have seen the glaring mistake. Etc.”

These statements provide zero insight into what was happening with you at the time and the various sources of your confidence at the time.

These statements also redirect inquiry away from the actual context of the incident, which is the opposite of how improvement works.

So the next time someone puts down “should have...” or “more thorough...” as a contributing factor or a ‘root cause’ - understand that while these may help us *feel better* about the future, they do not help us in the future. (fin)