51 ms·

The Grug Brained Developer

• nathias 4y ago
  complexity isn't bad, redundant complexity is
  • thealistra 4y ago
    Yes, people often confuse inherent problem complexity (maybe domain complexity) with unneeded complexity introduced by code architecture. You can reduce the latter, but often you can't reduce the former. That's why it is best to keep abstraction for code architecture at bay.
    • nyanpasu64 4y ago
      You can reduce inherent problem complexity by picking a simpler subset of the task to solve (for example only support a single backend rather than plugins and interfaces, or exclude complex problems like text ligatures and glyph shaping). The resulting program will be shorter, have less indirections (making it easier to trace statically, and require less scrolling between functions and jumping between files), easier to make correct and fix bugs, and easier for outsiders to read and learn the fundamentals of a problem domain from. And once you've learned a conceptual understanding from simple programs (JACK2), you'll be better-prepared to learn big complex programs (PipeWire), which are harder to learn not only because they deal with more complex problem domains (latency compensation, multi-device synchronization, video), but also because they suffer from dynamic dispatch (requiring runtime debugging to identify which type implements an interface) and are too big to learn the architecture by merely looking at individual files (though I hope projects get better at teaching architecture: https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html). Unfortunately, in some cases complex programs adopt fundamentally different architectures (dynamic dispatch and plugins, different data structures, extra modules like Harfbuzz and Pango, etc.) from simpler programs. Perhaps they have reasons for doing so, but in practice I find myself still confused even if I understand the simplified concepts and can write useful code using them.
• MrPatan 4y ago
  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.
  • vlunkr 4y ago
    I would recommend those to anyone here that hasn't seen them. I think this requires a big shift in community thinking. Programmers are trained in universities to throw OOP principles at every problem, and the DRY principle has deeply taken hold. Obviously both have their place, but they often used overzealously and come at the expense of readable and maintainable code.
  • TheOtherHobbes 4y ago
    In "Simple Made Easy" he's recommending XML, JSON and even SQL for data. So I'm going to have go to with "No." All that does is move somewhat messy language constructs into somewhat messy data constructs. The data is static-ish, which is nice. But the associated code has exploded in complexity and with XML particularly you can't even be sure if it's truly compliant - especially if it's coming from an outside source. So I think that whole talk is spectacularly missing the point. The idea is good but functional/read-only doesn't solve the problem. Because some problems are just hard, and no amount of functional twiddling makes the hardness go away. Names are hard. International localisation is hard. Dates and calendars are hard. International holidays and special dates are hard. Addresses are hard. Timezones and time systems are hard. Phone numbers are hard. There is no trivial solution to any of these problems. The most effective solution would be an international standard collection of algorithms and APIs baked into identical standard libraries for each mainstream language. What you get instead is a lot of people wasting time and energy solving these problems over and over - badly. And in fact XML, JSON, SQL, etc are similar. There are countless libraries and frameworks for managing these, and they're all slightly different and likely to fail in different ways - not just in different languages, but in multiple competing frameworks for the same language. The problem isn't the code, it's the culture around it. Instead of solving a problem completely and standardising, the industry is addicted to nearly-but-not-quite solving the same problems over and over. That's where a lot of unnecessary complexity comes from.
• pyrolistical 4y ago
  Heh, me not grug brained right?
• tines 4y ago
  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? :)
  • reidjs 4y ago
    https://github.com/reidjs/grug-dev-translation https://github.com/reidjs/grug-dev-translation Translated as best I could
  • andrepd 4y ago
    grug think grugposting is part of the charm
    • layer8 4y ago
      Grug thinks there would be middle course keeping most of charm but less exhausting to read.
      • manmal 4y ago
        Exhausting make grug read more slowly and parse well.
  • bitwize 4y ago
    This reminds me rather of a cross between "Code Monkey" (Jonathan Coulton song) and Film Crit Hulk Smash.
    • egypturnash 4y ago
      BE THANKFUL GRUG NO TYPE IN ALL CAPS LIKE FILM CRIT HULK, FILM CRIT HULK HAVE MANY THOUGHTFUL POINTS TO RAISE ABOUT FILMS SND STORIES BUT ALSO READING ALL CAPS FOR MORE THAN ABOUT ONE PARAGRAPH IS OUCHY (Film Crit Hulk released a book; half of it was in all caps, the other half was the exact same text except in normal sentence case.)
  • raphlinus 4y ago
