72
Introducing Predictive Debugging: A Game-Changing Look into the Future (blog.jetbrains.com)
submitted 3 years ago by to c/programming@programming.dev
22 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 3 years ago (1 child)

Have you ever tried my approach? It also works for understanding existing code bases. It just takes some practice, like working a mental muscle. So it might seem strange and ineffective at first.

If you do lots of trial and error and use the debugger you're basically externalizing the work, which slows it down and is less satisfying too imo.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 3 years ago (1 child)

    I have indeed. We even practice pure TDD and won't accept PRs without test coverage, but it doesn't change the fact that sometimes bugs happen, and when they do it tends to be much more effective to work through the problem with a debugger than make guesses at what things need to be logged, or poked into or whatever.

    If what you're doing works for you, more power to you, but in my opinion I'd never give up a tool in my toolset because it makes me far more productive than I'd be without it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago

    I get where you're coming from, and debuggers surely have their merits. But I've found value in a more deliberate approach that emphasizes understanding and careful code review. Even when faced with legacy systems or larger teams, with practice, this technique can be quite effective. It's less about relinquishing tools, and more about harnessing those that harmonize with our individual coding styles. Granted, it's not a one-size-fits-all approach, but it's what works for me and others who prefer a similar path in coding.

  • permalink
  • fedilink
  • source
  • parent