4 ms·

4) whodunit?

• TheDong 9y ago
  Blaming people is almost never a good idea. It can very easily lead to a toxic environment. It's often helpful to know who did it and have that person involved in fixing it and looking for other cases since they're likely to know that area of the code and best understand the thought process that ended up there. However, it should never be done with any sort of 'blame' or 'fault'. It's something to handle with care.
  • joshribakoff 9y ago
    If a particular person keeps breaking things by skipping code reviews and such then you may already have a toxic environment. That person needs to be talked to, not necessarily chastised, but talked to for sure.
    • sdenton4 9y ago
      Ahhhhhh!!!! Skipping code reviews is asking for breakages! And it's not even that person's fault, if the broader team allows unreviewed coffee to be checked in. Of course, one of the other great things about code review is that it diffuses blame, and allows us to focus on other things. If Dev A introduced a bug even after Dev B reviewed the code, then the root problem isn't that Dev A is a dummy. One needs some openness to changing process to prevent future bugs; process questions are a key part of a postmortem.
      • andirk 9y ago
        "great things about code review is that it diffuses blame" Yes! A code author and code reviewer(s) have equally signed off on it. Personally I always want to know if something I did has affected people in whatever way so that I can learn from it.