16 ms·
The Grug Brained Developer (2022)
- dang 3y agoDiscussed at the time: The Grug Brained Developer - https://news.ycombinator.com/item?id=31840331 https://news.ycombinator.com/item?id=31840331 - June 2022 (374 comments)
- givemeethekeys 3y agoComplexity still very bad.
- deleted 3y ago[deleted]
- jauntywundrkind 3y agoGrug 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 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 discover. I see a lot of people resolute & certain that everything around them (except what they do) is complex & needs to be bent into simplicity. It feels dangerously weak & clutching after authority.
- hotnfresh 3y agoWhat I like so much about the Grug piece is that it’s full of nuance and humility. It’s not pretentious.
- Affric 3y agoGrug express simple and clear. Grug no make small problem big. Grug humble.
- user8501 3y agoThat’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.
- jt2190 3y ago> The issue with this philosophy is that it tends to lock in first generation design choices… I agree. A common approach to simple is “just start with the first thing that pops into your head and see how far you get.” I guess we could describe that as “simple to think of.” A far less common approach to simple is “think through the whole problem, then remove everything that you don’t need.” This is what I’d call “a simple solution”, but note that it takes a lot more work to find it.
- jauntywundrkind 3y agoYou'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.
- dustingetz 3y agomeasure 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
- bloaf 3y agoI've seen a lot of people hating on LOC as a measure of complexity, but I think there is a signal in the noise. I think it does a pretty good job of identifying if you're fighting your tech/language or doing things the "intended" idiomatic way. The difference is usually at least an order of magnitude in LOC.
- jongjong 3y agoIt'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 forces. Even developers who appear to be totally robotic and ego-less are often guilty of over-engineering. It works on the subconscious mind. Few are ever able to escape the mindset because they are not fully conscious. They are not thinking about every single line of code that they write. They decide on some goal and then churn out whatever code first pops into their heads to get incrementally closer to that goal... Not realising that, at each step, there were many alternative paths that which were superior.
- josephg 3y agoI 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 straightforward and necessary. Its only later when I step away from my code and then try to understand it with fresh eyes do I notice what a mess I've made of everything. I also think that a lot of the time the most obvious solution to most problems is quite complex. It takes wisdom, skill and domain knowledge to know where to look for simple solutions to any given problem. Simple, clean solutions are rarely obvious. "Oh, it looks like we're slowly implementing a halfbaked message queue. Lets use a standard message queue instead." "Oh, we're slowly building up a custom, buggy, binary framing protocol. Lets just use protobuf/msgpack". "How about instead of writing a custom RPC protocol to fetch data, we just use REST over HTTP. And then we can put nginx in the middle to cache our backend responses, and we can throw out our custom cache."
- eldavido 3y agoThis 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 and "dumb" and does exactly what it's supposed to do. The other thing to realize, a lot of great code doesn't just spring from the developer's hands in its final form -- it's extensively edited and rewritten into its final, good, form.
- jiveturkey 3y agovery hard to read, but worth it
- dartos 3y agoEasy read. This grug turn off brain. Only grok from page for this grug.
- gofixurcode 3y agobig brain is not use brain make brain read grug.
- hotnfresh 3y agoReminds me of classic FILM CRIT HULK columns. The content’s good but the style can take some getting used to.
- magarnicle 3y agoHe dropped that style a while ago, for that reason I think.
- stylepoints 3y agoI asked chatgpt to fix it: ``` Intwoduction this cowwection of thoughts on softwawe devewopment gathewed by gwug bwain devewopew gwug bwain devewopew not so smawt, but gwug bwain devewopew pwogwam many wong yeaw and weawn some things awthough mostwy stiww confused gwug bwain devewopew twy cowwect weawns into smaww, easiwy digestibwe and funny page, not onwy fow you, the young gwug, but awso fow him because as gwug bwain devewopew get owdew he fowget impowtant things, wike what had fow bweakfast or if put pants on big bwained devewopews awe many, and some not expected to wike this, make souw face THINK they awe big bwained devewopews many, many mowe, and mowe even definitewy pwobabwy maybe not wike this, many souw face (such is intewnet) ```
- brettermeier 3y agoSome sentences are, but the whole thing is a pleasure to read, I really enjoyed it :)
- datadrivenangel 3y ago> 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.
- greatgib 3y agoWho wrote that? I want to know! I need to know! I need to follow him/her on Twitter, LinkedIn, GitHub, Whatever, ... I need to work with him/her, it's my doppelganger!
- hyggetrold 3y agoIt's the author of htmx - very smart guy. :)
- deleted 3y ago[deleted]
- avindroth 3y agoCarson Gross https://www.backendbanter.fm/episodes/024-behind-htmx-carson-gross-on-the-re-rise-of-hypermedia https://www.backendbanter.fm/episodes/024-behind-htmx-carson...
- pjs_ 3y agoOK 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 out
- noman-land 3y agoSpoiler very much alert.
- squeaky-clean 3y agoIf it's in the trailer it's fair game. Besides an actual spoilery description for From Dusk til Dawn would be all the non-vampire parts. The "twist" is that a movie billed as Robert Rodriguez vampire schlock actually has an entire other movie contained in it. That's a bit of a spoiler I suppose, my bad.
- Tao3300 3y agoThe Dimension Collector's Series DVD cover has the fanged face of a vampire woman on it. If someone thinks it's ruined because they found out ahead of time that there are vampires in it... yeah, that's their problem.
- recursivedoubts 3y agolmao so true
- kirse 3y agoeveryone is going to get on the HTMX wagon This is an infinite cycle with JS though. Someone tired of JS complexity writes a simple JS lib (SJSLib), SJSLib attracts people for simplicity, SJSLib grows complex because it has to support all the web things, someone tired of SJSLib complexity writes a simple JS lib... I say this as someone who started with raw JS and fought IE5/6 for years, jQuery then saved us all, skipped over AngularJS because it was meh, React beta finally came around and loved it for FP ideals, now wade thru piles of transpiling / hot-reload / Typescript and React fat-libs. Have also written a few projects with both Intercooler (and now HTMX). HTMX is overall solid, but this ain't the first wagon to come through town.
- hyggetrold 3y agoI 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
- Cerium 3y agoI 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
- globalnode 3y agoGrug Inc. -- Fantastic! I really enjoyed reading this and feel like im guilty of unleashing the complexity spirit demon, even though im not even a big brain. Out of curiosity, are there any programming languages that naturally steer people away from complexity? but still "get the job done".
- dinkleberg 3y agoOf the languages I’ve used, Go comes closest. The language is small and boring, but it means I stay focused on the problem and hand instead of getting fancy.
- MrVandemar 3y agoThat's the first thing anyone has ever said about Go that makes me want to learn the language. That sounds like an ideal programming language.
- fredrikholm 3y agoThis mindset permeates through the entire ecosystem and tooling as well. Enterprise projects build in single digit seconds, test suites fly by, project builds to a single binary (with embedded resources), most third party dependencies follow the established interfaces (which means plug and play) and so on. It's the one language that I feel confident in, despite having worked in several other languages for many more years than Go.
- gofixurcode 3y agoI second this but I will say that the complexity demon lives in the reflect package.
- harimau777 3y agoThere are two ways that a system can get unworkably complex. The most obvious is to overengineer and introduce too many excessively complex abstractions. However, it is equally harmful to become dogmatically obsessed with using the most "straightforward" implementation when more sophisticated approaches would make things easier to understand. I have not used Go, but what I have heard makes it seem like it is designed in a way that would encourage the second approach.
- kikoreis 3y ago"danger abstraction too high, big brain type system code become astral projection of platonic generic turing model of computation into code base"
- renewiltord 3y agoEveryone's blub paradoxed about simple. Anything below your chosen level of simplicity has no features. Anything above is too complex. You are at the true simplicity optimum. Your manager is the one who doesn't get it. Terrible guy. Understands nothing. Unlike you, true artist, pure simplicity.
- streakfix 3y agoThe only reasonable comment here
- noman-land 3y agoIncredible essay. Very funny and very wise.
- deleted 3y ago[deleted]
- fiddlerwoaroof 3y agoThis 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.
- sarchertech 3y agoThere’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 complexity coming out is the vastly larger amount of inexperienced developers around them. It’s much easier to add complexity than it is to fight it.
- fiddlerwoaroof 3y agoThere’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.
- ansc 3y agowhy is this ”anti-intellectualism”? intuition is a strong quality to have in your code.
- harimau777 3y agoWhat is intuitive is strongly dependent on what you have been taught. For example, if you have only been taught to use loops, then iterator functions like map and filter seem less intuitive. However, once you have learned them, iterator functions are dramatically more intuitive than loops.
- Jeff_Brown 3y agoI enjoyed "black think juice".
- I_Am_Nous 3y agoGrug not put water on body every day
- hyperthesis 3y ago> but grug must to grug be true
- darylteo 3y agoBUS RAM CPU BUS RAM CPU
- hyperthesis 3y ago> limit damage of big brain developer early in project by giving them thing like UML diagram Ah so this is the purpose of UML!
- lartin_muther 3y agook. so grug make good, good point. many good point. now say others no listen and do opposite of what grug say for month after month. code complex. code very complex what grug do now
- syradar 3y agook. some need feel fire under ass to see house burning. grog only relax and wait. complexity spirit demon do the rest
- otteromkram 3y agogrug say now ok reach for club
- gofixurcode 3y agogrug sad. grug make complexity demon more power. grug look at code. complexity demon look back. grug raises club. grug factor. complexity demon no more. grug tired. grug sleep.
- metabagel 3y agoI read it in this voice. https://youtu.be/v79fYnuVzdI?si=2iEdgEgx3Q-7RyI_ https://youtu.be/v79fYnuVzdI?si=2iEdgEgx3Q-7RyI_ (Zathras Wrong Tool)
- insanejudge 3y agoI'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.
- nicolas_t 3y agoI love the section on tests. It really is exactly what I've come to learn over the years. Integration tests are the sweet spot for finding bugs. Mocks tend to over complicate things (I still use them sometimes but I avoid using them systematically) and unit tests are too brittle in face of refactoring whereas integration tests help with refactoring.
- chalcolithic 3y agoCan't agree more. My favorite way to cheat with them is to have integration tests that follow demoing scenarios, so you can run them right before the demo (preferably twice)
- aardvark179 3y agoStrongly disagree. Integration tests work brilliantly until a certain size or complexity is hit and then they become really bad. Unit tests are harder to write and maintain, but they will serve you much better in the long run because when they fail it’s much easier to understand and debug. The worst sort of tests are integration tests which secretly depend on another integration test having run first, which will be true 99% of the time, until a change you make changes the order.
- hitchstory 3y agoUnit tests have lower up front costs but higher ongoing costs. By their very nature they couple more to implementation details, so they will not give you clear confirmation when code is broken. Integration tests can give unclear signals when they are flaky, but when they are engineered well they will give a much clearer signal that things work when they pass and that something is broken when they fail. It's harder to engineer a good integration test - this includes making them isolated and independent e.g. of test ordering or indeed, anything else.
- nicolas_t 3y ago> The worst sort of tests are integration tests which secretly depend on another integration test having run first That's an example of bad integration tests. Well engineered integrations tests don't do that.
- thefourthchime 3y agoI've been a developer for 30 years, and I'll admit that in my early days, I was arrogant and thought I was smarter than everyone else. I'd describe myself back then as one of those "big-brains" loving all the complexity demons. 10 years later, and I've shifted more towards being a "Grug brain" developer. Now, I focus on the simplest solution that could possibly work, knowing that it's probably not perfect. But that's okay, because it gets me closer to what is correct, allowing for iteration. The best thing you can do as a developer is to delete code! Right now, we have a requirement that we've been living with for two years that suddenly isn't a requirement anymore. I can't tell you how excited I am to go through and rip out a whole bunch of code, because it makes everything simpler.
- namtab00 3y agoThere's some indescribable and pleasurable sensation in the back of my head when I delete code. It's like I'm FEELING the space being freed.
- p0nce 3y agoOK, this was better than expected.
- p0nce 3y agoWhile I agree mostly, you can overdo the "grug". For example it is possible to underengineer (underabstract?) a software for years until realizing that simple things are still complicated, and you forget to built good abstractions once the patterns have emerged. If you build abstractions, you need a way to correct them anyway, making breaking changes to their contract.
- stnmtn 3y agoThe point is that "underengineering" then having to tie up the abstractions when it's really needed is oftentimes (read: not always) better than overengineering and entering the domain of the complexity demon
- p0nce 3y agoI agree that the balance is way too often shifted in the way of overengineering, probably because of our field being skewed by "higher status" thinking.
- mordae 3y agoI have a beef with the typing section: > 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 Juniors at my job routinely ship code that breaks due to null access in production, Sentry tells me. During intensive development periods that's about 1 detected null-access bug per day per junior developer. Using a proper type system with static checks would probably help immensely by pointing out "Hey, this can be null. You sure?" in their IDEs... Also, you can have completion even without static typing. > big brain type system shaman often say type correctness main point type system, but grug note some big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct That's just rude and uncalled for. I have shipped code mainly in in C, PHP, Python, Haskell and typed Python. The incidence of bugs that make it into production is much lower with typed languages. That's one reason to like it. It also makes refactoring much, much easier. I can check whole code base for broken callers when I change something widely used and get reliable results in seconds. That helps immensely with iterating on a growing code base.
- dryanau 3y agoI'm confused. The original article is in favour of typed languages. Aren't you in agreement?
- n4r9 3y agoI think they differ about the why. The article claims that types are useful mainly because they allow sophisticated auto-completions. u/mordae thinks there are more important benefits re avoiding bugs in production.
- randomdata 3y agoIn the link, Grug acknowledges the benefits of correctness established by types to an extent, but is highlighting the diminishing returns. After all, if one truly valued type system-enforced correctness, they would be writing code in something like Coq, not C and typed Python.
- juliangmp 3y ago>sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice grug speak only true
- brettermeier 3y agoThis is my favourite read this year I think :D
- jamil7 3y agoA lot resonates with this, particularly factoring code and carving out barriers later on when the project has settled. I believe there are some antipatterns like singletons and globals that on the surface look grug-brained but are actually complexity multipliers.
- sesm 3y agoSaying "complexity bad" without giving a definition of complexity is not very meaningful. In reality it means "I'll use my personal judgement and anything I don't like will be marked as complexity". Rich Hickey gave his own practical definition of complexity and followed it in his design, and sometimes the results are very unintuitive. For example, transducers in Clojure are actually simple (by his definition) because they de-couple transformation from the context. Also, by his definition HTMX approach (aka PJAX, aka HTML-over-the-wire) would be more complex then JSON + client side rendering, because it couples together multiple things: network, routing and rendering.
- johanneskanybal 3y agoThis is just the best. I’m gonna force this on you ger colleagues.
- Mikhail_Edoshin 3y agoIf you need nuanced behavior, you need a complex controller. And you always need more nuanced behavior, this is the inherent nature of software development. Sometimes the appearance of simplicity is achieved by making the behavior simpler (e.g. dropping the support for old versions, not implementing parts of the specification, and so on). This is degradation, not simplicity. The right simplicity is an art of having the required complexity yet somehow manage it internally. So complexity is not bad. It is given. What is deficient is our skill.
- Spivak 3y agoi don't think grug actually disagrees with you here but takes the position that skill both can't be counted on and doesn't scale. And this matches my own dev experience cathedrals of complexity pale into comparison that code that's easy to throw away and rewrite to meet changing requirements or scope.
- harimau777 3y agoMy experience has been that the powers that be generally won't give developers time to rewrite to meet changes in the requirements. Personally as I see it: iterative development with time to rewrite > cathedral development > "iterative" development without time to rewrite I think that most teams actually do "iterative development without time to rewrite" so cathedrals of complexity would actually be an improvement.
- alex440440 3y ago[flagged]
- never_inline 3y agoNobody asked.
- nercury 3y agoThankfully ChatGPT can translate this into readable English.
- p5a0u9l 3y agoGrug took their muse too far. Had much hard time try parse meaning from grug.
- dieselgate 3y agoNice to see this pop up again. Grug life!!