Using a debugger

September 2, 2022 on Eric Bower's blog

debugging in the sunset “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 neovimcraft1 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:

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.

  1. A neovim plugin directory (that I built) ↩︎

  2. How many other people use dlv directly? I’m curious if this is a common way to interact with delve↩︎

Articles from blogs I read

Generated by openring

How to help improve SourceHut's design

SourceHut is a software development forge and it is designed with the software engineer’s needs first and foremost. The design prioritizes things like page speed, minimal distractions, and information-forward layouts. It does not prioritize aesthetics, and p…

via Blogs on Sourcehut October 13, 2022

In praise of ffmpeg

My last “In praise of” article covered qemu, a project founded by Fabrice Bellard, and today I want to take a look at another work by Bellard: ffmpeg. Bellard has a knack for building high-quality software which solves a problem so well that every other solu…

via Drew DeVault's blog October 12, 2022

Site Update: HLS support

Hi blog readers! It's time for a regular update on stuff I've gained expertise in frantically googled and hacked together so I can put it in front of your faces. I use YouTube as a video hosting service because it's largely predictable and it'…

via Xe's Blog October 11, 2022