The Grug Brained Developer

Yes, and the LLM that wrote this is not performing the site's thesis about respecting human cognitive capacity. Dense, repetitive, nonlocal, narratively murky. Which is a shame because the overall message and the twenty-five tenets are good stuff! The prose just doesn't invite human consumption. For now, Grug [0] said it best. [0] https://grugbrain.dev/

The best descripcion of microservices comes from "The Grug Brained Developer" (https://grugbrain.dev/): "grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug"

That was still one of the best finds on HN in a long time. https://grugbrain.dev/ Carson Gross sure knows how to stay in character.

https://grugbrain.dev/ grug very elated find big brain developer Bob Nystrom redeem the big brain tribe and write excellent book on recursive descent: Crafting Interpreters book available online free, but grug highly recommend all interested grugs purchase book on general principle, provide much big brain advice and grug love book very much except visitor pattern (trap!) Grug says bad. In all seriousness, the rough argument is that it's a "big brain" way of thinking. It sounds great on paper, but is often times not the easiest machinery to have to manage when there are simpler options (e.g. just add a method).

I think grug has the best refactoring advice: https://grugbrain.dev/

Type systems, like any other tool in the toolbox, have an 80/20 rule associated with them. It is quite easy to overdo types and make working with a library extremely burdensome for little to no to negative benefit. I know what a UUID (or a String) is. I don't know what an AccountID, UserID, etc. is. Now I need to know what those are (and how to make them, etc. as well) to use your software. Maybe an elaborate type system worth it, but maybe not (especially if there are good tests.) https://grugbrain.dev/#grug-on-type-systems

Best advice I ever got on logging: log all major logical branches within code (if/for) if "request" span multiple machine in cloud infrastructure, include request ID in all so logs can be grouped if possible make log level dynamically controlled, so grug can turn on/off when need debug issue (many!) if possible make log level per user, so can debug specific user issue - https://grugbrain.dev/ The only one I'll add is: If your logs are usually read in a log aggregator like Splunk or Grafana instead of in a console or text file, log as JSON objects instead of lines of text. It makes searches easier.

It started with https://grugbrain.dev/ but I think its useful because it dispenses with any possibility of pretension and signals 'this is simple advice about the fundamentals'. The limited vocab means no jargon bullshit. I find some of it really insightful. It speaks to the truth that beneath all the layers we are just hominids who have accidentally given ourselves great powers, and day to day a lot of what we do can be explained in simple terms and there is value in admitting that.

this is a good filter. if someone starts careening through the task using brainfuck, they ain’t thinking like a senior dev at day job i.e. simple, clear, easy to follow and maintainable code writing. i don’t care how clever you are. i need to know you’re not going to rewrite the frontend in your first week because of a “big brain” moment [0]. using python or something simple without being told to helps me feel like you won’t do that, and that i might be able to trust you on day 0. expectations on seniors are higher [0]: https://grugbrain.dev/

As a CEO of HTMX, I'm qualified to say that recursivedoubts is best described as a grug-brained developer. https://grugbrain.dev/

As often, Grug has a great line about microservices: grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices

https://grugbrain.dev/#grug-on-saying-no > best weapon against complexity spirit demon is magic word: "no" > "no, grug not build that feature" > "no, grug not build that abstraction" > "no, grug not put water on body every day or drink less black think juice you stop repeat ask now" > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer > is ok: how many shiney rock grug really need anyway?

Does anyone have a better article on this? This is ok, but it seems like there are better - I would love to share with my team. These are things I always share with them: On code reviews: https://mtlynch.io/code-review-love/ On simplicity: https://grugbrain.dev/ On SOLID (even though we use Python now): https://www.baeldung.com/solid-principles I would love to have a "standard" article for planning.

https://grugbrain.dev/ has the following to say about microservices: "grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug"

I loved https://grugbrain.dev and wanted more content. So now you can talk to him!

John Ousterhout, Carson Gross (htmx, https://grugbrain.dev), and Rich Hickey are my favorite people on complexity. John Ousterhout was notably my professor for operating systems @ Stanford. He taught not just ways to design software, but also ways to live. Carson’s work is also directly influenced by Ousterhout, as referenced at the end of his article. For John Ousterhout, I suggest looking at the class website: https://web.stanford.edu/~ouster/cs190-winter23/ For Carson Gross, I suggest his book, Hypermedia Systems: https://hypermedia.systems/

Gotta dumb yourself down to write your best code sometimes. In this vain this often posted article is fun https://grugbrain.dev/

"apex predator of grug is complexity complexity bad say again: complexity very bad you say now: complexity very, very bad" https://grugbrain.dev/ No really -- I would bet that the single greatest contribution comes from the massive growth in complexity, in all relevant areas, over the last 20+ years.

After learning about a few of these I started to understand why people coming from C always said that PHP is a well designed language… But OK, I understand that my mind is just not made for the complexity of C. Most likely I'm not a real programmer. I get instantly knots in my brain and start to bang my head against the wall when I need to look for too long on C code. Actually even C documentation is enough to trigger this. (I get mad every time I have to look on a Linux system man page). This is highly subjective of course. Other people seem to love C! I'm more of a grug brain¹, who mostly only understands plain pure functions. Input in, output out. No magic. Everything else's too taxing. ¹ https://grugbrain.dev/

Articles like this bug me. You've given me a list of why types are awesome. Great. Now, tell me what the tradeoff is. Nothing is free in engineering. To get something, you have to give up something else. Even grug[0] understands this. [0]: https://grugbrain.dev/#grug-on-type-systems

It's worth mentioning that the world could use a few more grug-brain developers: https://grugbrain.dev/

I very much like the ethos of Golang for this reason. Still not had a reason to use it but like the idea of mastering the fundamentals in a weekend. Even if I lose the flexibility of LINQ or Java streams. It feels like a scale of language conservativeness Go all the way at the top, Java somewhat in the middle (a little above) and C# at the bottom. It is going the route with lots of features and complexity, which can be a great thing but not for grug devs https://grugbrain.dev like me. But saying all that Blazor looks really good for WebDev, I just worry it gets abandoned. It feels everything does in the C# space. C# also made a big mistake imo by going with async/await instead of lightweight threads which will add a ton of complexity in the future for if they decide to go the greenthread route like Goroutines/Project Loom.

Link: https://grugbrain.dev/ It is universally worth your time to read it if you haven’t :)

As another reader who has no idea what any of this is about, I've coerced my favorite LLM to digest it into ooga-booga format in the style of this essay[1]: # grug see big sky boom - sky make ooga FLASH but not light, just invisible whoosh (radio). - whoosh so strong, like sun work many day, but all squish into blink of eye. - smart sky-people have big ear rock (CHIME). ear rock say: "boom come from there, galaxy far, but not too far (only 130 million fire-circles (light years) away)." - ear rock also have many little ear-brother rock across land, help point finger very good. - finger point so good, sky-people know spot of boom smaller than tree forest (13 parsec). - then, magic glass eye (James Webb) look at spot. see old fat star (red giant) glowing soft. - but fat star not make ooga boom. hmm. maybe fat star have sneaky tiny angry friend (neutron star). - tiny angry friend go "KRAK!" → make fast radio boom. # lesson for tree-brain - boom in sky still big mystery. - now smart sky-people can say where boom come from. - if know where, can watch with other eyes, maybe find secret of why. - grug think: many sky boom = maybe angry tiny stars yelling far away. # Ooga booga translation: "Tree no know why sky yell. But now tree know where sky yell. Soon, tree maybe know why sky yell." [1]: https://grugbrain.dev/

Yeah, I dunno. This seems to have really missed the mark. I do think the original[1] is worth a read. Even if I didn't like the style, I can appreciate the message: complexity is a cost, spend your complexity budget on things that matter, take the 80/20 Pareto win, no silver bullet, Chesterton's fence, etc. Importantly, the original is ever so slightly self-deprecating in a way that the intended audience can appreciate. Compare this quote from the OP. > Even when new grug shout loudly, important not to give new grug too much shiny rock. Why? First: make sure new grug really want to join tribe, make tribe strong. Those who have read enough startup executive "thought leadership" probably recognize this idea: don't hire people who care about competitive compensation - those who work for passion will accept less. For the record, I personally think this idea is inherently toxic and exploitative - but let's put that aside for a moment. Even if one were to accept that idea as valid, this framing comes off as infantilizing. The same tone that was at least arguably acceptable for self-deprecation is entirely inappropriate for deprecating others. I can only imagine this guy's employees are going to have a bad time. [1]: https://grugbrain.dev/

The drama around this community is silly. I use these tools because I absolutely love their philosophy on software, and software alone. I couldn't care less what the authors personal beliefs and political leanings are, or who they offended on IRC or social media. I recently spent a few hours evaluating different terminals. I went back to urxvt, tried Alacritty again, gave Ghostty a try, and spent quite some time configuring Kitty. After all this I found that they all suck in different ways. Most annoying of all is that I can't do anything about it. I'm not going to spend days of my life digging into their source code to make the changes I want, nor spend time pestering the maintainers to make the changes for me. So I ended back at my st fork I've been using for years, which sucks... less. :) It consists of... 4,765 SLOC, of which I only understand a few hundred, but that's enough for my needs. I haven't touched the code in nearly 5 years, and the binary is that old too. I hope it compiles today, but I'm not too worried if it doesn't. This program has been stable and bug-free AFAICT for that long. I can't say that about any other program I use on a daily basis. Hhmm I suppose the GNU coreutils can be included there as well. But they also share a similar Unixy philosophy. So, is this philosophy perfect? Far from it. But it certainly comes closer than any other approach at building reliable software. I've found that keeping complexity at bay is the most difficult, yet most…

> towards something that is generally appreciated. I think it's simpler than that. It's convergence to the lowest common denominator. The simplest implementation of the simplest thing that does the job, in the simplest easiest language that is capable of it. But because "simple" can be taken to extremes of very clever but abstruse tools that only near-genius level minds can use effectively, and those folks do not work well together, what ends up cheap at first is the simple easy thing that is simple and easy to get working. Lisp might be arguably simpler in a theoretical sense but for a lot of ordinary folks it's just too weird and too hard. APL is "simple" inasmuch as a hundred lines of nested loops can be written as one line of a dozen hieroglyphics that does the same task in one operation... but there are only a few hundred people on the planet that can read it. C is a simple tool for simple computers but you can pick it up and learn how to use it with just a book and some time. It's fiddly and hard to do anything clever which means programmer must do grug brain stuff. https://grugbrain.dev/ And that means others can follow it, and work with it, and that means teams scale. Not very well but a bit. So companies can hire rooms full of grugs and make it work. Result, fairly simple dumb tool beats clever fancy more capable tool. Result, people who like the dumb tool have strength of numbers and they mock the speccy nerdy weirdos who like the weird tool. Which is…

> If the FaaS can catch the OOM, restart the instance and re-run the request, the visible effect would be somewhat greater latency for that request. I’m not aware of an FaaS that would hide the OOM… that falls under the “not a real thing” category. It would be a failed request, which is a very visible effect. Would you like to link me to the Lamda docs that say it will automatically retry the request in case of an OOM? Also consider that code which OOMs will do so unpredictably. It may have completed half of a task, leaving that task in a corrupt state that requires manual intervention from a human to recover from. If everyone wrote fully idempotent code that can somehow skip the already-completed updates and continue where the OOM occurred, this wouldn’t be a problem, but that isn’t what everyone does. This is certainly a large reason why FaaS do not retry requests automatically. > If the service is configured to automatically kill and restart instances after some time or some number of requests, it seems like a reasonable tradeoff. I don’t believe Lambda has any configuration parameters for those things. That’s not how this is meant to work. Lambda will kill the instance when it has been idle for too long, and that’s the primary factor. You could manually exit the process when your conditions are met, but why? The benefits of turning off the GC are likely to be negligible. This is a lot of complexity for no real gain. It would take some seriously huge gains…

I was part of a team maintaining 150k lines of ancient JavaScript. Doing this requires careful engineering, but is otherwise possible, though not recommended. A good friend of mine is still there. I find conversations with him enlightening because there does not exist a mainstream type system which can clearly an concisely express what he's doing there - even though these are fairly mundane things in dynamically typed languages, like arguments with correlated types. I'm a firm believer in exercise as a means of maintaining skill, so I've been doing a hobby project in vanilla JavaScript. Of course I make type errors, but they're usually the sort that makes me go "aw shit, this field is wrong" and move on. Meanwhile I relearned some characteristics of this environment, which are: -Tests are mandatory. -You have to be radically explicit, otherwise you lose track of what you've been doing. -Documentation is the cornerstone of remaining on track in the long run. -The biggest mistakes are not in the types, but, unsurprisingly, the logic behind the code. -General advice, like short-circuiting edge cases, using pure functions and immutable data structures still applies. -As per Grug (https://grugbrain.dev/) - "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" - wise tell this, me concur Some interesting features of…

I'm not aware of exactly what you're looking for, but I think such a resource would be very valuable. Unfortunately, modern web development has almost completely eschewed simplicity. I can offer some leads, though. This is more of a manifesto but there is a small movement around simplicity at https://grugbrain.dev/ which is written by the guy behind https://htmx.org/ -- a nice little way to add the bare minimum JS needed for a 'modern' app. You can find a community of likeminded people at HTMX-adjacent places like their Discord and Twitter. I've also been an advocate of this kind of 'primitive' dev style and it's great to see it gain some popularity. This recent talk from Djangocon "React to htmx on a real-world SaaS product" might be of interest: https://www.youtube.com/watch?v=3GObi93tjZI Ironically, the ultra-modern serverless platforms such as Cloudflare Workers have strict size constraints which is leading to a kind of back-to-basics approach that minimizes dependencies and bundle size. You can find a lot of small libraries for this at https://workers.tools/. The latest JS framework to buzz here, Deno's Fresh, even touts "no JS is shipped to the client by default". We can see there is a resurgence of interest in server-side rendering. The classics such as Rails are still alive and kicking. Phoenix seems to be a promising candidate for "the modern Rails". As someone who experienced the Good Old Days of web development, I would recommend at least trying out the…