[weitendorf]

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]

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.

[mk89]

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]

> 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]

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.

[BetterThanSober]

> people simply do not value reliable and secure consumer software

Because the incentive to care is not there, we'll see things changing when self-driving cats is mainstream

[BubbleRings]

I want one that can drive itself to the vet!

[mschuster91]

> You can't enforce those same policies on most consumer software because people consume it the same way they do food.

The government can. GDPR was an attempt in that direction, it wasn't enough of a hint to software developers, that's how we got the Cyber Resilience Act that's beginning to take first effects in a few months.

[SoftTalker]

It's interesting you bring up airliners. Whose engineers developed MCAS? Were any of them held liable? Are any in prison?

[mschuster91]

> Whose engineers developed MCAS? Were any of them held liable? Are any in prison?

Given that Boeing had been granted wide leeway to audit itself and write its own standards... the engineers couldn't be held liable and the corrupt US government dropped the corporate case [1].

[1] https://www.bbc.com/news/articles/c891k875x3qo

[SoftTalker]

So, the supposed code of ethics that would have applied to these "real engineers" did not stop them from designing and implementing a system that violated aeronautical engineering principles in several ways.

[Jach]

> 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...)