With the introduction of debugging tools, software developers were empowered to interactively investigate the control flow of software programs to find bugs in live environments. At JetBrains, we've a
I feel like you’re missing out on a ton of awesome features by not using a debugger? Step backs are super useful, inline/live commands save you from re-running the code to see a different value, you can change values on the fly.
And it’s nice to say “think about your code more” but when you’re working with large teams, on legacy codebases, you don’t often have the opportunity to “think about your code” because you’re trying to decipher what someone wrote 3 years ago and they don’t even work with the company anymore.
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.
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.
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.
I feel like you’re missing out on a ton of awesome features by not using a debugger? Step backs are super useful, inline/live commands save you from re-running the code to see a different value, you can change values on the fly.
And it’s nice to say “think about your code more” but when you’re working with large teams, on legacy codebases, you don’t often have the opportunity to “think about your code” because you’re trying to decipher what someone wrote 3 years ago and they don’t even work with the company anymore.
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.
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.
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.