I think it's reasonable to have a culture where you're encouraged to consult the IC who wrote the code even after they've moved on to other projects. But I don't think they should be responsible for fixing the bugs.

And I don't mean this to excuse the bad code written by ICs. I just think it's not sustainable from the POV of the org itself to depend so heavily on individuals, especially ones who aren't familiar with the entire codebase anymore.

The team currently in charge needs to have full ownership and be responsible for the code, even if they didn't write it.

OP used the word "lifetime" which makes a key difference.

I don't want to be responsible for a bug in my 8 years old code, which I probably even forgot how it worked etc. I probably don't even work anymore in the same team or on the same service.

Why the hell should I be responsible and how is this sustainable?

I am not even sure if your criticism makes any sense at all anymore nowadays. AI is writing 80% of the code, if not more. It's technically not even your code anymore, although there is your name on the commit. Why should I be responsible for that 3 years from now, when I have again moved team or service etc.

Accountability ok, but you should not retire with your code.

> If you’re not going to take responsibility for your bugs I don’t want to work with you.

Depends on what "taking responsibility" means.

> Don’t make other people QA your work; if you’re not able to figure out how to do that yourself while you work you’re legitimately bad at your job.

At a distance I agree with this, but closer to the details, eh... Having worked with excellent QA and QE people, they just think differently than I and other programmers I've worked with do, in a useful way, so I think it's a shame (even if understandable) how such roles have been killed industry wide for over a decade. "Hybrid" doesn't really cut it. But yes, I get pissed when a code review comes my way and the author clearly didn't bother to even run their own code because when I notice something wrong and try it, lo and behold it doesn't work. I imagine some even less competent places throw over reviews (or just push straight to master) that don't even compile. I won't get into basic automated testing. I believe programmers should have a professional ethos to learn new things to make themselves better at their craft, with or without management support or even paid company time for it, this includes ways to think about better achieving quality goals.

> Once you leave an employer obviously you have no obligation to fix bugs in IP you don’t own or anything.

This is the crux of the issue: the employer always owns the code, not the individual, and so to me it's the employer's job to be responsible for any defects. A sensible employer probably recognizes that often the author of the code is the best one to fix it -- but this is also part of why it's so important to have code reviews, because then in theory you have at least two people who are somewhat familiar with the code. At the same time, coding, like everything else, is subject to stochastic quality issues. Employees work within a system, many issues are caused by the system, and only management can change the system. Take some lessons from Deming's red bead experiment: https://www.youtube.com/watch?v=7pXu0qxtWPg (Write-up: https://web.archive.org/web/20251212234933/https://maaw.info...)