• whoomp12342 4y ago
  this is nothing short of amazing
• throwawayacc2 4y ago
  Grug no read good but grug fink is good advice here
• genjipress 4y ago
  You've heard of Film Crit Hulk? Here's Software Dev Hulk.
• whiskeytuesday 4y ago
  > 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.
  • Rantenki 4y ago
    Grug state Chesterton's fence very easy understand way.
• odipar 4y ago
  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!)"
• tboyd47 4y ago
  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
• TranquilMarmot 4y ago
  I think this nicely captures everything I've learned about programming over the past n years that I wish other people would realize too.
  • eurasiantiger 4y ago
    What have been the most complex business requirements for a project you have worked on, and what made them complex? Was the resulting system less complex than the requirements?
    • residualmind 4y ago
      Sorry to hijack without being asked. I totally agree with the original piece and this comment. For me the most important part is: no matter how complex your requirements are, how you deal with complexity and abstraction in your codebase and architecture, will make or break it. Abstractions should match what's actually happening (with just the minimal right amount of future telling). Useless abstractions and missing abstractions are both bad. Getting rid of a bad abstraction in a system is harder than introducing one, though. Erring on the side of fewer abstractions and dumber (not bad, just boring) code especially in early stages can save you literally thousands of hours of debugging, fixing, scratching your head. I may be wrong, this is how I feel right now.
      • 3np 4y ago
        grug think two is company but three is crowd. no refactoring new abstraction until same code in three places. sometimes crowd is fine too, if divided nicely. grug never saw point of new class with only fetchAndParseMany<T> function. also why grog keep putting state in mutable instance properties on acting class when can just be parameter arguments? save so little typing but will for get curse. grug remembers making big object-oriented python2 app multi-threaded. and all that c# when in consulting on legacy codebase. grug avoid such pattern now.
        • eurasiantiger 4y ago
• arbenpurben 4y ago
  This makes me so happy
• jamal-kumar 4y ago
  smol brain can dodge [1] [1] https://preview.redd.it/g1lpdmt1iiv51.jpg?auto=webp&s=a5f27c4ddb2c0e5de01ce85680ad512889dcc16a https://preview.redd.it/g1lpdmt1iiv51.jpg?auto=webp&s=a5f27c...
• GrumpyNl 4y ago
  That's a great write up.
• csours 4y ago
  Even big brain developer is grug brain when read code later.
  • pixelrevision 4y ago
    Big brain no read later code. Big brain go to conference.
  • weeeeelp 4y ago
    Big brain developer go to new tribe to paint new cave for shiny rock, leave old cave with grug
  • euroderf 4y ago
    Grug brain see grug code later. Grug brain say to grug: this code not grug code. Grug scratch head, kill favorite flea. Grug must grok old grug code but get no shiny rock for grok own old grug code. Grug sad, say to grug, next time make grug code more good. Grug boss say: no time, grug do as grug boss say. Grug lift rock, want tell grug boss stuff it. Grug not tell. Grug frustrated. Grug ask more snacks in work cave. Grug ask Aeron butt hammock.
• mcbishop 4y ago
  that grug say many variables good. make this grug many happy.
  • layer8 4y ago
    put explicit type on variable even more good for read code
