Using a debugger

"debugging in the sunset" generated by Midjourney

I'm a log statement debugger. I remember my first job as a software engineer and my boss showing me how great the browser debugger is for understanding code in javascript. I tried it a few times but it never really stuck. Instead I opted to brute force through bugs with log statements.

This has quite a few downsides. In particular, it's much more difficult to debug code outside of the code you wrote. If I want to inspect functions from other libraries -- including standard libraries -- I'd have to find where the library is located in my filesystem and add log statements there. Not great. Another major downside is the debugging workflow. Everytime I want to log a variable, I have to add the log statement and then rebuild and run the code again. It can be pretty slow sometimes.

This habit persisted until John Carmack debug-shamed me on Lex Friedman's podcast.

If John Carmack is telling me I'm missing something, I should probably listen. So I put my bad habits back in my toolbelt and decided to try to debug using an actual debugging tool.

Recently I've been doing quite a bit of work in golang. The entire pico ecosystem of services are built using golang.

One thing that I did not want to do is switch away from my terminal-based workflow. All the debuggers I've seen colleagues use are embedded inside their IDE. I use neovim so I first started by going to neovimcraft¹ and searching for golang debuggers.

It seems that delve is the most popular debugger for golang.

After looking at the neovim integrations, I decided that they were not going to work for me. I like to keep my plugin list minimal because I tend to forget what I have installed.

Instead I decided to use the CLI tool dlv that comes with delve.[^2] It's a little more manual, but when I'm trying to learn something new I tend to go with the easiest implementation in order to learn how it works. Adding an integration in between me and delve was too much overhead for me to think about immediately.

After using this tool for a couple of weeks, I learned how to:

• run it with web and ssh servers
• step through a program
• add/remove breakpoints
• rebuild the code when I make a change
• print/set variables
• call functions

I have definitely noticed an improvement in how quickly I can debug an issue. Like John Carmack mentioned, when building a new feature, I often start by running the server inside the debugger.

Another clear benefit is that I'm finding myself debugging library code a lot more. I'm reading the code as I'm debugging, finding issues, and then submitting tickets or patches to those projects. Libraries feel less like black boxes and more porous. They feel within my grasp.

So thank you John Carmack for helping me understand what I was missing.