My debug process

It’s not special at all, just how I do it :)


This is my process to figure out what’s wrong with pretty much anything (not that I can figure out everything, but it’s my go-to process to everything). It’s language agnostic and what I suppose you can call “fast paced”.

I think it’s specially useful when debugging code bases I don’t know, given that I can’t assume anything, just follow the code and see where it leads me to. But as always, YMMV.

1. Search for keywords, find out what’s the dependency that holds your attributes of interest.

Main tools:

The process is simple, if you don’t know where something is defined you just search it everywhere you can until you see a meaningful result. If you already know where something is coming from, then start going around doing cmd+click at stuff.

2. Log log log

Use fmt or log packages (or any other log package available in the code you are debugging) to print:

3. Reduce search area, clean and repeat

Once you are pretty sure that something is not related to the issue, you can remove those log statements.

For example, if you see in the command line HERE!: 1 and HERE!: 2, but not HERE!: 3 then you are 100% that something’s failing between log 2 and 3.

You can now cmd+click whatever is there and start over from step 1.

Why not use the debugger?

I tend to use the debugger when:

If the debugger is a sniper rifle then my process above is a machine gun. With the sniper rifle you know who your target is, while with the machine gun we are just shooting in the dark hoping to hit something.

Counter Strike analogy aside, my process = broad debug, debugger = narrow debug.

Also in Go’s case, it’s faster to write log statements and re-run the code than to wait for the debugger to initialize every time you make a change (or maybe I have a shitty computer).