Why I Can't Code Without a Debugger and IDEs?
Warning: This is strictly an opinion piece.I don't get it; why wouldn't you want to use an interactive debugger? There is tension in this question and maybe in my opinion, and my opinion could stem from how I grew up as developer in the PC world, which to note, I have left the PC world behind many years ago. I love linux and used it professionally, currently I am using MacOS professionally, which is a fair middle ground.
I'm genuinely curious about the "no debugger" mentality. After years of iterating my development workflow across countless editors/IDEs Notepad++, Borland C/C++, Visual Studio, neovim, VS Code, and Jetbrains IDEs; When I use a development tool that does not have interactive debugger, I come back to one conclusion, "I miss the debugger too much when it's gone."
This doesn't answer the question yet so lets carry on :)
The year was 2000, end of the world!
What a year the turn of the millennium was, the world didn't end. But print statements in my code did! This is the year I tried Borland C/C++. What an IDE it was! A game changer in my dev flow, this was my introduction into interactive debugging and I haven't looked back, well I tried a few times after this, unsuccessfully!
The Cave Analogy
Here's the difference between console logging and interactive debugging:
With print statements, you're standing at the mouth of a cave, sending someone else in. They yell back: "Yep, there are fantastic colored gems and it smells like minerals and salts." You nod, satisfied with the report.
With interactive debugging, you explore the cave yourself in real-time. You see the gems, smell the minerals, feel the texture. The experience is incomparable.
That's the magic. Step through code line by line, inspect variables as they change, watch execution unfold. You're inside the code itself, not hearing about it secondhand.
Beyond Bug Fixing
Many devs think debuggers are just for fixing bugs, they're not. Interactive debugging is how I explore unfamiliar codebases, understand complex logic, and satisfy my curiosity about how code actually executes. It's an adventure! Something I look forward to when a new code base is put in front of me!
The neovim Dilemma
I genuinely love neovim. The minimal aesthetic, lightweight feel, vim motions, and snappy performance are special. I was 100% committed to making the switch. But the debugging support was so subpar that it killed my motivation. I suspect the neovim community's "I don't use debuggers" stance stems partly from this frustration when debugging is soooo painful. I can see how you would learn to avoid it or take a different perspective on debugging.
The IDE Trade offs
Visual Studio has amazing debugging, but the heaviness is unbearable.
goland (my daily driver) offers the best debugging experience I've found, though it's heavier than I'd like, I appreciate that you get the same experience on winblowz, macOS, and linux
**Zed** is exciting! It's lean, mean, and the debugging experience keeps getting better. The AI features are done well and growing on me. I'm eyeing it for professional work; I use it as my daily driver outside of work. TBH, I would use it now for work but zed only supports github login, and since I use one github account for both work and off work ... it is a bit tricky ATM, I want to use Pro features and have my personal and work subscriptions separate.
We got off track a bit so back to debugging!
Why It Matters at Scale
Here's what I don't understand about the anti-debugger crowd: as your projects grow, console logging doesn't scale. Print statements get sprinkled everywhere, after you are done with them, you become a dust pan trying to sweep them all up. You'll miss some. Adding and removing debugging logs becomes tedious busywork.
With an interactive debugger, you're surgical. You set a break point, step through the exact code path you care about, dissecting the code, inspecting the exact state you need and throw some conditional break points in there, yum! It's a first class experience.
In my day to day I work on a complex banking system, and yeah sometimes I do get away with print statement debugging, and I do use it occasionally still, I use it to see output in another service, but when I really dig into bugs or understanding a code base, it is a supplement at best. My goto: when exploring the interactions between services, is to run more than one service in debug mode. It gets complicated but, is still highly do able. Aerospace tile manager for MacOS is mandatory for (me) multi-service debugging. I can max out 3 services per workspace! Watch your ram :) (ram ... this is also why I would like to move to Zed from goland)
The debugger does not:
1. replace logging
2. replace a good test suite
3. replace instrumentation and observability
I have heard some arguments you don't need a debugger if you have the above done really well, it is also rare that all three of those points are done really well! They are defiantly essential in production; But while developing sometimes you will need to debug you tests, or use the tests as an entry point for interactive debugging.
Closing thoughts
Every developer/engineer has there own style and tools, which I find fascinating. The main point of my digitized thought was, nothing really just my opinion, but I hope my opinion gets you to explore the world of interactive debugging, it isn't new, it isn't cutting edge, it's something that has been around for a very long time. But to me it is one of the most useful tools in the tool shed.
If you would like to add a comment in the comment section do a pull request on file: debuggers-ide.html
clone:
gh repo clone latebit-io/latebit
[email protected]:latebit-io/latebit.git
https://github.com/latebit-io/latebit.git