Live data from Hacker News

The Grug Brained Developer (2022)

grugbrain.dev

201–210 of 603 posts

Re: The Grug Brained Developer (2022)

#201
post #164

Earlier quoted context omitted.

OK yeah I see, that's natural to do with like rust enums Java doesn't support this though I thought?

Currently Java supports records (finalized in JDK 16) and sealed classes (JDK 17) which together work as algebraic data types; pattern matching in switch was finalized in JDK 21. The syntax is pretty sweet https://blog.scottlogic.com/2025/01/20/algebraic-data-types-...

oh thats cool. thanks for sharing!

Re: The Grug Brained Developer (2022)

#202

“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 s…

The rise of virtualization, containers, microservices, etc has I think contributed to this being more difficult. Even local dev-test loops often have something other than you launching the executable, which can make it challenging to get the debugger attached to it. Not any excuse, but another factor to be considered when adding infra layers between the developer and the application.

Debuggers are also brittle when working with asynchronous code

Debuggers actually can hide entire categories of bugs caused by race conditions when breakpoints cause async functions to resolve in a different order than they would when running in realtime

Re: The Grug Brained Developer (2022)

#203

“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 s…

Are you more productive with a debugger? For all bugs? How so?

Re: The Grug Brained Developer (2022)

#204

Earlier quoted context omitted.

There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program les…

There's another story I heard once from Rob Pike about debugging. (And this was many years ago - I hope I get the details right). He said that him and Brian K would pair while debugging. As Rob Pike told it, he would often drive the computer, putting in print statements, rerunning the program and so on. Brian Kernighan would stand behind him and quietly just think about the bug and the output the program was generati…

some of my best work as a programmer is done walking my dog or sitting in the forest

Re: The Grug Brained Developer (2022)

#205

Earlier quoted context omitted.

There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program les…

> Brian Kernighan and Rob Pike Most of us aren't Brian Kernighan or Rob Pike. I am very happy for people who are, but I am firmly at a grug level.

This! Also my guess would be Kernighan or Pike aren't (weren't?) deployed into some random codebase every now and then, while most grugs are. When you build something from scratch then you can get by without debuggers, sure, but foreign codebase, a stupid grug like I can do much better with tools.

Re: The Grug Brained Developer (2022)

#206
post #116

Earlier quoted context omitted.

Being at a firm where the decision to use C++ was made, the thought process went something like this: "We're going to need to fit parts of this into very constrained architectures." "Right, so we need a language that compiles directly to machine code with no runtime interpretation." "Which one should we use?" "What about Rust?" "I know zero Rust developers." "What about C++?" "I know twenty C++ developers and am conf…

And none of those 20 C++ developers can learn rust? What’s wrong with them?

They're probably busy writing code for a living.

Re: The Grug Brained Developer (2022)

#207

Earlier quoted context omitted.

I would tend to say that printf debugging is widespread in the Linux-adjacent world because you can't trust a visual debugger to actually be working there because of the general brokenness of GUIs in the Linux world. I didn't really get into debuggers until (1) I was firmly in Windows, where you expect the GUI to work and the LI to be busted, and (2) I'd been burned too many times by adding debugging printfs() that g…

Why would you want a GUI debugger?

Honestly, I consider myself pretty comfortable with the terminal and vim and whatnot, but I've never been able to get into using GDB. For me I feel like a debugger is one of those things that's just so much better as a proper GUI.

Re: The Grug Brained Developer (2022)

#208

“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 s…

There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program les…

On the other hand, John Carmack loves debuggers - he talks about the importance of knowing your debugging tools and using them to step through a complex system in his interview with Lex Friedman. I think it's fair to say that there's some nuance to the conversation.

My guess is that:

- Debuggers are most useful when you have a very poor understanding of the problem domain. Maybe you just joined a new company or are exploring an area of the code for the first time. In that case you can pick up a lot of information quickly with a debugger.

- Print debugging is most useful when you understand the code quite well, and are pretty sure you've got an idea of where the problem lies. In that case, a few judicious print statements can quickly illuminate things and get you back to what you were doing.

Re: The Grug Brained Developer (2022)

#209

Earlier quoted context omitted.

There's another story I heard once from Rob Pike about debugging. (And this was many years ago - I hope I get the details right). He said that him and Brian K would pair while debugging. As Rob Pike told it, he would often drive the computer, putting in print statements, rerunning the program and so on. Brian Kernighan would stand behind him and quietly just think about the bug and the output the program was generati…

some of my best work as a programmer is done walking my dog or sitting in the forest

[deleted]

Re: The Grug Brained Developer (2022)

#210
I avoided this page since it was a terrible programmer at work who shared it to me a couple years back. The title and the writing style made me think of him in new depths. Perhaps there’s something here for it to trend in HN, but I’m sure it resonates to all skill levels of programmers in wildly different ways—the comments are only an illusion of consensus and wisdom.
Post reply on HN