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

211–220 of 603 posts

Re: The Grug Brained Developer (2022)

#211

Post by strken »

AdieuToLogic wrote: post #200
geophile wrote: post #147

Earlier quoted context omitted.

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…

> 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. This is an anti-pattern which results in voluminous log "noise" when the system operates as expected. To the degree that I have personally seen gigabytes per day produced by emp…

It's absolutely not an anti-pattern if you have appropriate tools to handle different levels of logging, and especially not if you can filter debug output by area. You touch on this, but it's a bit strange to me that the default case is assumed to be "all logs all the time".

I usually roll my own wrapper around an existing logging package, but https://www.npmjs.com/package/debug is a good example of what life can be like if you're using JS. Want to debug your rate limiter? Write `DEBUG=app:middleware:rate-limiter npm start` and off you go.

Re: The Grug Brained Developer (2022)

#212

Post by soundpuppy »

I think even the simplest of programming tools is still unfathomably powerful, enough to where you could eliminate data structures and still be where we are today. BitTorrent had a great amount of complexity, and look what streaming did to it.

Re: The Grug Brained Developer (2022)

#213

Post by neogodless »

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…

> time to decide where to put print statements

But... that's where you put breakpoints and then you don't need to "single-step" through code. Takes less time to put a breakpoint then to add (and later remove) temporary print statements.

(Now if you're putting in permanent logging that makes sense, do that anyway. But that probably won't coincide with debugging print statements...)

Re: The Grug Brained Developer (2022)

#214

Post by magarnicle »

anonymars wrote: post #184
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?

I am the rest of my team. So yeah, not applicable to most people.

Re: The Grug Brained Developer (2022)

#215

Post by nyarlathotep_ »

api wrote: post #180
nyarlathotep_ wrote: post #151

Earlier quoted context omitted.

It's 100% this; you're right on the money (pun intended). Don't forget various pipelines, IaC, pipelines for deploying IaC, test/dev/staging/whatever environments, organization permissions strategies etc etc... When I worked at a large, uh, cloud company as a consultant, solutions were often tailored towards "best practices"--this meant, in reality, large complex serverless/containerized things with all sorts of inte…

There is now an entire generation of developers steeped in SaaS who literally don’t know how to do anything else, and have this insanely distorted picture of how much power is needed to do simple things. It’s hard to hire people to do anything else. People don’t know how to admin machines so forget bare metal even though it can be thousands of times cheaper for some work loads (especially bandwidth). You’re not exagg…

Thanks for making me feel less alone in this perspective--it's always been kind of verboten to say such a thing in those kinds of workplaces, but all my software type friends agree completely.

The "entire generation of developers" paradigm is all over in different domains too--web programmers that seem to honestly think web development is only React/Angular and seem to have no idea that you can just write JS, python programmers that have no idea a large portion of the "performant codebases" are piles of native dependencies etc

Re: The Grug Brained Developer (2022)

#216

Post by demosthanos »

neogodless wrote: post #213
demosthanos wrote: post #127

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…

> time to decide where to put print statements But... that's where you put breakpoints and then you don't need to "single-step" through code. Takes less time to put a breakpoint then to add (and later remove) temporary print statements. (Now if you're putting in permanent logging that makes sense, do that anyway. But that probably won't coincide with debugging print statements...)

True, but then you're still left stepping through your breakpoints one by one.

Printf debugging gives you the full picture of an entire execution at a glance, allowing you to see time as it happened. The debugger restricts you to step through time and hold the evolution of state in your memory in exchange for giving you free access to explore the state at each point.

Occasionally that arbitrary access is useful, but more often than not it's the evolution of state that you're interested in, and printf gives you that for free.

Re: The Grug Brained Developer (2022)

#218

Post by GrumpyYoungMan »

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…

Debuggers are great until you have to work in a context where you can't attach a debugger. Good old printf works in every context.

By all means, learn to use a debugger well but don't become overly dependent on them.

Re: The Grug Brained Developer (2022)

#219

Post by whateveracct »

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 use a repl instead of a debugger. White box vs black box.

Re: The Grug Brained Developer (2022)

#220

Post by travisgriggs »

XorNot wrote: post #182
sethjgore wrote: post #173

Earlier quoted context omitted.

What do you mean “visual debugger?”

Presumably an IDE rather then dealing the gdb CLI.

I think it depends on the debugger and the language semantics as well. Debugging in Swift/Kotlin, so so. The Smalltalk debugger was one of the best learning tools I ever used. “Our killer app is our debugger” doesn’t win your language mad props though.
Post reply on HN