The Grug Brained Developer (2022) • Hacker News Board

Re: The Grug Brained Developer (2022)

#71

Post by jauntywundrkind » Tue, Oct 31, 2023, 3:27 AM UTC

user8501 wrote: post #12

jauntywundrkind wrote: post #4

Grug 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 m…

You've made one strawman accusation, and sure, people polarized that specific way (insisting only things worth doing are worth making reusable) are often doing bad things.

But I see plenty of anti-intectual anti-whatever attitudes founded in other forms of disdain. And I think grug reflects a broad/broader spectrum of negative biases.

One example, I've had an incredibly hard time getting folks to switch from dirty cobbled-together-with-StackOverflow shell scripts to Ansible, which is a just more sight-readable consistent experience. Or to zx or anything not just badly written shell scripts no one collaborates on.

People swear worse is better, are YAGNI (you ain't gonna need it) up the wazoo against 90% of everything. I think grug picks a lot of things to bash on, and a lot of devs do to.

I adore simplicity, but I find it challenging & long & arduous to hammer out of things. It's not fast to produce, or low thought. It's not made by resolutely sticking to lo-fi paths & mentalities.

We do need to be aware of the hazards at the other side, of ridiculous complexity & absurd/unnecessary systems engineering: yes! And I think grug offers some good almost-koans to reflect on, illuminates real hazards well. But I also think it's actively harmful & pernicious to put grug-brainedness on a pedestal, to go about actively disbelieving against any possibilities that might possibly be done simpler.

We seem to agree that simplicity takes iteration. Grug presents it as "oh I'm just dumb grug brain, I dunno" but in practice there is a lot of infighting in tech, and those who insist too loudly on aiming too high are not even IMHO as dangerous as those too loudly insisting on too low. We have to keep engaging possibility from all sides, & keep finding out what balances do work.

Re: The Grug Brained Developer (2022)

#72

Post by metabagel » Tue, Oct 31, 2023, 3:43 AM UTC

I read it in this voice.

https://youtu.be/v79fYnuVzdI?si=2iEdgEgx3Q-7RyI_

(Zathras Wrong Tool)

Re: The Grug Brained Developer (2022)

#73

Post by Cerium » Tue, Oct 31, 2023, 3:50 AM UTC

hyggetrold wrote: post #24

I love this site, always get a laugh out of it. My absolute favorite: Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug

I love this site and read it regularly. Everyone I know must be tired of the "software development manifesto" that is grug brain.

>complexity very, very bad

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

Re: The Grug Brained Developer (2022)

#74

Post by jauntywundrkind » Tue, Oct 31, 2023, 3:50 AM UTC

pjs_ wrote: post #22

OK I reckon everyone is going to get on the HTMX wagon over the course of the next few months, and it's going to blow a ton of young minds and save a huge amount of global energy and make a lot of people very happy. And then these same inquisitive young people are going to click enough links on htmx.org that they stumble across hyperscript and it's gonna be like that moment in Dusk till Dawn where the vampires come o…

Ah! Carson Gross is author of grug brained developer, and htmx!

I'd love to see some real critiques of htmx.

Personally I think the web's big ongoing challenge has been figuring out how to update the page well, and we keep trying all kinds of attempts. That causes fatigue, and some of the ideas are wild or grow crufty over time. Htmx seems like a back-reaction, to insist on grug brained less/YAGNI.

And even though the future is uncertain, I still see work on things like signals as saintly. There's a lot of different pokers in the fire, refining & trying different angles. We're still pioneering this front, other fronts.

The quest feels similar to so many others. MobX and Svelte and others have made great journeys already. That the journey is still irresolute, that we do keep tangling with the complexity beast: rather than that being a sign of weakness, as the conservative/grug minded might take it for, I think and I hope it's appropriate & due effort to reach a simple but good. Rather than a just simply simple approach.

Re: The Grug Brained Developer (2022)

#75

Post by adonovan » Tue, Oct 31, 2023, 4:00 AM UTC

neilv wrote: post #70

Trasmatta wrote: post #18

Earlier quoted context omitted.

> 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.

Lock-in factor and billable hours can be motivations for contractors. But, for contemporary software developers in general, I'd guess more often it's either resume-driven development (e.g., add the big complex new framework keyword to your resume) or not yet having enough experience to know what complexity is worthwhile for a situation.

In my experience most over-engineering can be explained by a lack of understanding. When we design it, we don't know what matters and our guesses are wrong; and when we modify it later, we don't have time to figure out how it really works. Both of those problems can be fixed by simply spending more time to understand, but time is money.

Re: The Grug Brained Developer (2022)

#76

Post by userbinator » Tue, Oct 31, 2023, 4:16 AM UTC

jongjong wrote: post #6

It'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…

I wouldn't call those "smart people". They're not much beyond mediocre, but see overcomplicating things (which in many cases they will dogmatically explain away as being a "best practice") as a way to make it appear like they're smart.

The smartest are those who can make complex problems look simple, with simple solutions.

Re: The Grug Brained Developer (2022)

#77

Post by fiddlerwoaroof » Tue, Oct 31, 2023, 4:24 AM UTC

sarchertech wrote: post #54

fiddlerwoaroof wrote: post #45

This piece reflects some of the most frustrating professional interactions I’ve ever had where people insist that something is too complicated with no concrete suggestions for simplification.

There’s 2 reasons that can happen. 1. It’s not actually overcomplicated, but the people saying it is haven’t thought about it hard enough to realize this. 2. It is overcomplicated, but it’s such a tangle of complexity that fixing it would require the people pointing out the problems to basically do it over from scratch. #2 is usually the result of a very experienced developer being overwhelmed by the amount of comple…

There’s also a third reason: a form of anti-intellectualism where you think that designs that are hard to derive are intrinsically more complex than just doing the straightforwardly obvious thing.

Re: The Grug Brained Developer (2022)

#78

Post by jauntywundrkind » Tue, Oct 31, 2023, 4:28 AM UTC

Trasmatta wrote: post #18

jongjong wrote: post #6

It'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.

Today's best post on complexity to me was the I accidentally saved my company half a million dollars, which is a story filled yes with a lot of poor developers but much much worse is a story filled with Conway's Law style lessons. Of madcap organizations & wild legacy systems that we live atop & typically just have to make do with. https://news.ycombinator.com/item?id=38069710 https://ludic.mataroa.blog/blog/i-accidentally-saved-half-a-...

So much of the grug-brained argumentation is same-side violence, is developers roasting developers. Assigning bad motives & declaring immoral bad people among us probably takes already same-side disdain & amplifies it, forments real & powerful hatred. Yes, various petty or criminal over engineering happens some, yes. But I usually think there are simpler Hanlon's Razor explanations that aren't even the individual's fault, are just the story of an org: an organizational body where so many constituent members of the body-whole have so little idea what others are doing or have done, and access to so few who can offer informed situational-appropriate wisdom for whatever dark end a squad finds itself tasked with.

In some ways, this has been the actual story of open source. We have not been end user facing. We have grow communities of practitioners with individual knowledge & experience that ports & can be compared & discussed with others, from outside our company. We get peership that companies can rarely afford or find after they grow mid-sized.

The Influx folks just talked about their 3.0, & replacing their custom built engine with Flight, DataFusion, Arrow, and Parquet. Maybe they might miss one box or two on neat nitty gritty optimizations (maybe this guy elsewhere in this thread, insisting on diy'ing binary encodings because protobuf doesn't have 16-bit ints can find some deficiencies, https://news.ycombinator.com/item?id=38078133), but the nice to haves of ecosystem integration seems like an intangible, but one that lets little good things out there plug in & help out, and that seems invaluable. https://news.ycombinator.com/item?id=38013714 https://www.influxdata.com/blog/flight-datafusion-arrow-parq...

The top comment to me epitomizes the worst of grug brainedness. It's smug & certain of itself, a strong & divisive Hanlon's violation of high degree. That kind of blue-on-blue attitude to me is far worse than 99% of the people who end up over engineering. Few organizations have real defense, lack coherency, to help themselves away from complexity, or they have such tight constraints that they overprune & disaffect those who do care and have good ideas. These are organizational issues, and having an org that can somehow see itself & what's afoot is the huge challenge. Stop hating on devs, please.

Re: The Grug Brained Developer (2022)

#79

Post by qweqwe14 » Tue, Oct 31, 2023, 4:31 AM UTC

erik_seaberg wrote: post #59

qweqwe14 wrote: post #29

Earlier quoted context omitted.

> "Oh, we're slowly building up a custom, buggy, binary framing protocol. Lets just use protobuf/msgpack" By using protobuf/msgpack you lose the ability to precisely control the layout and encoding of your data on the wire. Most applications don't care, but this results in your wire representation being defined by "whatever protobuf says". Say I want to transmit an unsigned 16 bit integer with protobuf. How do I do t…

It might be different if you have to talk to an ASIC that cannot understand protobuf, or send billions of values at line speed. But generally I don’t have to care anymore whether a number is sent in exactly sixteen bits, for the same reason I long since stopped caring about message framing or parity or run-length limits or 0-5 vs ±12 V busses. Expressing any of those constraints takes more effort than letting the mac…

It wouldn't be ad hoc per se, basically you would have a set of guidelines on how to transmit data and that by itself would be a standard.

Something like "use fixed length 8/16/32/64 bit signed/unsigned integers in big endian, length prefix can be 8/16/32 bits, bool is 1 byte (00 = false, 01 = true)" etc, without extra stuff like varints or bit packing, which a lot of current formats are doing.

In short, just use the most straightforward way of encoding while also using the least amount of data. Big endian for ints is very common, simple and relatively compact if you only use the bit width that you need.

Re: The Grug Brained Developer (2022)

#80

Post by insanejudge » Tue, Oct 31, 2023, 4:33 AM UTC

I've operated by and described the concept of Chesterton's Fence countless times, so that's a great name to learn. It's such a regular thing working with new grads, etc. that they see some "old legacy crap" and their first reaction is to want to tear it out or scrap the whole thing start over.

On some occasions it can be worth the lesson to let them try but it's a good thing to remember that the people who came before us weren't all complete idiots and there is generally a reason why they did what they did.

Sometimes it is gross old code that needs to be replaced, but even then it often still contains a hard fought record of all of the corners and edge cases you need to understand and handle to build anything in that domain.