• agentultra 4y ago
  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.
  • recursivedoubts 4y ago
    ^ sound convince and probably very big brain right at times however! beware apply advice put form data from web page into database with many layers abstraction not needed! grug see many time! fear of looking dumb (FOLD) great danger in such conversations and beware!
    • eurasiantiger 4y ago
  • jjoonathan 4y ago
    It will go away -- to other devs, who will awkwardly and painfully route around grug, adding loads of complexity. Not grug's complexity, though!
  • lijogdfljk 4y ago
    > 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. Hah. Related, i became disgruntled with my previous favorite language for this reason. It promoted this style of development. Surface level simplicity built into the language, with minimal tools to actually manage the complexity that is inherent to the problem space you're working in.
• whiddershins 4y ago
  > Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug > Yes.
  • tharax 4y ago
    This is perhaps the most succinct way I've ever seen this expressed. Agree 100%.
• jstanley 4y ago
  > 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.
  • nisegami 4y ago
    >but then 3 years later you realise something you somewhat care about has been silently broken for a very long time The trick is to never stay somewhere long enough to feel the consequences of your bad decisions
    • collyw 4y ago
      Your reply made me smile, but it's the opposite that has given me my biggest learning experiences. Greenfield projects that you stay on a while. You only have yourself to blame when there are problems a few years in.
• ath3nd 4y ago
• pawelduda 4y ago
  > grug has never used erlang, hear good things, but language look wierd to grug sorry maybe grug try drink elixir?
• deleted 4y ago
  [deleted]
• armatav 4y ago
  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.
  • 49531 4y ago
    > frontend Complexity Demon having a grip on the entire industry Is frontend web development more complex than it needs to be? If so, how?
    • aaaaaaaaaaab 4y ago
      Hehe, good one! Oh, you're serious? :D
      • zero_shift 4y ago
        If it's so bad, you're welcome to write your applications in vanilla JavaScript, with no shims, in flat files without modules calling 1998 era DOM APIs. There's a reason most people don't, however.
        • throwaway892238 4y ago
          developer see javascript think "looks frozen yogurt came out wrong end, but can do job". end up building castle of wrong end frozen yogurt. some say better than no castle. grug say why building with no-no soft serve in first place. (grug know answer: more shiny rock)
          • zero_shift 4y ago
            Please stop the grugposting, it is impossible to read.
            • throwaway892238 4y ago
              you in thread for grug story! no like, no read!
• bobkazamakis 4y ago
  this is art and all of us should be ashamed.
• kazinator 4y ago
  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.
  • girvo 4y ago
    I have accidentally introduced “dope” as a thankful affirmative into our international developers lexicon at work. There’s another even more amusing one too but I can’t remember what it is. Working with global teams is fun!
  • _rgun 4y ago
    Thankfully this is not totally correct. I personally found grug English to be harder to understand/read as a non-native English reader.
• MrPatan 4y ago
  "deserve of club but heart in right place" I love it.
• cubano 4y ago
  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!
• dusted 4y ago
  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.
• deleted 4y ago
  [deleted]
• sovietswag 4y ago
  > 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....
• smm11 4y ago
  I sense a certain age-range here.
  • recursive 4y ago
    grug sense a certain age range in comment
• beckingz 4y ago
  Now we add GRUG to KISS and YAGNI.
• bfung 4y ago
  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>
  • SonOfLilit 4y ago
    grug read one sentence, grug feel smarter already. grug read next sentence, grug feel smart on different subject. grug hope have one sentence in inbox every day. or maybe little bird chirp sentence at grug. but no complex, just many subject.
• planarhobbit 4y ago
  Horseshoe theory right once again: Grug and 100x’er megaminds are aligned, and the midwits are over complicating and underperforming.
• elwell 4y ago
  Basically "Simple Made Easy"
