This model would not suggest the results seen in studies like this:

https://pmc.ncbi.nlm.nih.gov/articles/PMC11846175/

(The intervention was not "face the roots of your problems", it was "stop using your phone so much", and it produced positive impact.)

My parents were both construction workers. There is an understanding that you cannot lift heavy objects forever. You stop lifting objects and move to being a foreman, a supervisor... and if you are uncomfortable learning to get others to do work that you before have done yourself, you burn out your body entirely and the consequences are horrible.

This is factual reality, but it is also a parable that has been important for me to internalize about delegation in my own career. It is not irrelevant to AI use, but I don't think it slots onto it totally as neatly.

What is this referring to?

I mean, we do have weight categories in combat sports, right? I don't see why we couldn't come up with similarly neutral categories if we think it's good to segment people out by physical advantages. The parent comment is making a good point, though: it feels like some people care a lot about physical advantages that map onto gender stuff they care about, and not a lot about weird genetic anomalies that provide physical advantages that aren't gendered.

I will also admit that this part hurt my heart to read (vicarious embarrassment):

> the recruiter mentioned I needed to pay more attention to code debuggability (whatever this means - I assume that under the corpo-language, they mean that I wrote invalid code)

https://www.hillelwayne.com/post/stamping-on-eventstream/

He goes through the process, which he describes:

> The constant zooming-out is key here: it’s not enough to find out why things broke, but find out why “why things broke”. In theory you’re supposed to keep doing it: if someone skips a step because of managerial pressure, you ask why the manager was pressuring them in the first place. If the manager was worried about production quotas, find out how the quotas were decided. You just keep going and going and going.

There are different procedures folks can use to capture bits of this to different degrees, but I think this write-up illustrates well both how exhausting it is to do this right and what the value can be. Even if your goal is to get to Action Items, this kind of understanding of your event is what should generate them.

If a person doesn't understand the value, I would imagine they would write something very close to TFA's

> when something goes wrong [...] they explain why they made the decision, and then explain the contextual factors that influenced that, and then explain why those contextual factors existed, and then explain why it would have been unreasonable to expect them to anticipate the downstream effect of those factors, and by the end you have some fat five paragraphs that contains maybe one sentence worth of information and reads like a legal defense brief written by someone who knows they are guilty.

The number of junior engineers I have had to coach out of this way of thinking to get the smallest fragment of value out of a postmortem process... dear Lord. I wonder if this person is similarly new to professional collaboration.

The larger personal site is very aesthetically cool, though – make sure you click around if you haven't!