> Complexity very very bad.
> best weapon against complexity spirit demon is magic word: "no"
> sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice
Complex wisdom from grug.
The Grug Brained Developer (2022)
11–20 of 201 posts
Re: The Grug Brained Developer (2022)
#12Grug came up a week ago in a Philosophy of Software Design submission's comments. I thought the commentary was pretty good. https://news.ycombinator.com/item?id=38011938 > I feel the exact same about grug. I don't think people actually agree on what's simple, so it's pretentious to pretend your "simple" is the obvious one that a caveman would agree with. Simple/simplicity is often one of the most complex things to di…
That’s a very good point. I feel, however, that the main idea is that bad philosophy is what ultimately fuels complexity.
The grug brain philosophy is simplicity at all costs, unless absolutely unavoidable.
The big brain philosophy as grug sees it is reusability at all costs, unless absolutely unavoidable.
The issue with this philosophy is that it tends to lock in first generation design choices and makes iteration more difficult.
It’s true that simplicity is difficult to find, but iteration is the key to finding simplicity.
Re: The Grug Brained Developer (2022)
#13very hard to read, but worth it
Easy read. This grug turn off brain. Only grok from page for this grug.
Re: The Grug Brained Developer (2022)
#14Grug came up a week ago in a Philosophy of Software Design submission's comments. I thought the commentary was pretty good. https://news.ycombinator.com/item?id=38011938 > I feel the exact same about grug. I don't think people actually agree on what's simple, so it's pretentious to pretend your "simple" is the obvious one that a caveman would agree with. Simple/simplicity is often one of the most complex things to di…
measure LOC in my opinion. the local minima will move around based on the complexity of what you’re building - so there’s room for many reasonably intelligent opinions to be right. imperfect measure but directionally correct, works great on log scale
Re: The Grug Brained Developer (2022)
#15It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…
>They are not thinking about every single line of code that they write
Honestly for me over-engineering is usually the result of the opposite. Thinking too much when writing and having preconceived ideas about what a codebase ought to look like.
It was Casey from Handmade Hero IIRC who called his style of programming "compression based", effectively just writing code and factoring out what belongs together incrementally. Abstracting things out as they repeat, not consciously by design. I've taken this up more and more as a way to program.
Re: The Grug Brained Developer (2022)
#16Grug came up a week ago in a Philosophy of Software Design submission's comments. I thought the commentary was pretty good. https://news.ycombinator.com/item?id=38011938 > I feel the exact same about grug. I don't think people actually agree on what's simple, so it's pretentious to pretend your "simple" is the obvious one that a caveman would agree with. Simple/simplicity is often one of the most complex things to di…
What I like so much about the Grug piece is that it’s full of nuance and humility. It’s not pretentious.
Grug express simple and clear.
Grug no make small problem big.
Grug humble.
Re: The Grug Brained Developer (2022)
#17very hard to read, but worth it
Reminds me of classic FILM CRIT HULK columns. The content’s good but the style can take some getting used to.
Re: The Grug Brained Developer (2022)
#18It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…
> The developer's incentive to maximize their own lock-in factor and billable hours are powerful forces.
In my experience these are rarely, if ever, the reasons for over engineering.
Re: The Grug Brained Developer (2022)
#19It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…
>They are not thinking about every single line of code that they write Honestly for me over-engineering is usually the result of the opposite. Thinking too much when writing and having preconceived ideas about what a codebase ought to look like. It was Casey from Handmade Hero IIRC who called his style of programming "compression based", effectively just writing code and factoring out what belongs together incrementa…
Agreed. Over engineering happens when you overthink every line of code, not when you fail to think about every line.
Re: The Grug Brained Developer (2022)
#20Earlier quoted context omitted.
I struggle with this constantly. I think there are two problems: 1. I like interesting puzzles. A lot of code - especially commercial code - is pretty boring if you do it right. I find myself subconsciously pushing for features that will be fun to implement. And by "fun", I mean, features that will overcomplicate everything. 2. While I'm in the middle of programming something, all the choices that I make seem straigh…
This is it. There's real skill in creating simple solutions to complex problems. Knowing the general landscape of what's out there, and easily available off the shelf, really does help. Developers grow. It starts with simple code that doesn't work. The next step is, complicated code that solves the problem, in messy unmaintainable ways. The next step is writing super clean, almost boring code, that's highly readable…
> There's real skill in creating simple solutions to complex problems.
Not entirely facetiously, I think that, for engineers, there's real skill in creating simple solutions to simple problems—not, for example, finding the general instance of the problem and solving that, when the problem is unlikely to recur and crafting the perfect general solution delays delivery on what's actually in front of you.
(I know Perl's not fashionable any more, but I've always liked its design philosophy of "make easy things easy, and hard things possible." It seems like a slogan that can be adaptable to how to solve problems, though I'm not sure of the absolutely perfect analogue. Hmm, maybe I'm trying to solve the general instance of a problem ….)