• nullptr_deref 4y ago
  > 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
  • dmix 4y ago
    On the frontend I have a sweet debugger setup with neovim and chrome but there’s definitely a time investment setting it up. The overhead exists almost entirely because of how the code goes through a Typescript, Vue/Vite transpiler and needs to sync with the source map… so breakpoints aren’t a 1-to-1 connection. So yeah console.logs are still quite common even if you have a great debugger because it’s the most accessible and laziest option. But there’s something very rewarding about getting really good with a debugger and figuring things out quickly.
  • mattmanser 4y ago
    Relying on log and print statements is like giving up. I would claim that's not simplicity, that's inexperience, but I have no idea what language you're referring to. Sometimes I do it with JavaScript when I didn't setup the project, it's using a framework I don't know and I'm not willing to spend the time figuring out how to get real debugging working so there are caveats. But you definitely should not be doing that if you have a good debugger as It's faster to click the line to add a break point and press play. You can SEE the state. And you can view other variables at the same time if something's looking whiffy, usually by just hovering your mouse. Plus see the entire call stack. The thing that's boggling my mind about this is that if you know the line to add a log statement on, you know the line to add a breakpoint on. It's so much easier to just add a breakpoint. In some languages if I saw someone adding a log statement while debugging I would immediately classify them as a junior programmer and start teaching them how to debug properly. Either you are using a shitty language with a crap debugger or you need to learn how to use your IDE.
    • 4y ago
• lxe 4y ago
  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...
  • crooked-v 4y ago
    I hated dependency injection until I escaped Javaland and discovered that you could do it with direct interface references instead of four layers of indirection.
• wly_cdgr 4y ago
  This bats 0.950+ Who is this person? They must be a very senior Jedi
  • ntoskrnl 4y ago
    His name is grug.
    • philangist 4y ago
      His name is Robert Grugson
  • palotasb 4y ago
    > grug not like big complex front end libraries everyone use > grug make htmx and hyperscript to avoid https://twitter.com/htmx_org/status/1539713592794169346 https://twitter.com/htmx_org/status/1539713592794169346 https://github.com/bigskysoftware https://github.com/bigskysoftware
• kinbiko 4y ago
  Kevin, is that you?
• DevKoala 4y ago
  > 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.
• bekantan 4y ago
  > 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
• LawnGnome 4y ago
  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/9780731815487 https://www.simonandschuster.ca/books/Grug/Ted-Prior/9780731...
  • ammojamo 4y ago
    Hah! I read the whole thing thinking that of that grug. Which gave it a really odd but lovable vibe in my head. TIL there is more than one Grug.
• maest 4y ago
  > 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.
  • pif 4y ago
    > I'd love to work with a dev who's happy to think about how to most quickly deliver value I'd love to work with a PM who has the courage to engage over a detailed specification document.
  • xupybd 4y ago
    I've been there, so far away from the business use of the product that my solutions focused on the tech. I'm sorry. Now I'm right on the front lines of the business and it's eye opening. I think we need to take time to tech the domain to devs first. It's expensive and won't pay off unless the dev stays on the project for a while but it's the only way to allow the dev to understand what they're trying to do for the business. In reflection I'm wondering if the problem is more that an external consultant is often not aligned with the business. Being directly employed helps with alignment.
    • charlie0 4y ago
      The problem is that most companies don't proactively teach the business side to the devs, I know mine doesn't.
  • TideAd 4y ago
    Do you understand the basic reasons why? Developers are on the hook for bad code and complexity. Rushed code makes feature work take longer, it makes working more irritating, and creates operational work. Everyone is burned by a team that does these things poorly at some point in their career and it drains the life out of you. They need to trust that you'll schedule time to go back and do things correctly. Clean up technical debt, nail down all the requirements, etc.; you don't want to be jumping from MVP to MVP. Maybe you do this well, I don't know. But you need to understand the motivations and incentives of the devs you work with better or you're going to be fighting them constantly.
• sdfhdhjdw3 4y ago
  Too difficult to read, can't be bothered. Does this style really appeal to anyone at all?
  • bigbillheck 4y ago
    I didn't think reading it was very hard at all.
  • JetAlone 4y ago
    It appeals to me, absolutely, because I am familiar with and have a positive impression of the Grug character.
• trwhite 4y ago
  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.
  • pvillano 4y ago
    code can be thought of explaining to a computer what do you want it to do. In general, explaining without managing complexity is easy and makes you look smart. However, explaining so anyone can understand is very hard. Grug author good at this
