4 ms·

So sure, bugs happen, regardless of how good you are. But there really are some people who constantly make mistakes, and those that rarely do. There are peopl

So sure, bugs happen, regardless of how good you are. But there really are some people who constantly make mistakes, and those that rarely do. There are people on my team where, when there is a bug, I just start looking at diffs of what they have committed because more likely than not, they caused the problem. I think it's important to reinforce an attitude of trying to become better and people who give a shit when they make mistakes tend to also be the ones who make less of them.

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
erikbye 6y ago
> There are people on my team where, when there is a bug, I just start looking at diffs of what they have committed because more likely than not, they caused the problem. If you can tell the bug from looking at diffs, why was the bug not caught in code review or by tests? Most obvious bugs should be caught this way.
- lidHanteyk 6y ago
  In my experience, it's because Thing 1 and Thing 2 can review each others' code, and have no compunctions about potential bugginess. Somebody else gets to pick up after both of them, and is always outvoted during team code review. It's like giving a minority report, honestly.
  - danenania 6y ago
    Code review also isn't great at catching the kinds of edge cases that lead to many production bugs. Even tests only help you so much, because if you forget about input X or state Y or api result Z while writing the code, you're likely to forget about it when writing tests too. This is why bugs are more or less inevitable in systems beyond a certain level of complexity that are being actively worked on, and why engineers who think very carefully about anything that could go wrong will produce far fewer bugs than sloppy engineers who try to use process as a safety net.
Libeste 6y ago
It's more important to identify the root of the problem and actually solve it. Even if these people suck at coding and are still committing code without someone else double-checking their work, they're not the real problem.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

erikbye 6y ago

> There are people on my team where, when there is a bug, I just start looking at diffs of what they have committed because more likely than not, they caused the problem. If you can tell the bug from looking at diffs, why was the bug not caught in code review or by tests? Most obvious bugs should be caught this way.

lidHanteyk 6y ago
In my experience, it's because Thing 1 and Thing 2 can review each others' code, and have no compunctions about potential bugginess. Somebody else gets to pick up after both of them, and is always outvoted during team code review. It's like giving a minority report, honestly.
- danenania 6y ago
  Code review also isn't great at catching the kinds of edge cases that lead to many production bugs. Even tests only help you so much, because if you forget about input X or state Y or api result Z while writing the code, you're likely to forget about it when writing tests too. This is why bugs are more or less inevitable in systems beyond a certain level of complexity that are being actively worked on, and why engineers who think very carefully about anything that could go wrong will produce far fewer bugs than sloppy engineers who try to use process as a safety net.

Libeste 6y ago

It's more important to identify the root of the problem and actually solve it. Even if these people suck at coding and are still committing code without someone else double-checking their work, they're not the real problem.