Using the literal words: "You screwed up." -- can you make an example of a way that would be helpful in an incident, either during the process, or after?

I can't. There's no value in it. What did we, as a team, do that allowed the incident to happen? Yes, John Smith shouldn't have dropped the tables on production, obviously, but does he really not know that as part of the incident response that he's (presumably) also dealing with?

If he's truly not aware that was a mistake, there's an underlying transparency issue that goes way beyond telling an individual they screwed up.

I can, in that given situation. Your assumption is that John Smith should be told "you screwed up" for dropping the prod tables. He shouldn't - he made a normal mistake. The negligent party here, who should hear the words "you screwed up," is Johnny's boss or tech lead, who decided that those tables should be droppable in the first place, despite the obvious risk.

"Negligent" doesn't just mean "made a mistake." It means something more like "their carelessness led to a mistake."

That person hearing "you screwed up" will cause significant behavior change. I daresay it will encourage them to make the prod tables very hard to drop, and since they are presumably a smart person, when combined with the postmortem of the incident, it will encourage them to look for and proactively fix similar problems, and generally align the team with good DevOps practices.

It is important in all of this that the right person gets the message. I assume you expect that to not happen, since that is one of the theses of "blameless postmortems."

I suppose I agree more with you than before, but I still think that aside from the fact that a manager or tech lead is ostensibly used to hearing people be angry (or frustrated, or whatever) -- why is John's boss more deserving of "You screwed up." than the person who dropped them? Yeah, obviously, the prod tables shouldn't have been droppable. John still shouldn't have dropped them. In fact, John, the original developer who implemented them, anyone who altered them since, the tech lead, manager, and frankly anyone who knew this data was critical could have all raised the alarm.

Ideally a blameless post mortem allows the freedom to identify any of the potential fixes that could've stopped this, and empowers anyone who could've dealt with it to deal with future issues. If you blame the manager then that can implicitly absolve everyone else in the chain.

With that said, I would agree that having a primary owner of things does matter. For that reason, sure, making the manager more aware might help in future. I still think it's a bad idea for org culture though because many managers will respond to "You screwed up." with trying to ensure future blameables find their way to another target. Instead, I'd prefer approaching the manager with "We could've caught this in [any of the ways we could've caught it].", and if the manager doesn't care at that point they're just fully incompetent.

I will point out that in the ideal scenario you're talking about, there is probably a next sentence after "at that point, they're just fully incompetent." That next sentence involves some real-life consequences of that incompetence. At that point, the postmortem is not really blameless, the blame is just one step removed.

I agree that what you are describing is the ideal, but I don't think it happens often. What I have seen more is that the postmortem turns into 10 different open bugs, 5 of which (usually bandaids that stop that particular failure mode) get closed quickly and the rest of which (often including the real solution) get put off until the next crisis.

Ownership is really important, but hand in hand with ownership is responsibility. That step is missing in many orgs today.

> I'll pay any amount of money that will make me sit down and do things.

That's almost exactly what I said to myself that prompted me to realize I needed to go to a doctor. Not because I planned on actually spending any amount of money, but because that level of sheer desperation is what finally convinced me I had something wrong with me.

Turns out I had undiagnosed and untreated ADHD the whole time. I'd seek a second opinion because I have no idea why your doctor would say you "definitely don't have ADHD" unless he is one of those doctors that just doesn't believe in ADHD, which is unfortunately common. If you weren't rigorously tested then that doctor's opinion doesn't mean anything, so try again.

So once diagnosed what then, pills or is there anything else that can be done?

Medication makes a huge difference, but doesn't cure you. I truly found myself getting on medication life-changing and it's what allowed me to get on a career track instead of bouncing between minimum wage jobs.

Now that I actually have an income, I'm also seeing a therapist who focuses in ADHD to help build strategies to mitigate the impact it has on my life. I'd say medication then therapy, in that order, have the biggest impact.

I've always liked the premise that you should be competent one level below where you do your daily work. The tools you use should be more efficient for you, not necessarily the only way you can get your work done. If you don't know how to use a drill, you shouldn't use a drill press.

By that token, using AI to solve AoC really seems like one would be doing themselves a disservice. You might tell yourself you fully understand what the AI spits out, and maybe you do, but you won't build the same sort of comprehension that you would from solving it yourself. Nor will you retain it for as long.