The Grug Brained Developer

> oh well, grug end up at good company anyway and rob pike dress habit increasingly erratic, so all work out in end, but point stand: logging very important!

beautiful...well done....

This might be the best text on programming I've read since Why's Poignant Guide

Microservices

grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

That made me laugh. The microservices madness of the past decade is now starting to settle down to more mature understandings, but there are still a lot people biting off large testing, operational, and data transactionality/ reporting costs.

People often don't recognise beforehand the magnitude of extra complexity & associated productivity costs.

I've seen companies architecting 50 microservices with 50 separate datastores when they actually needed 5 midi services.. Then lose half their productivity trying to work with all this.

Never before have I read such wisdom. Young grug impressed.

> Microservices

grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

seem very confusing to grug

>

Yes.

As a grug-brained developer, I love the spirit of this, but it's kinda hard to read. Maybe the author can publish an English translation? :)

> also danger abstraction too high, and big brain code become astral projection of platonic generic turing model of computation into code base. grug confused and agree some level very elegant but also very hard do anything like record number of club inventory for Grug Inc. task at hand

My favourite part.

> grug no able see complexity demon, but grug sense its presence in code base

This is the key problem with complexity.

Complexity is fine if you understand it! It's when you're aware that something is complex, but you start to get these mental force-fields pushing you aware from the scary parts, that it becomes a problem.

> demon complexity spirit mocking him make change here break unrelated thing there what!?!

That's the happy case! The sad case is when you make a change and don't observe any obvious breakage, but then 3 years later you realise something you somewhat care about has been silently broken for a very long time.

> grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug

This resonates with me

Australians of a certain age might have a different (yet not that different) take on the Grug brain: https://www.simonandschuster.ca/books/Grug/Ted-Prior/9780731...

2 more point grug want make.

1. big brain write code when no idea big picture. later problem make grug have to rewrite many code, make grug want break keyboard on desk! (no idea where club, maybe left bathroom stall)

grug now make diagram first, tell purpose code. maybe take long time and grug no happy. but diagram tell many story from tiny picture. all see picture, all grok. junior grug see problem, ask question, all work together solve problem. many pat on back for junior grug, maybe give bonus shiny rock. then grug make code. less waste time throw away code not make sense, more grugs make code from picture same time. think of artist make mural with grid. grug happy when think code like art.

2. grug also told to refactor sometime, not happy. executive vp say refactor whole app, grug raise club very high. grug boss say "Ok, we'll do Embrace, Extend, Extinguish", grug lower club a little.

grug put up app facade, make feature flag and new feature, push feature to prod, test new feature with little real traffic using flag. test more and more traffic. when new feature use 100% traffic in prod, then remove old code and flag. do again until all old code replace. refactor slow but not make grug work overtime from bad deadline crunch, waste less money when refactor no work, less smash boss when no stand up to executive vp.

Grug and I have essentially identical software development philosophies. I appreciate you Grug. This, especially, was where I felt kindred spirits colliding.

> type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic

This reads a lot like like commit comments, status reports, e-mails and tickets in a company in which everyone is from a different country from around the globe.

If you can't read grug English, you will find it hard to navigate in the global workforce.

Developers talk about reducing/avoiding complexity all the time. And yet the very same developers keep making things more complex. I am starting to realize that most developers don't understand what complexity is. So they say crazy things like "microservices are less complex than monoliths". And they actually believe it! When I then step by step show them that microservices are actually objectively more complex than a well designed monolith they agree with every step of my explanation but somehow still don't get it. Very strange.

> grug understand all programmer platonists at some level wish music of spheres perfection in code. but danger is here, world is ugly and gronky many times and code so also must. humility not often come big brained or think big brained easily or grug even, but grug often find "oh, grug no like look of this, grug fix" lead many hours pain grug and no better or system worse even. grug early on often charge into code base waving club wildly and smash up everything, learn not good

> grug not say no improve system ever, quite foolish, but recommend take time understand system first especially bigger system is and respected code working today even if not perfect

grug read this and grok spirit, grug enlightened. master not club grug so much.

big brain really like post. lesson learn is deep!

"(best grug brain able to herd multiple big brain in right direction and produce many complexity demon trap crystals, large shiney rock pile!)"

The advice is fantastic! Fear the club.

