5 ms·

> I’ve noticed quality issues in your code recently that’s resulted in some rollbacks I would tend to even leave out the first part of that phrase. Focus on th

by pdonis 2y ago

> I’ve noticed quality issues in your code recently that’s resulted in some rollbacks I would tend to even leave out the first part of that phrase. Focus on the actual objective measure: the rollbacks. They happened, and the goal is to figure out how to not have them happen in the future.

xandrius 2y ago
Yeah, code quality is marginally important if whatever QA/UAT process allowed that code to go to production. If "bad code" can make it to production it's usually the fault of the system as a whole, not the author.
- nrclark 2y ago
  I have mixed feelings about this. For the most part, I think "you can't bolt on quality after the fact" is true. Code reviews and CI/CD automated-tests are helpful, but can never be thorough enough to catch every mistake that a low performing developer might make. If that developer causes enough problems over time, that is absolutely something that their manager can and should address.
  - xandrius 2y ago
    I'd think about actioning the individual only if it was exactly the same issue every time (how did the same issues manage pass time and time again, didn't we learn anything as a team?). Otherwise I'm more in the mentality that breakages are a great way to improve internal flows against (inevitable) failures. I think the real problem would be when a developer cannot manage to get any code into production (e.g. Code stuck in PR for weeks) but once the rest of the team and our systems approve it then they have proven their worth. Also, if developer X's code keeps passing code reviews, CI/CD, QA and UAT, and it's not the fault of the systems in place, I would ask myself what kind cutting edge stuff are they working on?
quietbritishjim 2y ago
I disagree, at least in this case. In the comment you're replying to, the new manager is technical and familiar with the codebase, and can assess that the reason for the rollbacks is a genuine quality issue. This is useful information, and if you leave it out then you leave your report partially in the dark, wondering if the rollbacks are happening for some other reason (I can think of plenty). I'm not saying it needs to literally be in the first sentence or phrased exactly like that, but I don't think that's what they meant anyway. Rather, you do need to be upfront about it instead of alluding to the problem without giving away what you actually think.
- pdonis 2y ago
  > the new manager is technical and familiar with the codebase, and can assess that the reason for the rollbacks is a genuine quality issue. This is useful information Only if the report doesn't already know it. But they probably do. It doesn't seem likely to me that the report would be in the dark about why the rollbacks happened. And if they already know it, it's better to let them ask for help than to tell them up front that you, their manager, know that their code quality is an issue. Give them a chance to identify the issue themselves first.
  - cutemonster 2y ago
    Meanwhile, deployments keep getting rolled back? Sounds like this mistake: > > avoiding hard conversations with your reports. And hoping that things will get better soon. But: > > Sadly it is the single biggest cause for dissatisfaction that can also be among others in the team, who have to deal with the rollbacks.
    - pdonis 2y ago
      > Meanwhile, deployments keep getting rolled back? One could say that the scenario as described in the post I originally responded to, by localghost3000, doesn't make sense, yes. If there have already been multiple rollbacks, and this is the first conversation you as a manager are having about them with this report, then you as a manager have already messed up by not addressing the issue sooner. But that just makes it even more of a problem to lead with language like "quality issues in your code", implying that all the responsibility lies with the report, and none of it lies with you, the manager. The approach I described, where you focus first on the objective fact, that the rollbacks happened, and on how to keep them from happening again, avoids that.

by pdonis 2y ago

xandrius 2y ago

Yeah, code quality is marginally important if whatever QA/UAT process allowed that code to go to production. If "bad code" can make it to production it's usually the fault of the system as a whole, not the author.

nrclark 2y ago
I have mixed feelings about this. For the most part, I think "you can't bolt on quality after the fact" is true. Code reviews and CI/CD automated-tests are helpful, but can never be thorough enough to catch every mistake that a low performing developer might make. If that developer causes enough problems over time, that is absolutely something that their manager can and should address.
- xandrius 2y ago
  I'd think about actioning the individual only if it was exactly the same issue every time (how did the same issues manage pass time and time again, didn't we learn anything as a team?). Otherwise I'm more in the mentality that breakages are a great way to improve internal flows against (inevitable) failures. I think the real problem would be when a developer cannot manage to get any code into production (e.g. Code stuck in PR for weeks) but once the rest of the team and our systems approve it then they have proven their worth. Also, if developer X's code keeps passing code reviews, CI/CD, QA and UAT, and it's not the fault of the systems in place, I would ask myself what kind cutting edge stuff are they working on?

quietbritishjim 2y ago

I disagree, at least in this case. In the comment you're replying to, the new manager is technical and familiar with the codebase, and can assess that the reason for the rollbacks is a genuine quality issue. This is useful information, and if you leave it out then you leave your report partially in the dark, wondering if the rollbacks are happening for some other reason (I can think of plenty). I'm not saying it needs to literally be in the first sentence or phrased exactly like that, but I don't think that's what they meant anyway. Rather, you do need to be upfront about it instead of alluding to the problem without giving away what you actually think.

pdonis 2y ago
> the new manager is technical and familiar with the codebase, and can assess that the reason for the rollbacks is a genuine quality issue. This is useful information Only if the report doesn't already know it. But they probably do. It doesn't seem likely to me that the report would be in the dark about why the rollbacks happened. And if they already know it, it's better to let them ask for help than to tell them up front that you, their manager, know that their code quality is an issue. Give them a chance to identify the issue themselves first.
- cutemonster 2y ago
  Meanwhile, deployments keep getting rolled back? Sounds like this mistake: > > avoiding hard conversations with your reports. And hoping that things will get better soon. But: > > Sadly it is the single biggest cause for dissatisfaction that can also be among others in the team, who have to deal with the rollbacks.
  - pdonis 2y ago
    > Meanwhile, deployments keep getting rolled back? One could say that the scenario as described in the post I originally responded to, by localghost3000, doesn't make sense, yes. If there have already been multiple rollbacks, and this is the first conversation you as a manager are having about them with this report, then you as a manager have already messed up by not addressing the issue sooner. But that just makes it even more of a problem to lead with language like "quality issues in your code", implying that all the responsibility lies with the report, and none of it lies with you, the manager. The approach I described, where you focus first on the objective fact, that the rollbacks happened, and on how to keep them from happening again, avoids that.