12 ms·

Why would debugging be a team culture thing? It's very individual in practice.

by zaphar 2y ago

tantalor 2y ago
Agreed. I don't care how a team member debugs something as long as they can solve the issue.
- Terr_ 2y ago
  Let's flip that around and replace "debugging" with "coding" for a moment. Imagine you have a new junior developer on the team, and their deliverables seem okay. Then one evening you discover they've been staying late manually reformatting and reindenting all of their code using notepad before each commit. They explain this is because it's what they know will work reliably, and those other tools gave odd errors on their computer or had too many confusing options or needed some kind of bridge or dependency. I might be impressed with their work ethic, but I can't just not-care about the problem that has risen into view. (Unless I'm literally counting the days until I move elsewhere.)
  - tantalor 2y ago
    I suppose that's a fair analogy. But formatting is trivial whereas debugging is not.
TeMPOraL 2y ago
Yes, but then imagine saying on the next stand-up that you took a couple hours or a whole day on adding new NATVIS visualizers or GDB pretty-printers, and think of the reaction you'd get. Approval and interest, or eyerolls and comments on work prioritization? That is the difference between the two cultures. It matters at least because use of debuggers gets more effective with investment into support scripts and configs, in ways print-debugging doesn't.
Terr_ 2y ago
Debugging tooling is a team/project level issue just as much as local build/run steps and coding-style. The effects are just harder than see. Best practices and tricks for debugging a given project will impact things like: * The overall productivity of the team. * Writing guides and documentation. * CI/CD scripts, such as preventing accidental leakage of print statements. * How development environments are set up and configured, especially if there are containers or port forwarding or remote services involved. * How team members collaborate when there's more than one person trying to diagnose a problem. * Generally how you teach new juniors or experienced developers arriving with a learning curve.

Why would debugging be a team culture thing? It's very individual in practice.

by zaphar 2y ago

Why would debugging be a team culture thing? It's very individual in practice.

tantalor 2y ago

Agreed. I don't care how a team member debugs something as long as they can solve the issue.

Terr_ 2y ago
Let's flip that around and replace "debugging" with "coding" for a moment. Imagine you have a new junior developer on the team, and their deliverables seem okay. Then one evening you discover they've been staying late manually reformatting and reindenting all of their code using notepad before each commit. They explain this is because it's what they know will work reliably, and those other tools gave odd errors on their computer or had too many confusing options or needed some kind of bridge or dependency. I might be impressed with their work ethic, but I can't just not-care about the problem that has risen into view. (Unless I'm literally counting the days until I move elsewhere.)
- tantalor 2y ago
  I suppose that's a fair analogy. But formatting is trivial whereas debugging is not.

TeMPOraL 2y ago

Yes, but then imagine saying on the next stand-up that you took a couple hours or a whole day on adding new NATVIS visualizers or GDB pretty-printers, and think of the reaction you'd get. Approval and interest, or eyerolls and comments on work prioritization? That is the difference between the two cultures. It matters at least because use of debuggers gets more effective with investment into support scripts and configs, in ways print-debugging doesn't.

Terr_ 2y ago

Debugging tooling is a team/project level issue just as much as local build/run steps and coding-style. The effects are just harder than see. Best practices and tricks for debugging a given project will impact things like: * The overall productivity of the team. * Writing guides and documentation. * CI/CD scripts, such as preventing accidental leakage of print statements. * How development environments are set up and configured, especially if there are containers or port forwarding or remote services involved. * How team members collaborate when there's more than one person trying to diagnose a problem. * Generally how you teach new juniors or experienced developers arriving with a learning curve.