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

441–450 of 603 posts

Re: The Grug Brained Developer (2022)

#441

Post by chickenzzzzu »

johnfn wrote: post #431
osigurdson wrote: post #385

Earlier quoted context omitted.

It seems unlikely that John Carmack doesn't understand his problem domain. Rather it is more likely the problem domain itself, i.e., game dev vs web dev. Game dev is highly stateful and runs in a single process. This class of program can logically be extended to any complex single computer program (or perhaps even a tightly coupled multi-computer program using MPI / related). Web dev effectively runs on a cluster of…

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.

Re: The Grug Brained Developer (2022)

#442

Post by GMoromisato »

Symmetry wrote: post #366
GMoromisato wrote: post #98

One of the many ironies of modern software development is that we sometimes introduce complexity because we think it will "save time in the end". Sometimes we're right and it does save time--but not always and maybe not often. Three examples: DRY (Don't Repeat Yourself) sometimes leads to premature abstraction. We think, "hey, I bet this pattern will get used elsewhere, so we need to abstract out the common parts of…

On my laptop I have a yin-yang sticker with the yin labeled DRY and the yang labeled YAGNI.

I love it!

Re: The Grug Brained Developer (2022)

#443

Post by 9rx »

tayo42 wrote: post #164
PaulHoule wrote: post #135

Earlier quoted context omitted.

See https://en.wikipedia.org/wiki/Tagged_union In languages influenced by ML (like contemporary Java!) it is common in compiler work in that you might have an AST or similar kind of structure and you end up writing a lot of functions that use pattern matching like switch(node) { type1(a,b) -> whatever(a,b) type2(c) -> process(c) } to implement various "functions" such as rewriting the AST into bytecode, building a sy…

OK yeah I see, that's natural to do with like rust enums Java doesn't support this though I thought?

> that's natural to do with like rust enums

Stands to reason. Rust "enums" are tagged unions (a.k.a. sum types, discriminated unions).

In implementation, the tag, unless otherwise specified, is produced by an enum, which I guess is why it got that somewhat confusing keyword.

Re: The Grug Brained Developer (2022)

#444

Post by TOGoS »

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…

Some people are wizards with the debugger. Some people prefer printfs.

I used to debug occasionally but haven't touched a debugger in years. I'm not sure exactly why this is, but I'm generally not concerned with exactly what's in the stack on a particular run, but more with some specific state and where something changes time after time, and it's easier to collect that data programatically in the program than to figure out how to do it in the debugger that's integrated with whatever IDE I'm using that day.

And the codebase I deal with at work is Spring Boot. 90% of the stack is meaningless to me anyway. The debugger has been handy for finding out "what the f*$% is the caller doing to the transaction context" but that kind of thing is frustrating no matter what.

Anyway, I think they're both valid ways to explore the runtime characteristics of your program. Depends on what you're comfortable with, how you think of the problem, and the type of codebase you're working on. I could see living in the debugger being more useful to me if I'm in some C++ codebase where every line potentially has implicit destructor calls or something.

Re: The Grug Brained Developer (2022)

#446

Post by anonymars »

mrkeen wrote: post #281
anonymars wrote: post #185

Earlier quoted context omitted.

In what way would you say they are related? I've read both but don't see it

Introducing a needless us/them dynamic. Don't do it the way those elites do it, do it like us real grugs. That's why it's so easy to rush in and agree with everything. In another article, you might have to read 3 points for microservices, and 4 against. But here? Nope. Factoring? Just something you do with your gut. Know it when ya see it. Grug isn't going to offer up the why or how, because that's something a reader…

I don't see it as an us/them, he even says:

> note: grug once think big brained but learn hard way

It's basically a lot of K.I.S.S. advice. Of course you should use the best tool for the job, but complexity often sneaks up on you.

> Factoring? Just something you do with your gut. Know it when ya see it. Grug isn't going to offer up the why or how, because that's something a reader could disagree with.

I would dispute this characterization. Grug says it's difficult, and it is, but gives specific advice, to the extent one can:

- grug try not to factor in early part of project and then, at some point, good cut-points emerge from code base

- good cut point has narrow interface with rest of system: small number of functions or abstractions

- grug try watch patiently as cut points emerge from code and slowly refactor

- working demo especially good trick: force big brain make something to actually work to talk about and code to look at that do thing, will help big brain see reality on ground more quickly

Re: The Grug Brained Developer (2022)

#447

Post by zero_shift »

recursivedoubts wrote: post #400
osigurdson wrote: post #396

While I agree that complexity is bad the fact that we don't really have a shared understanding of what complexity is doesn't help. At worst, it can be just another synonym for "bad" that passes through the mental firewall without detection. For instance is having multiple files in a project "complex"? If I am unfamiliar with a codebase is it "complex" and I therefore have to re-write it?

Part of the problem with complexity is that it is very easy for engineers to justify. Yes, there is an important distinction between necessary and accidental complexity, but, to take a point from the essay, even necessary complexity can be reduced by saying "no" to features. This is why I treat "complexity bad" as a mantra to keep me in the right mindset when programming. Complexity bad. Even necessary complexity. We…

What exactly is complexity?

How do I recognise it?

When do I tell whether something is complex or I am just not very familiar with it?

Re: The Grug Brained Developer (2022)

#448

Post by 1-more »

This 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'm forgetting to handle with a red squiggly.

Re: The Grug Brained Developer (2022)

#449

Post by recursivedoubts »

zero_shift wrote: post #447
recursivedoubts wrote: post #400

Earlier quoted context omitted.

Part of the problem with complexity is that it is very easy for engineers to justify. Yes, there is an important distinction between necessary and accidental complexity, but, to take a point from the essay, even necessary complexity can be reduced by saying "no" to features. This is why I treat "complexity bad" as a mantra to keep me in the right mindset when programming. Complexity bad. Even necessary complexity. We…

What exactly is complexity? How do I recognise it? When do I tell whether something is complex or I am just not very familiar with it?

really hard questions

but complexity bad

Re: The Grug Brained Developer (2022)

#450

Post by recursivedoubts »

0xbadcafebee wrote: post #415

Me no like grug perpetuate complexity myth. Little grugs no understand complexity is not monolith. Me want fix that. Complexity not bad. Complexity just mean "thing have many consideration". Some thing always have many consideration. Not bad if useful and necessary. Complexity still difficult and raise problem. So try avoid complexity when unnecessary and no add value. But shun complexity bad when it detract value or…

that's a good point, but complexity bad
Post reply on HN