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
Kudos to the people who wrote this and it’s great for people who use debuggers.
However I’d like to say that I haven’t used one in years and don’t see any reason to go back.
I’ve found that there’s way simpler practices that have upped my development speed considerably. Simply think about what you’re trying to do more carefully, and read over the code until you’re sure it’s good. It’s the fastest way to iterate. Doesn’t work? Read and think again.
You can put a format log in there. You can even comment it out, which can be useful later and for other people. It’s plain and simple.
When I find myself using log all the time, it’s either because I am tired, and I shouldn’t be coding any way. Or impatient, which means I’m wasting time and should slow down. Or I have to deal with a library that has a shitty API, which you’ll probably want to avoid using any way. And in that case you can use the interactive console to quickly try things out.
Honestly if there’s anything I want to get better at it’s test driven development. It tells you clearly whether it’s working as expected or not.
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.
Since adopting TDD, my debugger use has really dropped off. I think it’s partially due to TDD encouraging me to develop more pure functions and push side effects to injectable (and thus mockable) objects.
But every so often I encounter a state that I can’t understand how the code gets into, and in those cases being able to step through everything that’s going on is incredibly helpful.
I may not use my debugger every day, but when I want it, I’m sure glad it’s there.
When I have a real head scratcher like that I use log with a b c d. It’s rare though and mostly due to me not paying attention or due to some convoluted calling graph.
Ya I’ve also switched to functional wherever possible. I still use objects for di.
It’s a little hard to iterate and think when you’re adding to a complicated codebase you might not have worked with in several months, or even just a portion of a project that’s seemed stable for a long time. In that scenario, debuggers are able to shorten the getting up to speed process by quite a bit.
Kudos to the people who wrote this and it’s great for people who use debuggers.
However I’d like to say that I haven’t used one in years and don’t see any reason to go back.
I’ve found that there’s way simpler practices that have upped my development speed considerably. Simply think about what you’re trying to do more carefully, and read over the code until you’re sure it’s good. It’s the fastest way to iterate. Doesn’t work? Read and think again.
You can put a format log in there. You can even comment it out, which can be useful later and for other people. It’s plain and simple.
When I find myself using log all the time, it’s either because I am tired, and I shouldn’t be coding any way. Or impatient, which means I’m wasting time and should slow down. Or I have to deal with a library that has a shitty API, which you’ll probably want to avoid using any way. And in that case you can use the interactive console to quickly try things out.
Honestly if there’s anything I want to get better at it’s test driven development. It tells you clearly whether it’s working as expected or not.
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.
Since adopting TDD, my debugger use has really dropped off. I think it’s partially due to TDD encouraging me to develop more pure functions and push side effects to injectable (and thus mockable) objects.
But every so often I encounter a state that I can’t understand how the code gets into, and in those cases being able to step through everything that’s going on is incredibly helpful.
I may not use my debugger every day, but when I want it, I’m sure glad it’s there.
When I have a real head scratcher like that I use log with a b c d. It’s rare though and mostly due to me not paying attention or due to some convoluted calling graph.
Ya I’ve also switched to functional wherever possible. I still use objects for di.
Same here! Testing up front has made it extremely rare that I have to go back with a debugger later.
It’s a little hard to iterate and think when you’re adding to a complicated codebase you might not have worked with in several months, or even just a portion of a project that’s seemed stable for a long time. In that scenario, debuggers are able to shorten the getting up to speed process by quite a bit.
My favorite tool in that case is jump to definition.