• dgb23 4y ago
  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.
• dack 4y ago
  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.
  • l5ymep 4y ago
    Complexity doesn't necessarily slow down feature development. In my experience it reduces the project longevity. At some point it will be too big and complex to rewrite all the while more glaring problems emerge and cannot be dealt with.
    • deleted 4y ago
      [deleted]
    • ryanmcbride 4y ago
      If I had a nickel for every time I was hired to rebuild an app from the ground up because it became too complex for anyone to work on, I'd be able to keep up with inflation.
  • dgb23 4y ago
    You mean in the form of books, tech talks, articles and so on? There's plenty of that. But it is usually very technical or about abstract problem solving, sometimes also historical/anecdotal. Things like that. Methodology stuff sometimes comes from people who don't seem to code much at all, or haven't for a long time. I don't really read those things often and when I do I tend to skim them out of boredom. Software design, architecture and paradigms are a mixed bag. There is plenty of distracting stuff there, and much is from people who again, don't code. But there are a bunch of rare gems in this area, even coming from academics/teachers or veterans who haven't been in the trenches for quite a while, but have plenty of useful things to say.
  • danuker 4y ago
• twhitmore 4y ago
  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.
  • strix_varius 4y ago
    I don't know if this is universal, but in my circles "microfrontends" are now all the rage. How do you bring up concerns with that in good faith? It's so obviously terrible that I've no idea where to begin.
    • ryanmcbride 4y ago
      GOD I hate microfrontends. Had a client that had a single, relatively simple application that they wanted as 3 separate angular apps. The reasoning was that they wanted to be able to autoscale them separately? Was unable to convince them that the gains from that would be negligible, especially for an internal tool, and that scaling the whole frontend instead of a single part of it would have virtually no downside since each app was basically a single form, but tons of upsides like less code complexity, easier data persistence, and fewer versioning issues, faster build time. But they didn't care. To this day I don't know what manager was sold so firmly on building 3 apps when one would do, but not my problem anymore.
      • 3np 4y ago
        Could you have done "the monorepo approach" and just have the same code deployed in 3 instances with different `APP_MODE` configuration value or something like that? :P
        • 4y ago
• deleted 4y ago
  [deleted]
• dugmartin 4y ago
  Grug no talk of estimation spirit demon.
• tragomaskhalos 4y ago
  Wise fellow, that grug.
• beaker52 4y ago
  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.
• charlie0 4y ago
  Never before have I read such wisdom. Young grug impressed.
• bpicolo 4y ago
  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
  • strix_varius 4y ago
    For me, that's 50% of it. The other 50% would be: > type systems other most value when grug make wrong, but no user see because big red arrow point to first.
    • bpicolo 4y ago
      The other big one is I think Rust style enums (especially to enable null-safe types) are amazing. Lots of real world problems are solved well by really darn good enums.
      • pvillano 4y ago
        grug hate magic number, magic string
        • bbkane 4y ago
          Rust enums eliminate those (unlike C enums)
• arthurcolle 4y ago
  > 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
  • arthurcolle 4y ago
    These literally just get better and better. > big brain type system shaman often say type correctness main point type system, but grug note 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! grug need start shiney rock deposit ritual for grug similar program shaman so grug has more club. maybe some club have spike or some club have more big size. me no idea what grug need but me know grug need more. me is mere artoo not big brain like grug but me has big sympathy for grug. like grug test shaman make artoo skeptical. like grug artoo wish spread word of grug. grug too is shaman. artoo most good disciple grug.
    • arthurcolle 4y ago
      More > grug warn closures like salt, type systems and generics: small amount go long way, but easy spoil things too much use give heart attack
      • razzimatazz 4y ago
        Definitely saving that, translating it to interview-compatible speak, and springing it on future employers. Actually I need to translate a good 75% of grug's teachings to interview compatible language...
        • yakorevivan 4y ago
          Grug is my spirit animal. I want to meet Grug.
