←back to thread

The Grug Brained Developer (2022)

(grugbrain.dev)
1087 points smartmic | 10 comments | 17 Jun 25 20:24 UTC | HN request time: 1.298s | source | bottom
Show context
titanomachy ◴[17 Jun 25 23:45 UTC] No.44305194[source]▶
“Good debugger worth weight in shiny rocks, in fact also more”

I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow.

I generally agree that it’s the best way to start understanding a system. Breaking on an interesting line of code during a test run and studying the call stack that got me there is infinitely easier than trying to run the code forwards in my head.

Young grugs: learning this skill is a minor superpower. Take the time to get it working on your codebase, if you can.

replies(48): >>44305342 #>>44305375 #>>44305388 #>>44305397 #>>44305400 #>>44305414 #>>44305437 #>>44305534 #>>44305552 #>>44305628 #>>44305806 #>>44306019 #>>44306034 #>>44306065 #>>44306133 #>>44306145 #>>44306181 #>>44306196 #>>44306403 #>>44306413 #>>44306490 #>>44306654 #>>44306671 #>>44306799 #>>44307053 #>>44307204 #>>44307278 #>>44307864 #>>44307933 #>>44308158 #>>44308299 #>>44308373 #>>44308540 #>>44308675 #>>44309088 #>>44309822 #>>44309825 #>>44309836 #>>44310156 #>>44310430 #>>44310742 #>>44311403 #>>44311432 #>>44311683 #>>44312050 #>>44312132 #>>44313580 #>>44315651 #
geophile ◴[18 Jun 25 00:54 UTC] No.44305628[source]▶
I am also in the camp that has very little use for debuggers.

A point that may be pedantic: I don't add (and then remove) "print" statements. I add logging code, that stays forever. For a major interface, I'll usually start with INFO level debugging, to document function entry/exit, with param values. I add more detailed logging as I start to use the system and find out what needs extra scrutiny. This approach is very easy to get started with and maintain, and provides powerful insight into problems as they arise.

I also put a lot of work into formatting log statements. I once worked on a distributed system, and getting the prefix of each log statement exactly right was very useful -- node id, pid, timestamp, all of it fixed width. I could download logs from across the cluster, sort, and have a single file that interleaved actions from across the cluster.

replies(4): >>44305698 #>>44306106 #>>44306184 #>>44308522 #
1. hobs ◴[18 Jun 25 01:08 UTC] No.44305698[source]▶
A log is very different than a debugger though, one tells you what happened, one shows you the entire state and doesn't make you assemble it in your head.
replies(3): >>44305705 #>>44306783 #>>44307219 #
2. demosthanos ◴[18 Jun 25 01:11 UTC] No.44305705[source]▶
Your framing makes it sound like the log is worse in some way, but what the log gives you that the debugger makes you assemble in your head is a timeline of when things happen. Being able to see time is a pretty big benefit for most types of software.

I can always drop an entire state object into the log if I need it, but the only way for a debugger to approximate what a log can give me is for me to step through a bunch of break points and hold the time stream in my head.

The one place where a debugger is straight up better is if I know exactly which unit of code is failing and that unit has complicated logic that is worth stepping through line by line. That's what they were designed for, and they're very useful for that, but it's also not the most common kind of troubleshooting I run into.

replies(2): >>44305762 #>>44306116 #
3. hobs ◴[18 Jun 25 01:20 UTC] No.44305762[source]▶
It's not worse or better, but its not really comparable is all I am really saying, I would not use them for the same things.
4. switchbak ◴[18 Jun 25 02:25 UTC] No.44306116[source]▶
In the early 2000’s I whipped up a tool to convert log statements into visual swim lanes like the Chrome profiler does. That thing was a godsend for reasoning about complex parallelism.
replies(1): >>44306842 #
5. fingerlocks ◴[18 Jun 25 04:57 UTC] No.44306783[source]▶
All these print debugging advocates are blowing my mind. Are most people unaware that both lldb and gdb have conditional pass throughout breakpoints with function hooks? In other words, you can create a breakpoint that just prints its location and doesn’t pause execution.

You can script this so all function entry/exists, or whatever, are logged without touching the code or needing to recompile. You can then bulk toggle these breakpoints, at runtime, so you only see a particular subset when things get interesting.

Modifying the code to print stuff will feel barbaric after driving around a fine tuned debugging experience.

replies(1): >>44306941 #
6. EFreethought ◴[18 Jun 25 05:11 UTC] No.44306842{3}[source]▶
Would you be willing to share this tool?
replies(1): >>44371705 #
7. dpkirchner ◴[18 Jun 25 05:40 UTC] No.44306941[source]▶
I can't tell you how many times lldb has failed to hit breakpoints or has dumped me in some library without symbols. This was in Xcode while writing an iOS app, maybe it's better in other environments.

Print debugging, while not clever or powerful, has never once failed me.

replies(1): >>44307151 #
8. fingerlocks ◴[18 Jun 25 06:28 UTC] No.44307151{3}[source]▶
Sometimes the debugserver is flakey, I’ll give you that. But some that also sounds like UI quirks such as ambiguous breakpoints on a function definition with default initialized default values.

You can attach lldb without Xcode. Or you can open the lldb terminal in Xcode, pause execution, and inspect the breakpoints manually

9. mort96 ◴[18 Jun 25 06:41 UTC] No.44307219[source]▶
I've never had a debugger show me the entire state. I'm not even sure I want to know the entire state, but GDB has a lot of issue with anything but the most basic data structures most of the time, and I always need to explicitly ask for what I want to see by calling things like operator[] (and then hope that the particular operator[] wasn't optimized out of the final binary). It's not exactly a great experience.
10. switchbak ◴[24 Jun 25 22:27 UTC] No.44371705{4}[source]▶
Oh that's long lost to the trashbin of history. As I recall it was a combination of:

- Log4j + MDC's so we could get a timestamp and thread ID easily

- some python scripting

I can't remember if it was PDF or SVG, but I do remember having to choose something that would allow for huge graphs and lots of scrolling!

These days there's better options on github, but nice to see I was on a decent path.