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

521–530 of 603 posts

Re: The Grug Brained Developer (2022)

#521

Post by jbs789 »

toastercat wrote: post #494
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?

I think you hit the nail on the head. This article is definitely biased against modern front-end development for example and recommends HTMX as less "complex", but from what I've seen, using HTMX just trades one form of complexity for another. This part: > back end better more boring because all bad ideas have tried at this point maybe (still retry some!) I entered a Spring Boot codebase recently, and it was anything…

Seems consistent to me. Does your example fit within his caveat “(still retry some!)”.

Re: The Grug Brained Developer (2022)

#522

Post by nothrabannosir »

npodbielski wrote: post #381
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

I think mostly this is to brake down the system between teams. This is easier to manage this way. Nothing to do with technical decision - more the way of development. What is the alternative? Mono-repo? IMHO it is even worse.

microservices and mono repo are not mutually exclusive. Monolith, is. Important distinction imo, Micro services in mono repo definitely works and ime is >>> multi repo.

Of course the best is mono repo and monolith :3

Re: The Grug Brained Developer (2022)

#523

Post by frollogaston »

Kwantuum wrote: post #517
frollogaston wrote: post #468

Earlier quoted context omitted.

It's not a realtime system kind of thing where the debugger would change the behavior too much... It's possible with enough engineering work, but nobody has put that work in, in fact they had a debugger for some staging envs that they deleted. Lately they keep adding more red tape making it hard to even run something locally, let alone attach a debugger. I guess you can attach a debugger for unit tests, but that's no…

> I guess you can attach a debugger for unit tests, but that's not very useful. That is in fact incredibly useful

Eh, it's there for those who want it, but nobody uses it

Re: The Grug Brained Developer (2022)

#524

Post by kunzhi »

fwip wrote: post #70
kunzhi wrote: post #34

Earlier quoted context omitted.

Sometimes if I'm reading something and having trouble with the words or sentences, I'll slow down and focus on the individual letters. Usually helps a tremendous amount.

Apologies if I came across as condescending.

Not at all! No offense was taken.

Re: The Grug Brained Developer (2022)

#525

Post by chickenzzzzu »

sapiogram wrote: post #473
chickenzzzzu wrote: post #441

Earlier quoted context omitted.

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.

Find me a bank that will give me a 150k collateralized loan and after 2 years I will give you the best AAA game you've ever played. You choose all the features. Vulkan/PC only. If you respond back with further features and constraints, I will explain in great detail how to implement them.

Re: The Grug Brained Developer (2022)

#526

Post by ttoinou »

prmph wrote: post #428
ttoinou wrote: post #418

Earlier quoted context omitted.

Your two first examples, you just hide the complexity by using another tool, no ? And I don’t see how number 3 is simpler. In my maths head I can easily create bijective spaces. Emulating backward migration through others means might be harder (depending on details of course thats not a general rule)

I'm not sure where the complexity is hiding in my examples. For the code generation, note that some types are almost impossible to express properly, but code can be generated using simpler types that capture all the same constraints that you wanted. And, of course I only use this approach for cases where it is not that complicated to generate the code, and so I can be sure that each time I need to (re)generate it, it…

Ah yeah in that case it all makes sense

Re: The Grug Brained Developer (2022)

#527

Post by mdaniel »

chickenzzzzu wrote: post #525
sapiogram wrote: post #473

Earlier quoted context omitted.

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.

Find me a bank that will give me a 150k collateralized loan and after 2 years I will give you the best AAA game you've ever played. You choose all the features. Vulkan/PC only. If you respond back with further features and constraints, I will explain in great detail how to implement them.

I suspect you're trolling, but if not then this is the kind of thing that kickstarter or indiegogo are designed to solve: give me money on my word, in 2 years you get license keys to this thing, assuming it materializes. I was going to also offer peer-to-peer platforms like Prosper but I think they top out at $50k

Re: The Grug Brained Developer (2022)

#528

Post by monkeyelite »

frollogaston wrote: post #523
Kwantuum wrote: post #517

Earlier quoted context omitted.

> I guess you can attach a debugger for unit tests, but that's not very useful. That is in fact incredibly useful

Eh, it's there for those who want it, but nobody uses it

See this just sounds like you do not have an engineering culture or learning, enabling, and using debuggers.

Re: The Grug Brained Developer (2022)

#529

Post by gorjusborg »

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…

> substantially faster

Than what? In languages with good debugger support (see JVM/Java) it can be far quicker to click a single line to set a breakpoint, hit Debug, the inspect the values or evaluate expressions to get the runtime context you cant get from purely reading code. Print statements require rebuilding code and backing them out, so its hard to imagine that technique being faster.

I do use print debugging for languages with poor IDE/debugger support, but it is one big thing I miss when outside of Java.

Re: The Grug Brained Developer (2022)

#530

Post by mdaniel »

9rx wrote: post #470
1-more wrote: post #466

Earlier quoted context omitted.

I'm just talking null-less FP languages such as Haskell and Elm, not a full proof system such Lean and Agda or a formal specification language such as TLA+. I'm not sure I agree with your prior that "your tests are also going to 'deal with "what if this input is null?" everywhere' cases and whatnot." Invalid input is at the very edge of the program where it goes through a parser. If I parse a string value into a type…

Assume that there was room for null. What is your concrete example of where null becomes a problem in production, but goes unnoticed by your tests?

Relevant: Google Cloud Incident Report – 2025-06-13 - https://news.ycombinator.com/item?id=44274563 - June, 2025 (220 comments)
Post reply on HN