> grug tempted to reach for club and yell "big brain no maintain code! big brain move on next architecture committee leave code for grug deal with!"

> grug tempted reach for club when too much agile talk happen but always stay calm

Now we add GRUG to KISS and YAGNI.

> test shaman have good point on importance of test, even if test shaman often sometimes not complete useful feature in life and talk only about test all time, deserve of club but heart in right place

> also, test shaman often talk unit test very much, but grug not find so useful. grug experience that ideal tests are not unit test or either end-to-end test, but in-between test

amazing

this grug read article, but author grug big brain, article too long. If article was smaller with less complexity, easier for regular grug to read and remember.

</grug>

this is nothing short of amazing

I think this nicely captures everything I've learned about programming over the past n years that I wish other people would realize too.

I can't tell who this article is making fun of.

think hard ==> always need think hard

think hard about think soft ==> no need think hard all time

This makes me so happy

"deserve of club but heart in right place"

I love it.

The problem here as I currently see it.

What could be complex to some could be simple to others.

How could grug developer possibly make sense of such a contradictory statement?

My name is Groot!

Horseshoe theory right once again: Grug and 100x’er megaminds are aligned, and the midwits are over complicating and underperforming.

Love this. Always keep it simple, because future me is dumb. I will say though that frontend dev gets a bad rap, and the tooling is complex because the problem is. UI's are incredibly stateful by nature, and you're not going to get anywhere unless you use a mature framework that lets you reason about it effectively. No, I'm not talking about using React to make a static site, but anything with a modicum of complexity gets out of hand pretty quick.

Basically "Simple Made Easy"

This is wonderful. I feel myself thoroughly agreeing (but also somehow intensely disagreeing at the same time) with things that are written, especially when it comes to type systems. At some sort of deep level, I seem to like the idea that stuff is proven to work, regardless of how complex the type system overhead is. Maybe it's just two sides of the same coin. Some sort of primitive hatred of complexity and a primitive desire for safety and control will forever be at war inside me.

>grug brain developer not very smart, but grug brain developer program many long year and learn some things although mostly still confused

grug admit confusion is puzzle. grug blame complexity for confusion. grug make better relation to grug's target. grug reduce complexity and confusion. grug win woman and shiny rock.

> sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overworked and dealing with many grugs.

In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going.

I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing to help with the cost-benefit analysis for each suggested feature.

Problem is, for that, you need a developer who cares about and deeply understands the use case/the product. Many of the devs I've had to work with were more interested in building pristine codebases with clever abstractions and ability to scale to unnecessary numbers of users or bytes.

Nice article but a bit tedious to read improper English. It is fun for paragraph or two but wears out rather quickly. If you got something important to say why not just say it as clearly as possible?

> good debugger worth weight in shiney rocks, in fact also more: when faced with bug grug would often trade all shiney rock and perhaps few children for good debugger and anyway debugger no weigh anything far as grug can tell

grug know debugger good but grug often realize grug no need debugger on smaller cases and only run it when grug need it, grug try simple code like print and log first, if grug sad and no understand grug go for debugger

Good stuff, reminds me of PLT Hulk [0], although obviously Grug isn't a fan of powerful type systems.

[0] https://twitter.com/plt_hulk

Can we get this idea as popular as Joel's rockstar developer? See it in job ads? I think I would prefer to work with guys like this.

>> over time grug learn this hard debug, learn prefer write like so:...

I thought grug would say, "grug used to use debugger but now grug stare at code until grug understand code - debugger bad brain drug for grug".

This is like if Code Monkey[1] wrote a whole manifesto.

[1] https://www.youtube.com/watch?v=v4Wy7gRGgeA

smol brain can dodge [1]

[1] https://preview.redd.it/g1lpdmt1iiv51.jpg?auto=webp&s=a5f27c...

sometime grugbrain sometime complexitybrain

That's a great write up.

Start calling bad abstraction "indirection". If I'm debugging something, I don't want to be chasing a rabbit through figuring out what calls what, and what constant is stored where, what pattern created what instance, etc...

Even big brain developer is grug brain when read code later.

Too difficult to read, can't be bothered.

Does this style really appeal to anyone at all?

Wise fellow, that grug.

cf. 'Grunk' in the very funny Lost Pig: https://pr-if.org/play/lostpig/

I skipped most of this post, but the combo of name and writing style seems like a homage.

