I has a similar experience where I had to 5 why a issue and... the gist of it was that the why was because I bungled it up. I just.. saw it as an issue while I wrote my stuff, added a TODO and then... just never did it. So then, after the first 2 why's I could only answer in the back of my head, "Because I'm fucking stupid, that's why!"
I get the idea with the why's but sometimes, it's just that simple, you can't really go deeper than that. I fucked up.
The question then becomes: what could you have done for the "system" to automatically prevent you from forgetting that? Would an end-to-end or smoketest prevented that? Would having a TODO-linter have stopped this? Would singing your country's anthem from the top of a hill prevented this (I dunno, maybe it's a really magic song)?
You are looking for improvements to your process that will help you protect yourself from yourself. :)
Exactly this. We have a saying in the GxP QA world - look at the process, not the person.
Anyone can make mistakes, and sometimes the naive 'why' of something is just that someone made a mistake. But if you focus your questions on the process, it becomes 'why did the process allow this mistake through'. Perhaps a checklist could have helped. Perhaps you need a QC [1] step in the process. Maybe the instructions aren't detailed enough.
[1] Though there are many sometimes subtle differences in how these terms are used across industries, generally the difference between Quality Control and Quality Assurance is that QC is part of the process (e.g. a built-in check in the system), while QA is a separate process making sure these checks and balances are working properly.
To bring in the car analogy, QC would be your tire pressure sensors, and QA would be your mechanic checking that the pressure sensors are working correctly.
Why did you fuck up? Because you didn't get enough sleep. Why didn't you get enough sleep? Because you were on-call at 3am. Why were you on-call at 3am? Because the apps keep crashing once a week. Why are the apps crashing once a week? Because nobody has prioritized fixing them. Why has nobody prioritized fixing them? Because the feature work is higher priority.
Or: Why did you fuck up? There was no validation of the change before applying it. Why was there no validation of the change? Because we've never prioritized validation. Why have we never prioritized validation? Because we don't think it's important. Why don't we think it's important? Because we never look back at our previous failures to see if there's a pattern of failures from lack of validation.
So even from "I fucked up" we find a number of problems and things we can start addressing.
Major cause of burnout and incidents, yet management will ignore this particular "why", because their promotions are based on features, mostly. Also why it sucks being an SRE unless the company empowers your team.
The hardest part is usually figuring out a reliable way to avoid making the same mistake in the future. "Don't make mistakes" is never a viable solution to that problem.
I think you can still usefully push past the "I just never did it."
If the problem is that you are overcommitted and things are starting to slip, that's a different problem than "I got distracted by something shiny and forgot." In the first case, it might make sense to try to grow the team, for instance.
I get the idea with the why's but sometimes, it's just that simple, you can't really go deeper than that. I fucked up.