[tredre3]

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.

[nomel]

That works as long as there's a finish line. If you make a framework, or a set of libraries, it's easy to get pigeon holed into all new features/tangential work around those.

[deathanatos]

I'd go more with their last statement of,

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

That's honestly a high enough bar — many orgs I've worked in do what I call "zero-staffing", which is where an in-use / deployed-to-production project has no team, no engineers (or so few engineers, such as one, as to be a pittance). That one eng, if they even exist, is often just trying to hold everything together.

There's a middle ground, of course: an engineer who has accomplished too much might be underwater with questions, but at the same time, they need to pass the torch to the next team that is maintaining it.

… but too often, there just isn't a next team. People get burnt out, leave for greener pastures, and stuff gets decommed (maybe) because people are like "what even is this?" b/c the knowledge has walked.

The industry is not rewarding experience or knowledge at the moment, so that trend will continue.