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

251–260 of 603 posts

Re: The Grug Brained Developer (2022)

#251

Post by _heimdall »

johnfn wrote: post #208
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…

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

This hasn't been my experience.

When I'm unfamiliar with a codebase, or unfamiliar with a particular corner of the code, I find myself reaching for console debugging. Its a bit of a scattershot approach, I don't know what I'm looking for so I console log variables in the vicinity.

Once I know a codebase I want to debug line by line, walking through to see where the execution deviates from what I expected. I very frequently lean on conditional breakpoints - I know I can skip breaks until a certain condition is met, at which point I need to see exactly what goes wrong.

Re: The Grug Brained Developer (2022)

#254

Post by closeparen »

anthomtb wrote: post #13

So many gems in here but this one about microservices is my favorite: grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

The network boundary gives you a factoring tool that most language module systems don't: the ability for a collection of packages to cooperate internally but expose only a small API to the rest of the codebase. The fact that it's network further disciplines the modules to exchange only data (not callbacks or behaviors) which simplifies programming, and to evolve their interfaces in backwards compatible ways, which makes it possible to "hot reload" different modules at different times without blowing up.

You could probably get most of this without the literal network hop, but I haven't seen a serious attempt.

Re: The Grug Brained Developer (2022)

#255

Post by tcoff91 »

johnfn wrote: post #208
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…

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

Adding print statements sucks when you are working on native apps and you have to wait for the compiler and linker every time you add one. Debuggers hands down if you are working on something like C++ or Rust. You can add tracepoints in your debugger if you want to do print debugging in native code.

In scripting languages print debugging makes sense especially when debugging a distributed system.

Also logging works better than breaking when debugging multithreading issues imo.

I use both methods.

Re: The Grug Brained Developer (2022)

#256

Post by jakewins »

closeparen wrote: post #254
anthomtb wrote: post #13

So many gems in here but this one about microservices is my favorite: grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

The network boundary gives you a factoring tool that most language module systems don't: the ability for a collection of packages to cooperate internally but expose only a small API to the rest of the codebase. The fact that it's network further disciplines the modules to exchange only data (not callbacks or behaviors) which simplifies programming, and to evolve their interfaces in backwards compatible ways, which ma…

Any language that offers a mechanism for libraries has formal or informal support for defining modules with public APIs?

Or maybe I’m missing what you mean - can you explain with an example an API boundary you can’t define by interfaces in Go, Java, C# etc? Or by Protocols in Python?

Re: The Grug Brained Developer (2022)

#257

Post by dpkirchner »

fingerlocks wrote: post #242
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.

All these print debugging advocates are blowing my mind. Are most people unaware that both lldb and gdb have conditional pass throughout breakpoints with function hooks? In other words, you can create a breakpoint that just prints its location and doesn’t pause execution. You can script this so all function entry/exists, or whatever, are logged without touching the code or needing to recompile. You can then bulk togg…

I can't tell you how many times lldb has failed to hit breakpoints or has dumped me in some library without symbols. This was in Xcode while writing an iOS app, maybe it's better in other environments.

Print debugging, while not clever or powerful, has never once failed me.

Re: The Grug Brained Developer (2022)

#258

Post by closeparen »

jakewins wrote: post #256
closeparen wrote: post #254

Earlier quoted context omitted.

The network boundary gives you a factoring tool that most language module systems don't: the ability for a collection of packages to cooperate internally but expose only a small API to the rest of the codebase. The fact that it's network further disciplines the modules to exchange only data (not callbacks or behaviors) which simplifies programming, and to evolve their interfaces in backwards compatible ways, which ma…

Any language that offers a mechanism for libraries has formal or informal support for defining modules with public APIs? Or maybe I’m missing what you mean - can you explain with an example an API boundary you can’t define by interfaces in Go, Java, C# etc? Or by Protocols in Python?

The service I'm working on right now has about 25 packages. From the language's perspective, each package is a "module" with a "public" API. But from the microservices architecture's perspective, the whole thing is one module with only a few methods.

Re: The Grug Brained Developer (2022)

#259

Post by mrkeen »

dgb23 wrote: post #45
12_throw_away wrote: post #11

This has by far the best discussion of the visitor pattern I've yet to come across.

I don't work in typical OO codebases, so I wasn't aware of what the visitor pattern even is. But there's an _excellent_ book about building an interpreter (and vm) "crafting interpreters". It has a section where it uses the visitor pattern. https://craftinginterpreters.com/representing-code.html#the-... I remember reading through it and not understanding why it had to be this complicated and then just used a tagged u…

You're right. It's an example of changing best practices to fit whatever the language designers released.

Re: The Grug Brained Developer (2022)

#260

Post by bluefirebrand »

cowthulhu wrote: post #168
dgb23 wrote: post #63

One thing to appreciate is that this article comes from someone who can do the more sophisticated (complex) thing, but tries not to based on experience. There is of course a time and place for sophistication, pushing for higher levels of abstraction and so on. But this grug philosophy is saying that there isn't any inherent value in doing this sort of thing and I think that is very sound advice. Also I noticed AI ass…

I feel like this would fit the bell curve meme - Novice dev writes simple code Intermediate dev writes complex code Expert dev writes simple code

I gave this advice to an intermediate dev at my company a couple of years ago

Something along the lines of "Hey, you're a great developer, really smart, you really know your stuff. But you have to stop reaching for the most complicated answer to everything"

He took it to heart and got promoted at the start of this year. Was nice to see. :)

Post reply on HN