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

471–480 of 603 posts

Re: The Grug Brained Developer (2022)

#471

Post by bogomog »

bregma wrote: post #348
nc0 wrote: post #291

Earlier quoted context omitted.

You also have to remember the context. First that visual debugging was still small and niche, probably not suited to the environment at Bell Labs at the time, given they were working with simpler hardware that might not provide an acceptable graphical environment (which can be seen as a lot of the UNIX system is oriented around the manipulation of lines of text). This is different from the workplace where most game d…

Why the emphasis on the use of cartoons (graphical debuggers) for analyzing problems with the text of computer code?

I think graphical debuggers are a big help: 1. It separates the meta-information of the debugger into the graphical domain. 2. It's easier to browse code and set/clear breakpoints using the mouse than the keyboard.

Re: The Grug Brained Developer (2022)

#472

Post by owlstuffing »

norir wrote: post #460
owlstuffing wrote: post #452

Earlier quoted context omitted.

Their comment conflates debugging with logging. Professional debuggers such as the one in IntelliJ IDEA are invaluable regardless of one's familiarity with a given codebase, to say otherwise is utter ignorance. Outside of logging, unless attaching a debugger is impractical, using print statements is at best wasting time.

Perhaps consider that your experience is not universal and that others have good reasons for their decisions that are not simply ignorance.

I didn't say there aren't acceptable reasons to reach for the print statement, there are. But for the vast majority of codebases out there, if good debugger tooling is available, it's a crime not to use it as a primary diagnostics tool. Claiming otherwise is indeed ignorant if not irresponsible.

Re: The Grug Brained Developer (2022)

#473

Post by sapiogram »

chickenzzzzu wrote: post #441
johnfn wrote: post #431

Earlier quoted context omitted.

I posted this elsewhere in the thread, but if you listen to Carmack in the interview, it's quite interesting. He would occasionally use one to step through an entire frame of gameplay to get an idea of performance and see if there were any redundancies. This is what I mean by "doesn't understand the problem domain". He's a smart guy, but no one could immediately understand all the code added in by everyone else on th…

Thankfully, we live in an era where entire AAA games can be written almost completely from scratch by one person. Not sarcasm. If I wrote the code myself, I know where almost everything is that could go wrong. It should come as no surprise that I do not use a debugger.

AAA games are not even close to being write-able by one person, what are you talking about. You couldn't even write AAA games from 20 years ago.

Re: The Grug Brained Developer (2022)

#474

Post by noisy_boy »

rusk wrote: post #287
josephg wrote: post #194

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…

It’s amazing what even the most subtle perturbation in output can tell you about the internal state of the code.

where you=Brian

Re: The Grug Brained Developer (2022)

#475

Post by kakuri »

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 loved Chrome's debugger for years, then build tools and React ruined debugging for me.

Built code largely works with source maps, but it fails often enough, and in bizarre ways, that my workflow has simply gone back to console logs.

React's frequent re-renders have also made breakpoints very unpleasant - I'd rather just look at the results of console logs.

Are there ways I can learn to continue enjoying the debugger with TS+React? It is still occasionally useful and I'm glad its there, but I have reverted to defaulting to console logs.

Re: The Grug Brained Developer (2022)

#476

Post by noisy_boy »

owlstuffing wrote: post #472
norir wrote: post #460

Earlier quoted context omitted.

Perhaps consider that your experience is not universal and that others have good reasons for their decisions that are not simply ignorance.

I didn't say there aren't acceptable reasons to reach for the print statement, there are. But for the vast majority of codebases out there, if good debugger tooling is available, it's a crime not to use it as a primary diagnostics tool. Claiming otherwise is indeed ignorant if not irresponsible.

Debugging is for the developer; logging is for all, and especially those who need to support the code without the skills/setup/bandwidth to drop into a debugger. Once you start paying attention to what/where/how of logging, you (and others) can spot things faster then you can step through the debugger. Plus logs provide history and and searchable.

Re: The Grug Brained Developer (2022)

#477

Post by noisy_boy »

bluefirebrand wrote: post #261
mplanchard wrote: post #137

Earlier quoted context omitted.

For folks who seek a rule of thumb, I’ve found SPoT (single point of truth) a better maxim than DRY: there should be ideally one place where business logic is defined. Other stuff can be duplicated as needed and it isn’t inherently a bad thing. To modulate DRY, I try to emphasize the “rule of three”: up to three duplicates of some copy/paste code is fine, and after that we should think about abstracting. Of course no…

> To modulate DRY, I try to emphasize the “rule of three”: up to three duplicates of some copy/paste code is fine, and after that we should think about abstracting Just for fun, this more or less already exists as another acronym: WET. Write Everything Twice It basically just means exactly what you said. Don't bother DRYing your code until you find yourself writing it for the third time.

And to those who feel the OCD and fear of forgetting coming over by writing twice, put TODOs on both spots; so that when the third time comes, you can find the other two easily. If you are the backlogging type, put JIRA reference with the TODOs to make finding even easier.

Re: The Grug Brained Developer (2022)

#478

Post by danfunk »

demosthanos wrote: post #127
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…

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…

This feels a little like "I don't use a cordless drill because my screw driver works so well and is faster in most cases" grug brain says use best tool, not just tool grug used last.

Re: The Grug Brained Developer (2022)

#479

Post by mdavid626 »

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…

Nobody has time for that. Need time for prompting AI!

Re: The Grug Brained Developer (2022)

#480

Post by dgb23 »

strogonoff wrote: post #358
4hg4ufxhy wrote: post #221

Earlier quoted context omitted.

It depends on the domain. Any complex long lived mutable state, precise memory management or visual rendering probably benefits from debuggers. Most people who work on crud services do not see any benefit from it, as there is practically nothing going on. Observing input, outputs and databases is usually enough, and when it's not a well placed log will suffice. Debuggers will also not help you in distributed environm…

Is there a name for an approach to debugging that requires neither debuggers nor print calls? It works like this: 1. When you get a stack trace from a failure, without knowing anything else find the right level and make sure it has sensible error handling and reporting. 1a. If the bug is reproduced but the program experiences no failure & associated stack trace, change the logic such that if this bug occurs then ther…

In order for this to cover enough space, I assume you‘d have to really pin down assumptions with asserts and so on in a design by contract style.
Post reply on HN