3 ms·

Have you tried using a debugger at all? I see people who've resisted for years become mega fans when they finally try one. I also see people who use them all

Have you tried using a debugger at all? I see people who've resisted for years become mega fans when they finally try one. I also see people who use them all the time but reluctantly - I'd love to know what the difference is.

gnulinux 3y ago
Yes I used debuggers many many times, I'm also relatively experienced with e.g. gdb commands syntax etc. It doesn't seem to fit my workflow for various reasons. In very short, my development style is some form of extreme TDD: when I write code it's almost always of the form "write test, red, write code, still red, write code, green" loop. I know many people hate it but this is what I came to like over the many years and this is what makes me productive the most. I am working on adopting different development paradigms recently though.
- mark_undoio 3y ago
  That certainly makes sense - and that tight loop is very compelling. What if you have to solve a bug outside of the development loop though? E.g. a bug somewhere in the whole system after you've done your development, where you don't have a root cause yet?
  - gnulinux 3y ago
    I write integration tests as well as unittests, but mostly integration tests, to a reasonable extent. I also don't commit all integration tests if it's impractical e.g. makes the test suite too slow, instead have equivalent unittests. I use integration test to understand the underlying bug, then write a unittest. But, truthfully, to understand where to begin with, I religiously use logs. Normally prod logs are disabled or silenced, so the first step of debugging is enabling logs, reproduce the error in prod, get logs. Then, I inspect the logs and develop a hypothesis where the bug is. I write an integration test reproducing the exact same bug, red, I fix the bug, green. Then, I decide whether I want to commit this test, is it useful, is it fast enough. If so, we're done. Otherwise, I undo my commit, I write a unittest, red, apply the previous fix as-is, green. As you see, this is a mix of printf() debugging (logs are essentially printf statements) and TDD. One problem with this approach is, of course, if your logs aren't sufficient you may not now where to start. Then, you need to either ssh into a dev env and play around, or recreate the infra on you laptop and use a debugger to step through. I make sure my logs and tests are excellent in order to prevent these scenarios though, I also make sure the system is idempotent so that it's easy to reproduce bugs (because leadership tends not to like verbose logging enabled in prod due to storage costs, this means before reproducing a bug you need enable logs).
pas 3y ago
I grew up on PHP (xdebug, var_dump, and stepping through the code) and C# with Visual Studio. Compared to this gdb is just meh. I know, I know, Rust compiles to a nice binary, there's no runtime/vm/interpreter/JIT/intermediate-language/bytecode... but that's not what I miss in gdb, I miss the discoverability, the visual representation, the whole I from the IDE concept.

gnulinux 3y ago

Yes I used debuggers many many times, I'm also relatively experienced with e.g. gdb commands syntax etc. It doesn't seem to fit my workflow for various reasons. In very short, my development style is some form of extreme TDD: when I write code it's almost always of the form "write test, red, write code, still red, write code, green" loop. I know many people hate it but this is what I came to like over the many years and this is what makes me productive the most. I am working on adopting different development paradigms recently though.

mark_undoio 3y ago
That certainly makes sense - and that tight loop is very compelling. What if you have to solve a bug outside of the development loop though? E.g. a bug somewhere in the whole system after you've done your development, where you don't have a root cause yet?
- gnulinux 3y ago
  I write integration tests as well as unittests, but mostly integration tests, to a reasonable extent. I also don't commit all integration tests if it's impractical e.g. makes the test suite too slow, instead have equivalent unittests. I use integration test to understand the underlying bug, then write a unittest. But, truthfully, to understand where to begin with, I religiously use logs. Normally prod logs are disabled or silenced, so the first step of debugging is enabling logs, reproduce the error in prod, get logs. Then, I inspect the logs and develop a hypothesis where the bug is. I write an integration test reproducing the exact same bug, red, I fix the bug, green. Then, I decide whether I want to commit this test, is it useful, is it fast enough. If so, we're done. Otherwise, I undo my commit, I write a unittest, red, apply the previous fix as-is, green. As you see, this is a mix of printf() debugging (logs are essentially printf statements) and TDD. One problem with this approach is, of course, if your logs aren't sufficient you may not now where to start. Then, you need to either ssh into a dev env and play around, or recreate the infra on you laptop and use a debugger to step through. I make sure my logs and tests are excellent in order to prevent these scenarios though, I also make sure the system is idempotent so that it's easy to reproduce bugs (because leadership tends not to like verbose logging enabled in prod due to storage costs, this means before reproducing a bug you need enable logs).

pas 3y ago

I grew up on PHP (xdebug, var_dump, and stepping through the code) and C# with Visual Studio. Compared to this gdb is just meh. I know, I know, Rust compiles to a nice binary, there's no runtime/vm/interpreter/JIT/intermediate-language/bytecode... but that's not what I miss in gdb, I miss the discoverability, the visual representation, the whole I from the IDE concept.