I can't believe this is (2022). I would have confidently told you I read this 10 years ago and guessed that it was already a classic then.
Same. I think it is inspired by an earlier work.
The Grug Brained Developer (2022)
451–460 of 603 posts
Re: The Grug Brained Developer (2022)
#452“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…
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.
Re: The Grug Brained Developer (2022)
#453This just became my favorite article of all time.
Re: The Grug Brained Developer (2022)
#454“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 want to master JS/React and Python debugging. Am an "advanced beginner" in both. What tools do you recommend?
Re: The Grug Brained Developer (2022)
#455“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'm looking around and I don't see anyone mentioning what I think is one of the biggest advantages of debugging: not having to recompile.
Even assuming print statements and debuggers are equally effective (they're not), debuggers are better simply because they are faster. With print statements, you might need to recompile a dozen times before you find whatever it is you're looking for. Even with quick builds this is infuriating and a ton of wasted time.
Re: The Grug Brained Developer (2022)
#456This concept is really interesting when you think about statically typed, pure functional languages. I like working in them because I'm too pretty and stupid to think about side effects in every function. My hair is too shiny and my muscles are too large to have to deal with "what if this input is null?" everywhere. Can't do it. Need to wrap that bad boy up in a Maybe or some such and have the computer tell me what I…
Formal proof languages are pretty neat, but boy are they tedious to use in practice. It is unsurprising that effectively no code is written in them. How do you overcome that?
Where the type system isn't that expressive, you still have to fall back to testing to fill in the places where the type system isn't sufficient, and your tests are also going to 'deal with "what if this input is null?" everywhere' cases and whatnot by virtue of execution constraints anyway.
Re: The Grug Brained Developer (2022)
#457Earlier quoted context omitted.
How long are you realistically "waiting for the compiler and linker"? 3 seconds? You're not recompiling the whole project after all, just one source file typically If I wanna use a debugger though, now that means a full recompile to build the project without optimizations, which probably takes many minutes. And then I'll have to hope that I can reproduce the issue without optimizations.
> How long are you realistically "waiting for the compiler and linker"? 3 seconds? I've worked on projects where incremental linking after touching the wrong .cpp file will take several minutes... and this is after I've optimized link times from e.g. switching from BFD to Gold, whereas before it might take 30 minutes. A full build (from e.g. touching the wrong header ) is measured in hours. And that's for a single co…
I understand you are likely doing this for shiny rocks, but life is too short to spend on abominable code bases like this.
Re: The Grug Brained Developer (2022)
#458One of my favorite LLM uses is to feed it this essay, then ask it to assume the persona of the grug-brained developer and comment on $ISSUE_IM_CURRENTLY_DEALING_WITH. Good stress relief.
I am not very proficient with LLMs yet, but this sounds awesome! How do you do that, to "feed it this essay"? Do you just start the prompt with something like "Act like the Grug Brained Developer from this essay "?
Could put it in a ChatGPT project description or Cursor rules to avoid copy pasting every time.
Re: The Grug Brained Developer (2022)
#459Earlier quoted context omitted.
How long are you realistically "waiting for the compiler and linker"? 3 seconds? You're not recompiling the whole project after all, just one source file typically If I wanna use a debugger though, now that means a full recompile to build the project without optimizations, which probably takes many minutes. And then I'll have to hope that I can reproduce the issue without optimizations.
I work on Scala projects. Adding a log means stopping the service, recompiling and restarting. For projects using Play (the biggest one is one of them) that means waiting for the hot-reload to complete. In both cases it easily takes at least 30s on the smallest projects, with a fast machine. With my previous machine Play's hot reload on our biggest app could take 1 to 3mn. I use the debugger in Intellij, using breakp…
This reminds me why I abandoned scala. That being said, even a small sbt project can cold boot in under 10 seconds on a six year old laptop. I shudder to think of the bloat in play if 30 seconds is the norm for a hot reload.
Re: The Grug Brained Developer (2022)
#460Earlier 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…
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.