I disagree with this pretty strongly. If you’re not going to take responsibility for your bugs I don’t want to work with you.

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.

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

▲

tredre3 2 hours ago | parent | next [-]

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 an hour ago \| parent [-]
		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.

▲

mk89 an hour ago | parent | prev [-]

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.

▲

mschuster91 28 minutes ago | parent [-]

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

Well, it works for professional engineers, you know, the people designing bridges, tunnels, heavy machinery, aircraft, spacecraft or medical instruments. When something happens and they can't show that their work adhered to the generally accepted best standards at the time... they're held liable. And sometimes, that liability includes jail time, particularly when people are seriously injured or die.

And how it is sustainable? Simple: legal requirements that force managers to allot enough time and tooling to their engineering teams, because engineers whose professional license is on the line will rather quit than be forced to sign off something that is unsafe.

In the software world, this might result in AI not being used at all - simply put: no matter what, AI in its current form is always going to be vulnerable to in-band attacks, or to use an older term... phreaking [1]. It might result in software having to go through formal proof programs, fuzzers, whatever. It might result in entire programming languages just being outright banned in production code in favor of programming languages that eliminate entire classes of vulnerabilities.

And before the usual "but China/India/... would outcompete us" complaints come... well, have you ever seen a Chinese widebody airliner in Western airspace? No. Because China is not able to pass over the engineering gates we have set in place. We could easily do the same with software.

Requiring at least some sort of quality gates on software would not be bad for you as a programmer. Quite the contrary: it would hand you power over your incompetent beancounter boss.

[1] https://en.wikipedia.org/wiki/Phreaking

	▲	jerojero a minute ago \| parent [-]
		I think the problem I see with your argument is that people simply do not value reliable and secure consumer software as much as they'd value reliable and secure airplanes. Of course, software that is in charge of things where people value security a lot, such as the software in airplanes, is much more scrutinized and adheres to better standards. This is the case precisely because when it goes bad people die in ways that attract a lot of attention. You can't enforce those same policies on most consumer software because people consume it the same way they do food. You can have Michelin starred restaurants with the best practices but most people can't afford to eat there so instead they will buy hot dogs on the street. The idea of "high quality hand crafted artisinal software" is closer to luxury products than it is to the engineering of planes, trains and bridges.