• resters 4y ago
  I can't tell who this article is making fun of.
  • SonOfLilit 4y ago
    not who, what. grug make fun spirit of complexity, but many time grug git blame who summon spirit, see grug summon spirit. grug humility. everyone complexity sometime. grug make fun frontend, put grug write frontend sometime.
  • bauble 4y ago
    People who think simple, easy-to-understand systems are beneath them.
• galaxyLogic 4y ago
  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?
  • zero_shift 4y ago
    grugspeak imply that message self-evident and that complexity is not really in world but invented by badspeakpeople but world is complex, and babytalk is denial
    • galaxyLogic 4y ago
      I am groot
• 5cott0 4y ago
  sometime grugbrain sometime complexitybrain
• abecedarius 4y ago
  cf. 'Grunk' in the very funny Lost Pig: https://pr-if.org/play/lostpig/ https://pr-if.org/play/lostpig/ I skipped most of this post, but the combo of name and writing style seems like a homage.
• phailhaus 4y ago
  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.
• User23 4y ago
  > 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.
• jessemcbride 4y ago
  chef kiss
• lwansbrough 4y ago
  > 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.
• throwaway892238 4y ago
  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.
• rukuu001 4y ago
  How long until you see the first 'grug-brain' t-shirt at your workplace?
  • shmde 4y ago
    Never maybe. People will identify its a modified version of 4chan wojak and cancel Grug.
    • JetAlone 4y ago
      More likely, the creator might recognize that a lot of people who like this kind of stuff have a habit of "hiding their power level" by not buying it and displaying it on their chest. Going ahead and buying that shirt is something like what we used to call the "Silk Screen Goku Shirt" phenomenon, but the newer generation tends to refer to it as "Ahegao hoodie" Syndrome.
  • pvillano 4y ago
    small (optionally 3d printed) caveman on desk, with removable club for small bonks
• osigurdson 4y ago
  >> 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".
• skykooler 4y ago
  This is like if Code Monkey[1] wrote a whole manifesto. [1] https://www.youtube.com/watch?v=v4Wy7gRGgeA https://www.youtube.com/watch?v=v4Wy7gRGgeA
  • throwaway892238 4y ago
    https://pst.klgrth.io/paste/449sp https://pst.klgrth.io/paste/449sp
• alexashka 4y ago
  This is a long winded way of saying we don't know how to write software, so we opt for 'ha ha, funny' instead.
• maxfurman 4y ago
  This might be the best text on programming I've read since Why's Poignant Guide
  • recursivedoubts 4y ago
    this might be the highest complement ever received in the history of hacker news, thank you
• barrysteve 4y ago
  >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.
• deleted 4y ago
  [deleted]
• deleted 4y ago
  [deleted]
• coalpha 4y ago
  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.
• virtualwhys 4y ago
  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 https://twitter.com/plt_hulk
• lynguist 4y ago
  The writing style has the same cadence as the speech of “Uncle Roger” of egg-fried rice fame: https://youtube.com/c/mrnigelng https://youtube.com/c/mrnigelng
• dangerface 4y ago
  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
• deleted 4y ago
  [deleted]
• Tade0 4y ago
  > 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?
  • TremendousJudge 4y ago
    grug brain like pokemon brain: have to forget thing to learn new thing. sometimes old thing useless, sometime old thing very important like bank password
    • pvillano 4y ago
      grug brain tip: password manager. grug only remember one password. even on other computer, grug look up password on phone grug brain tip 2: use grug-brain-compatible password generation algorithm. Grug only need remember algorithm Example: f("hacker news") = "GRUG<3CLUB" + "hand" + "neck" grug invent first part with number and symbol one time. rest change depending on site
• yakorevivan 4y ago
• pvillano 4y ago
  think hard ==> always need think hard think hard about think soft ==> no need think hard all time
• collyw 4y ago
  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.
• JonathanAquino 4y ago
  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-developer-in-yoda-voice.html https://jonaquino.blogspot.com/2022/06/grug-brained-develope...
• jnash 4y ago
  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.