Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Grug Brained Developer (2022)

grugbrain.dev

Post reply on HN
Print view View original

181–190 of 603 posts

Re: The Grug Brained Developer (2022)

#181

Post by shadowgovt »

titanomachy wrote: post #115

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

It has gotten to the point where when somebody wants to add a DSL to our architecture one of my first questions is "where is your specification for integrating it to the existing debuggers?"

If there isn't one, I'd rather use a language with a debugger and write a thousand lines of code than 100 lines of code in a language I'm going to have to black box.

Re: The Grug Brained Developer (2022)

#182

Post by XorNot »

sethjgore wrote: post #173
recursivedoubts wrote: post #169

Earlier quoted context omitted.

I think a lot of “naturals” find visual debuggers pointless, but for people who don’t naturally intuit how a computer works it can be invaluable in building that intuition. I insist that my students learn a visual debugger in my classes for this reason: what the "stack" really is, how a loop really executes, etc. It doesn't replace thinking & print debugging, but it complements them both when done properly.

What do you mean “visual debugger?”

Presumably an IDE rather then dealing the gdb CLI.

Re: The Grug Brained Developer (2022)

#184

Post by anonymars »

magarnicle wrote: post #99

I know, I get it, but I've realised that I'm not actually grug-brained. The way my brain works, I remember things pretty well; I like to get into the details of systems. So if more complexity in the code means the app can do more or a task is automated away I'll make the change and know I'll be able to remember how it works in the future. This doesn't mean OP is bad advice, just make a conscious decision about what t…

What about the rest of your team?

Re: The Grug Brained Developer (2022)

#186

Post by porridgeraisin »

sethjgore wrote: post #173
recursivedoubts wrote: post #169

Earlier quoted context omitted.

I think a lot of “naturals” find visual debuggers pointless, but for people who don’t naturally intuit how a computer works it can be invaluable in building that intuition. I insist that my students learn a visual debugger in my classes for this reason: what the "stack" really is, how a loop really executes, etc. It doesn't replace thinking & print debugging, but it complements them both when done properly.

What do you mean “visual debugger?”

In vscode when you step to the next statement it highlights in the left pane the variables that change. Something like that.

It's useful for a beginner e.g in a for loop to see how `i` changes at the end of the loop. And similarly with return values of functions and so on.

Re: The Grug Brained Developer (2022)

#187

Post by switchbak »

geophile wrote: post #147
titanomachy wrote: post #115

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

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 ver…

What I find annoying is how these async toolkits screw up the stack trace, so I have little what the real program flow looks like. That reduces much of the benefit off the top.

Some IDEs promise to solve that, but I’ve not been impressed thus far.

YMMV based on language/runtime/toolkit of course. This might get added to my wishlist for my next language of choice.

Re: The Grug Brained Developer (2022)

#189

Post by alisonatwork »

roncesvalles wrote: post #123
titanomachy wrote: post #115

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

I'd love to use a real debugger but as someone who has only ever worked at large companies, this was just never an option. In a microservices mesh architecture, you can't really run anything locally at all, and the test environment is often not configured to allow hooking up a stepping debugger. Print debugging is all you have. If there's a problem with the logging system itself or something that crashes the program…

This is basically it. When I started programming in C, I used a debugger all the time. Even a bit later doing Java monoliths I could spin up the whole app on my local and debug in the IDE. But nowadays running a dozen processes and containers and whatnot, it's just hopeless. The individual developer experience has gone very much backwards in the microservice era so the best thing to do is embrace observability, feature toggles etc and test in prod or a staging environment somewhere outside of your local machine.

Re: The Grug Brained Developer (2022)

#190

Post by switchbak »

demosthanos wrote: post #155
hobs wrote: post #154

Earlier quoted context omitted.

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.

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 bu…

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.
Post reply on HN