Grug no talk of estimation spirit demon.

that grug say many variables good. make this grug many happy.

For your enjoyment, here is a part of the article being read in a Yoda voice by a pretty good speech synthesizer:

https://jonaquino.blogspot.com/2022/06/grug-brained-develope...

Grug no read good but grug fink is good advice here

> grug brain developer try collect learns into small, easily digestible and funny page, not only for you, the young grug, but also for him because as grug brain developer get older he forget important things, like what had for breakfast or if put pants on

grug relate. other day grug forget Angular have pipes even though grug use async pipe in same PR.

This is particularly concerning for me because not being too strong in the klaka klaka klaka 600LoC daily department I always relied heavily on my knowledge. Is it a coincidence that this started happening after exactly ten years of commercial experience?

This bats 0.950+

Who is this person? They must be a very senior Jedi

How long until you see the first 'grug-brain' t-shirt at your workplace?

I sense a certain age-range here.

You've heard of Film Crit Hulk? Here's Software Dev Hulk.

I have been thinking about the complexity bias that affects our perception of quality. I think as programmers it is our natural assumption that if something is complex, lots of thought must have gone into it beyond our understanding. This is especially true when starting a new job. But this is slightly ironic because often more code makes something slow, which isn't a good thing at all.

What a fun article!

When reading it, I felt like it was loosely inspired by A Philosophy of Software Design by Ousterhout. And it was! Near the end it is listed as recommended reading. Cannot recommend it enough.

> grug has never used erlang, hear good things, but language look wierd to grug sorry

maybe grug try drink elixir?

complexity isn't bad, redundant complexity is

As funny as this post is to read, I don't want to see yet another developer say "complexity bad". I want to see a company deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down.

_THEN_ I want developers from that company to share their opinions about how they do it. Do such companies/products even exist? Software is so bad these days that maybe no existing software lives up to our ideals.

This is a long winded way of saying we don't know how to write software, so we opt for 'ha ha, funny' instead.

Well meaning..

However, what I _REALLY_ want is a sw-dev (let's just say it like it is _PROGRAMMER_) version of the BOFH stories.

Ah, the ample club of wishful thinking.

There are two general ways of approaching software design (and I'm paraphrasing Tony Hoare here):

1. You can write software so simple there are obviously no errors

2. You can write software so complex there are no obvious errors

One thing that escapes "grug" is that achieving 1. often requires more sophistication than their magical club allows. Most well-intentioned "grug" developers will write software so simple that it becomes it's own form of complexity: a giant mud-ball of for-loops, while-loops, variable assignments, and other wonderful side effects. Instead of addressing complexity head-on with abstraction, "grug" will beat "galaxy brain" over the head.

What grug fails to understand is that simplicity isn't easy or familiar. It doesn't mean "sticking to what you know." If often requires being able to reason about programs and to verify that reasoning!

But go ahead grug... keep beating people over the head with the club and hope that the complexity will go away.

The writing style has the same cadence as the speech of “Uncle Roger” of egg-fried rice fame: https://youtube.com/c/mrnigelng

Kevin, is that you?

chef kiss

Grug feel related, make grub happy. And not know why but grug notice that grug style make easier leave club resting. Grug think practice talk grug to inside grug, make club battle few.

Also, grug not know if big brained or grug. Grug think grug but not see big brained. Big brained think big brained stop big brain and become grug. When stop think grug big brain, big brain grug return. Hard, and bore. Life such.

Now sleep, soon shiny rocks collect.

Now this is a good post. Especially the part about the frontend Complexity Demon having a grip on the entire industry, and the Fear Of Looking Dumb. It goes hand in hand.

Holy shit this is the best learning I have read on hackernews, funny and so very true.

> given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex

this is art and all of us should be ashamed.

> unfortunately also many test shamans exist. some test shaman make test idol, demand things like "first test" before grug even write code or have any idea what grug doing domain!

I am keeping that.

> sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice

This is a big part of the general career skills I teach interns when I'm mentoring. Learn how to not lose the game of musical chairs. When a project is clearly going to immanently collapse under its own weight, change teams before it happens.

This is true and excellent, and I'd put it next to Hickey's "Simple made easy" and Metz' "The Wrong Abstraction" as something I wish every developer would grok.

Heh, me not grug brained right?