9 ms·

Of all the fucked up things in this comment, giving a single Engineer lifetime responsibility for all bugs in code they wrote is probably the dumbest. And it's

Of all the fucked up things in this comment, giving a single Engineer lifetime responsibility for all bugs in code they wrote is probably the dumbest. And it's slowly becoming the norm. The last place I worked at, a large and well known Tech company, didn't even roll with QA's. That just wasn't a role anywhere in the division. You are fully responsible for all the bugs in all the code you ever wrote Cute at first. Unsustainable in the long term

vlovich123 2mo ago
Ok. So QA finds a bug. Who’s responsible for fixing it? The only value of QA is to try to make sure you become aware of issues before customers find them
- episteme 2mo ago
  The company, not the individual
  - ShrootBuck 2mo ago
    And who in the company do you propose should fix it
    - jareklupinski 2mo ago
      someone hired by the company to understand the application and fix the bug ive inherited a lot of code
      - SoftTalker 2mo ago
        Fixing bugs is a great activity for new hires. Gets them familiar with the codebase.
        ProjectMRI 2mo ago
        [flagged]
- dizhn 2mo ago
  QA probably has their own promotion path that doesn't involve finding bugs. :)
weitendorf 2mo ago
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 2mo ago
  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 2mo ago
    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 2mo ago
      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.
goosejuice 2mo ago
It's not cute, it's a sensible way to build greater understanding by learning from mistakes. The thing is, it has to be engrained in the culture and that also means it may need to take priority over other work. Responsibility doesn't need to mean you have to write the code, just see it through.
dfxm12 2mo ago
It's even worse when you don't work at a tech. Even the simplest of Excel formulae, power automate flows simply go abandoned once the creator moves on, or maybe a very expensive consultant is onboard to maintain what amounts to a handful of lines of code. It's embarrassing how little initiative the average information worker has when it comes to stuff like this.
boredatoms 2mo ago
Lifetime is too much. One or two re-orgs at most. People only spend a couple of years at each company anyway

vlovich123 2mo ago

Ok. So QA finds a bug. Who’s responsible for fixing it? The only value of QA is to try to make sure you become aware of issues before customers find them

episteme 2mo ago
The company, not the individual
- ShrootBuck 2mo ago
  And who in the company do you propose should fix it
  - jareklupinski 2mo ago
    someone hired by the company to understand the application and fix the bug ive inherited a lot of code
    - SoftTalker 2mo ago
      Fixing bugs is a great activity for new hires. Gets them familiar with the codebase.
      - ProjectMRI 2mo ago
        [flagged]
dizhn 2mo ago
QA probably has their own promotion path that doesn't involve finding bugs. :)

weitendorf 2mo ago

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 2mo ago
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 2mo ago
  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 2mo ago
    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.

goosejuice 2mo ago

It's not cute, it's a sensible way to build greater understanding by learning from mistakes. The thing is, it has to be engrained in the culture and that also means it may need to take priority over other work. Responsibility doesn't need to mean you have to write the code, just see it through.

dfxm12 2mo ago

It's even worse when you don't work at a tech. Even the simplest of Excel formulae, power automate flows simply go abandoned once the creator moves on, or maybe a very expensive consultant is onboard to maintain what amounts to a handful of lines of code. It's embarrassing how little initiative the average information worker has when it comes to stuff like this.

boredatoms 2mo ago

Lifetime is too much. One or two re-orgs at most. People only spend a couple of years at each company anyway