[HarryHirsch]

Say nice things? That reminds me of the lab incident we had last week - a recalcitrant student, no extinguisher on hand, no way of cleaning up after the incident, no clothes for the kid who had to use the safety shower, our safety lady is responsible for provisioning all that and it wasn't there because she's that incompetent. And as the guy who dealt with the incident and wrote the incident report I am supposed to say nice things about the safety lady? Sorry, that's preposterous.

[bethly]

I am sorry your work has been frustrating.

Here I was talking specifically about code reviews, so the context is pretty different than an incident retro. A code review where there is nothing nice to say is probably not going to merge into the code base: it is going to get updated to address the issues, and then there will be something nice to say as I give it a plus one.

But when I run retrospectives, even in the most horrific cases we have a section on "what went right". Sometimes the answer is "nothing", but usually there is something that was helpful: a log message that helped us find the root cause, documentation that meant we didn't have to call someone, alerting that found the problem, a feature flag we could toggle off until it got fixed.

In a corporation, we are playing a repeated game. It isn't about just this one incident: it is about what all the people watching the retrospective are going to built tomorrow, and the day after that, and the day after that. I want people to hear what went right with this incident so they put the log statements & feature flags into their own stuff. Those are the kinds of things that may only be relevant when something goes really wrong, and it's easier to leave them off, so every bit of positive reinforcement we can manage makes our lives easier when we do get paged.

[HarryHirsch]

I am sorry your work has been frustrating.

We had an incident that was worse than it could have been due to long neglect of infrastructure (dare I say that sloth and cluelessness figure heavily?). That's a different kind of complaint. Sometimes work is hard, sometimes things shouldn't be as they are.

even in the most horrific cases we have a section on "what went right"

Yes, in the distant past someone knew what they were doing and bought a bag of cat litter that our current crew of clueless hoarder freaks thankfully kept. It doesn't make them less clueless, though.

In a corporation, we are playing a repeated game.

We as well. We want to ingrain proper habits to get in front of the crazy train. That doesn't mean that we say to every passing serviceman "Thank you for your service and good job you are wearing proper headgear".

I'm tired of the sugar-sweetness. I want quiet and good practice, and the continuous din of "positive reinforcement" is the opposite.

[bethly]

I would recommend reading the blog post; I think there is context you have missed.

I'm describing interactions here I am having with my peers, not people I'm in a service relationships with. We are practicing a highly-skilled trade, and acknowledging the times our skill pays off isn't a "continuous din", or even "positive reinforcement". It is just refusing to be dour sourpusses who have to pretend our work isn't super cool.

Code reviews are most closely akin to a Writing Workshop. When someone in a writing workshop says, "that description evoked Oregon in spring" or whatever, it isn't banal positivity: it is specific feedback on how the craft is functioning.