[HN Gopher] The Grug Brained Developer
___________________________________________________________________
The Grug Brained Developer
Author : huimang
Score : 393 points
Date : 2022-06-22 19:00 UTC (3 hours ago)
(HTM) web link (grugbrain.dev)
(TXT) w3m dump (grugbrain.dev)
| sovietswag wrote:
| > 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....
| twhitmore wrote:
| 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 wrote:
| 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.
| charlie0 wrote:
| Never before have I read such wisdom. Young grug impressed.
| whiddershins wrote:
| > Microservices
|
| grug wonder why big brain take hardest problem, factoring system
| correctly, and introduce network call too
|
| seem very confusing to grug
|
| >
|
| Yes.
| tharax wrote:
| This is perhaps the most succinct way I've ever seen this
| expressed. Agree 100%.
| tines wrote:
| 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? :)
| crooked-v wrote:
| On the other hand, I'd be interested in seeing a 'ten hundred
| most common words' version of it that dumps those complicated
| words like 'refactor'.
| bitwize wrote:
| This reminds me rather of a cross between "Code Monkey"
| (Jonathan Coulton song) and Film Crit Hulk Smash.
| egypturnash wrote:
| 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.)
| andrepd wrote:
| grug think grugposting is part of the charm
| layer8 wrote:
| Grug thinks there would be middle course keeping most of
| charm but less exhausting to read.
| manmal wrote:
| Exhausting make grug read more slowly and parse well.
| raphlinus wrote:
| I might be willing to give this a shot. I appreciated the charm
| and humor in the original, but especially for readers who don't
| have English as a first language it probably gets in the way of
| the message.
| jstanley wrote:
| > 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.
| bekantan wrote:
| > 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 wrote:
| Australians of a certain age might have a different (yet not that
| different) take on the Grug brain:
| https://www.simonandschuster.ca/books/Grug/Ted-Prior/9780731...
| bpicolo wrote:
| 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 wrote:
| 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.
| kazinator wrote:
| 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 wrote:
| 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!
| whiskeytuesday wrote:
| > 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 wrote:
| Grug state Chesterton's fence very easy understand way.
| odipar wrote:
| 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 wrote:
| 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
| beckingz wrote:
| Now we add GRUG to KISS and YAGNI.
| arthurcolle wrote:
| > 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
| bfung wrote:
| 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>
| whoomp12342 wrote:
| this is nothing short of amazing
| TranquilMarmot wrote:
| 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 wrote:
| 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?
| resters wrote:
| I can't tell who this article is making fun of.
| arbenpurben wrote:
| This makes me so happy
| MrPatan wrote:
| "deserve of club but heart in right place"
|
| I love it.
| cubano wrote:
| 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!
| planarhobbit wrote:
| Horseshoe theory right once again: Grug and 100x'er megaminds are
| aligned, and the midwits are over complicating and
| underperforming.
| phailhaus wrote:
| 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.
| [deleted]
| elwell wrote:
| Basically "Simple Made Easy"
| maest wrote:
| > 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.
| TideAd wrote:
| 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.
| devmunchies wrote:
| > Rushed code makes feature work take longer
|
| grug say nothing of "rushed code". Grug get sick if grug
| drinks from dirty water, even if it is closer than walking to
| clean water. Rushed code and dirty water hurts Grug.
|
| But that not mean that Grug needs to dig a trench to clean
| water, or build wall like beaver to get more clean water, it
| hurts Grug's back. Grug just walk to clean water when Grug is
| thirsty.
|
| Grug dig canal to clean water before, and Grug need to always
| keep canal clean and me not able to hunt for food because me
| digging new holes. One time, chief said village need to move
| to other side of mountain. Grug said goodbye to canal and my
| beaver wall. Grug should not built them.
| verve_rat wrote:
| 100% A bad code base is a mental health hazard, and that shit
| hurts. Of course time crunch isn't the only thing that makes
| a bad code base. Devs bike shedding to much, or just not
| being good at maintaining a code base can have the same
| effect, but not having the time to protect your own future
| mental health really starts to weigh on a workplace.
| ornornor wrote:
| You nailed it.
| riazrizvi wrote:
| The difference is mostly a result of perspective, that could be
| fixed. The PM has the use cases and product gestalt, if this
| was shared and made the environment in which the devs work,
| their prioritizing shifts to product, and engineering concerns
| would be limited to more obvious ones that make sense.
|
| But it's human nature to protect one's job and decision making
| autonomy. PMs being no exception, often underweight their roles
| in communication transfer and overweight them in decision
| taking.
| [deleted]
| goodoldneon wrote:
| It's a balance. As an engineer, I'm constantly dealing with the
| consequences of a "the feature worked so we shipped" mindset.
| Churning out features without thinking about architecture
| creates increasing amounts of code "tangle" that gradually
| slows down feature dev. On the flip side, thinking too much
| about architecture slows down feature dev
| galaxyLogic wrote:
| You have the right insight I think. The thing about putting
| lots of effort into "refactoring" is that the code you refactor
| may actually not end up in the product at all.
|
| I think "prototyping" is better than "refactoring". Prototyping
| basically means that you write your app more than once. On the
| 2nd round you know what needs to be there and what not. You may
| have come up with a much better much simpler design for the
| whole system when you know what needs to be there and what it
| needs to do.
|
| Code-quality is important no doubt, but it is not important for
| code that doesn't end up in the final product.
| lmarcos wrote:
| That's because such developers know that they won't have to
| maintain such code. They will probably be gone (switch to
| another company) in 1 or 2 years.
| jbreckmckye wrote:
| It's a question of incentives and accountability.
|
| PMs aren't accountable when their shortcuts come and bite the
| team further down the line. Developers feel the pain instead.
|
| PMs won't be honest with the business that they sold an
| undercooked product. Need to suddenly scale up that
| "pragmatically" designed database? I know in my heart that you
| will almost _never_ manage expectations with your superiors if
| you can harangue developers into overtime or death marches.
| "Who could have guessed this could happen?"
|
| Don't take that personally. It's just the way incentives are
| structured for middle managers. By the time the problems of
| your "pragmatic" architecture have emerged, your typical PM /
| EM / team lead will either be working on another team, doing
| another job, or talking about "tech debt" as "just one of these
| things", a mysterious natural force, visiting your team
| stochastically like a freak summer snowstorm or an outbreak of
| measles.
|
| _That_ is why developers are cautious. Do you _seriously_ think
| that you are the only person in your team who understands
| "commercials" or "cost benefit analyses"? Experienced
| developers do, which is why we've learned the best strategy in
| the long run is to avoid offering concessions to people without
| any skin in the game.
| xupybd wrote:
| 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 wrote:
| The problem is that most companies don't proactively teach
| the business side to the devs, I know mine doesn't.
| galaxyLogic wrote:
| 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?
| going_ham wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| nwatson wrote:
| You can't run a system handling real money or real medical
| records in a debugger. Or if you are, you're violating a
| bunch compliance standards and will get sued into oblivion.
| going_ham wrote:
| It totally depends on the case at hand!
|
| I use debugger all the time when I run into pointer related
| issue, or some checking some tensors in deep neural nets etc.
|
| In some cases, I throw debugger just to see what is going on.
|
| However, I have had few cases where debugger slowed me down.
| If you are doing something in graphics that requires you
| debugging issues that spans multiple frames, sometimes it's
| easier to notice the value over a period of time and see why
| things are behaving that way. From there you can reason what
| might be causing the issue. It can be done frame per frame
| inserting multiple breakpoints, recording them and viewing
| them accordingly! However, I prefer simple logs in such
| cases.
|
| I have used both approaches as time demanded.
| iamthepieman wrote:
| If I set a breakpoint somewhere and it ended up being a
| location that was useful, that's usually a good place for a
| log statement.
|
| As for your point about logging being a fail condition, I was
| working on a distributed system where I had no control over
| which instance my code was running on. I would attach a
| debugger and make the same request a dozen times before the
| instance I had attached the debugger to processed the
| request. This wasn't a system I could setup a local instance
| of. I also couldn't reduce the instances to a single one
| because there were other devs, testers, data engineers
| working on it and the system did raster processing that
| regulary took 1-5 minutes. I resorted to log debugging.
| IsopropylMalbec wrote:
| You are not able to, or at least should not be able to debug
| your code in production. More than likely all you will have
| is your logs.
| nerdponx wrote:
| Printf bad, log good. Grug already have logging in app. Grug
| use logging, Grug no reinvent logging with printf.
| ath3nd wrote:
| This. Is. Pure. Gold!11
| jamal-kumar wrote:
| smol brain can dodge [1]
|
| [1]
| https://preview.redd.it/g1lpdmt1iiv51.jpg?auto=webp&s=a5f27c...
| 5cott0 wrote:
| sometime grugbrain sometime complexitybrain
| GrumpyNl wrote:
| That's a great write up.
| lxe wrote:
| 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 wrote:
| 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.
| csours wrote:
| Even big brain developer is grug brain when read code later.
| sdfhdhjdw3 wrote:
| Too difficult to read, can't be bothered.
|
| Does this style really appeal to anyone at all?
| bigbillheck wrote:
| I didn't think reading it was very hard at all.
| tragomaskhalos wrote:
| Wise fellow, that grug.
| abecedarius wrote:
| cf. 'Grunk' in the very funny Lost Pig: https://pr-
| if.org/play/lostpig/
|
| I skipped most of this post, but the combo of name and writing
| style seems like a homage.
| dugmartin wrote:
| Grug no talk of estimation spirit demon.
| mcbishop wrote:
| that grug say many variables good. make this grug many happy.
| layer8 wrote:
| put explicit type on variable even more good for read code
| throwawayacc2 wrote:
| Grug no read good but grug fink is good advice here
| wly_cdgr wrote:
| This bats 0.950+
|
| Who is this person? They must be a very senior Jedi
| palotasb wrote:
| > 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://github.com/bigskysoftware
| ntoskrnl wrote:
| His name is grug.
| philangist wrote:
| His name is Robert Grugson
| smm11 wrote:
| I sense a certain age-range here.
| recursive wrote:
| grug sense a certain age range in comment
| genjipress wrote:
| You've heard of Film Crit Hulk? Here's Software Dev Hulk.
| trwhite wrote:
| 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.
| dgb23 wrote:
| 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.
| pawelduda wrote:
| > grug has never used erlang, hear good things, but language look
| wierd to grug sorry
|
| maybe grug try drink elixir?
| nathias wrote:
| complexity isn't bad, redundant complexity is
| [deleted]
| dack wrote:
| 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.
| dgb23 wrote:
| 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.
| l5ymep wrote:
| 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]
| dusted wrote:
| 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.
| agentultra wrote:
| 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.
| keerthiko wrote:
| > a giant mud-ball of for-loops, while-loops, variable
| assignments, and other wonderful side effects.
|
| Woah woah. This is literally the kind of complexity grug wants
| to avoid. Simple doesn't mean using the fewest language
| features or keywords, it means simple to read, follow along,
| reason about, and debug. Abstractions can aid in that (like
| using a third party library!), until they are
| imported/implemented aspirationally and thus often
| unnecessarily, and sometimes resulting in abstractions for
| abstractions, selective application of the abstractions vs
| fresh implementation, etc (...and thus AWS)
|
| At no point does grug argue that you should stick to what you
| know, he just says you should trap your complexity in crystals
| ie literally suggesting to use the Good Abstractions, When They
| Make Sense.
| kazinator wrote:
| Software in category (1) and (2) can be of any relative size.
|
| 1 could be 50,000 lines, 2 could be 500.
| coldtea wrote:
| > _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_
|
| And both are neither here, nor there, regarding what the
| article talks about, which is basic advice that always holds:
| avoid complexity, say no whenever possible, opt for 80/20
| solutions.
|
| > _One thing that escapes "grug" is that achieving 1. often
| requires more sophistication than their magical club allows._
|
| Which is irrelevant to grug's point, as he doesn't pretend to
| advocate achieving 1.
| nonethewiser wrote:
| You're focusing on coding style but it sounds more like hes
| talking about business requirement.
|
| If we are talking about coding style, then the things you have
| identified as actually not simple are by definition not what
| the article favors.
| Barrin92 wrote:
| > Instead of addressing complexity head-on with abstraction,
| "grug" will beat "galaxy brain" over the head.
|
| the argument made in the piece is more nuanced than that. The
| author points out that you often _cannot_ address complexity
| head on (in particular not with abstraction), because you don
| 't even know what your complexity looks like, as the author
| says, complexity isn't trivial to see.
|
| This was the old problem of inheritance as a paradigm which
| tried to anticipate structure of programs and code when often
| you can't anticipate what shape your program is going to take,
| often leaving you in dead ends and wrong hierarchies or
| taxonomies.
|
| The author isn't saying to not abstract at all but to not do it
| early. Casey from Handmade Hero had a similar style he called,
| IIRC 'compression' based programming, implying that you write
| your code, and as you go over it again and again you see where
| duplication pops up and only then you factor it out into some
| higher abstraction.
| geekbird wrote:
| This. Develop the logic and flow for all of the thing, make
| it big, code it simple and even redundant, but really basic
| and simple. That's your "proof of concept". Pass two is
| finding and factoring out all of the redundant stuff into
| functions and libraries, grouping like with like. It's like
| in relational database design - first you grab all the fields
| needed, then group them and normalize them.
| ImprobableTruth wrote:
| I think the post actually touches on this? It doesn't say that
| you shouldn't abstract, just don't abstract too early.
| shams93 wrote:
| Then there's the Super Mario developer, I putta all 50,000,000
| lines of code into one a fantastic pasta bowl file just for a
| you!
| frostwarrior wrote:
| That's the classic "only coder" mindset. Instead of being
| uncomfortable learning about software architecture, side
| effects or even pure functions, tries to solve every problem
| with for and while loops.
| WesolyKubeczek wrote:
| Sir, may I remind you that when you get down to it, your
| architecture and higher order functions are all made of
| branching and for and while loops, and branching and for and
| while loops are all made of goto.
| vnorilo wrote:
| And gotos are made of jump instructions which are made of
| NAND gates, transistors and silicon. Good abstraction is
| all about hiding the details that are not essential to the
| problem at hand.
| WesolyKubeczek wrote:
| I wanted to say jump instructions at first, but gotos are
| more hated and considered harmful in these quarters.
|
| You hide the details but you never forget they're there,
| lest they spoil and start smelling really bad.
|
| (Also, apparently the MOV instruction on amd64 gives you
| Turing completeness as proved by that crazy compiler, so
| gotos may be made of MOVs sometimes, but meh)
| lmm wrote:
| A particular _implementation_ might use those things, and I
| will meet it on its terms when I need to. But that 's a
| mechanical convenience, nothing more. My top-level code is
| written for people to read, and only incidentally for
| machines to execute.
| recursivedoubts wrote:
| ^ 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 wrote:
| titzer wrote:
| Undoing someone's copy-pasted for-loops and while-loops is
| called "factoring" and undoing someone's bad abstractions is
| called "re-factoring" and is about 10x as slow. At this point
| in my career I have seen _way more_ crappy abstractions and
| needlessly abstracted code than grug-brain code.
|
| And, to be brutally honest, as much as I love those functional
| combinators, first-class functions, streams, etc, they suck to
| reason about.
|
| Sometimes loops are better!
| lmm wrote:
| > And, to be brutally honest, as much as I love those
| functional combinators, first-class functions, streams, etc,
| they suck to reason about.
|
| > Sometimes loops are better!
|
| That I think is backwards. A loop could be doing literally
| anything - it probably _is_ futzing with global variables -
| so there 's no way to reason about it except by executing the
| whole thing in your head. A map (or mapA) or a fold (or
| foldM) or a filter or a scan is much more amenable to
| reasoning, since it's so much more specific about what it's
| doing even without looking at the body.
| andyferris wrote:
| I like to write loops where they follow the functional
| map/filter/reduce paradigm where they don't mutate anything
| except some initial variables you "fold" over (defined
| immediately prior to the loop) and which are treated
| immutable (or uniquely owned) after the loop.
|
| I find this has good readability and by containing the
| mutation you can reason about it "at a distance" quite
| simply since further away it's for-intents-and-purposes
| pure code.
|
| What you might lose are the compiler-enforced guarantees
| that a functional language gives you. Some languages give
| you the best of both worlds - with rust you could put this
| in a pure function (immutable inputs, owned outputs) and
| the borrow checker even reasons about things like this
| within a function body.
| galaxyLogic wrote:
| I think a loop is ok if it only modifies variables whose
| scope is the loop.
|
| And that's what map() basically does.
| philosopher1234 wrote:
| Not true in reality, so your theory must be wrong.
| lmm wrote:
| I've been doing this professionally for over a decade and
| it's been true in my experience, shrug.
| eurasiantiger wrote:
| I think you found the head of the nail, so let me hit it:
|
| "Simple" code is simple to reason about, but it is not as
| expressive.
|
| "Complex" code is just as simple to reason about, but being
| more expressive, it requires more intimate knowledge of the
| language features and abstractions used.
|
| Then there is "bad" code, which is confusing for reasons
| other than domain complexity.
|
| Sometimes complexity just gets handed to a developer even if
| they say no, and that doesn't make their complex code bad
| code.
| stonecolddevin wrote:
| I personally almost always use loops (in Java) unless I know
| the dataset being dealt with is small, unless I'm writing
| stuff in Scala where maps and flatMaps are first class, but
| diving into Scala is its own can of worms.
| joshuamorton wrote:
| I've seen a massive, "simple", abstraction-free function of
| 500-1000 lines take smart engineers _quarters_ to safely
| "factor". I've seen this same thing happen a handful of
| times. Big spaghetti function requires someone to build a new
| test suite from scratch so that they can refactor safely,
| because everything ends up having spooky surprising distant
| effects, because there isn't any abstraction to contain
| things.
|
| They're dead simple, there's no abstraction, its just loops
| and variables (and state, which is the real killer). But
| they're impossible to reason about as a result.
| jjoonathan wrote:
| 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 wrote:
| > 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.
| short_sells_poo wrote:
| Alright I'll bite :)
|
| Python? Java? C? Assembly?
| mgsouth wrote:
| That would make for some interesting posts. "How X promotes
| wishful simplification," for various values of X. I imagine
| some common traits would be probably be "X makes simple
| things simple," with "it makes hard things look like simple
| ones." But there's also "X has defaults that Just Work"
| with "until they don't." I don't think I'd include
| assembly, C, or Java in those categories. Python? Maybe;
| "batteries included" is starting to break down. Go? Yep.
| Goroutines and channels usually work well for simple stuff,
| often for more complicated, and the core libraries follow
| that pattern. Model failures tend to be buried and solved
| when the service is turned off and back on. Rust? Don't
| think so; its schtik is making hard things into blockers.
| Web frameworks? Yes, oh very yes. Lisp? "Simple? Blink
| blink. Oh, you mean elegant."
| kapp_in_life wrote:
| My guess would be Go since I've heard that as a common
| complaint.
| bityard wrote:
| Not who you're replying to, but Tcl was that language for
| me. Dead-simple syntax, documentation, and behavior. I
| loved it. But also dead-simple tools. And if you wanted to
| do anything that wasn't a "solved problem" already, you had
| to write your own library.
|
| When I switched my focus to Python, everything was more
| effort but I could also do _much_ more with it.
| lmm wrote:
| Interesting - I found TCL to be very much the opposite,
| because it makes "meta" things so easy. Like, if you want
| to write your own control flow construct, you can go
| right ahead, it's like Lisp except that it's easier to
| write macros.
| dusted wrote:
| > And if you wanted to do anything that wasn't a "solved
| problem" already, you had to write your own library.
|
| For which language is that statement not true ?
| girvo wrote:
| Their point is that the language they're discussing
| requires you to write that library far more often than
| other languages, as a second order effect of few using
| it. But you know that already, you just want to make a
| semi-snarky reply instead, I guess.
| dahdum wrote:
| As usual the truth is somewhere in the middle. I've seen nearly
| $1m in development cost and a year of time lost to the
| complexity demon due to big brains playing AWS Service Bingo
| while a competitor hired a single grug to do the same task.
|
| That single grug got it done in ~1 month for basically nothing,
| and without the multiple AWS service overhead it ran much
| faster, fewer resources, and dead simple to maintain. Bigger
| company bought the smaller one, then proceeded to toss the grug
| code and continue the big brained approach, as far as I know
| never reaching parity.
|
| But there were cool network diagrams, data diagrams, and all
| sorts of new, interesting, and complex technology developers
| enjoy playing with.
|
| I'm more inclined to side with grug now.
| joe_the_user wrote:
| The OP's point is that being able to produce a simple
| solution to a complex problem only seems like the product of
| "refusing to be smart" from the outside. From the inside,
| there's always a delicate balancing act - each step involves
| choosing approaches that may generate complexity just in
| different ways. The same data used in different places in the
| application? What do you do? Objects? Globals? Cut-and-paste.
| Any of those solutions might be fully justified or might
| degenerate into a tangle by the time the application is done.
| Once, if you have a nice, simple working application, you can
| say "it's all just 'grug'" but that's essentially what they a
| call "humble brag".
| [deleted]
| pkulak wrote:
| Whoa now, I was with you until you seemed to imply that
| "simple" software means shitty code. Simple in this context
| means a solution with as little complexity as possible.
| Hopefully written elegantly and carefully, with lots of thought
| for future maintenance and readability.
|
| Maybe you use a 10-year-old, constantly maintained and
| thoroughly tested library to do 90% of the work instead of
| writing everything yourself.
|
| Would it be faster to compute some end state without
| intermediate calculations? Probably. But how about we just spin
| a loop forward instead if it's more accurate that way and
| easier to understand.
|
| What if we cached values, then made sure the caches are always
| in sync? That should speed things up. Well, maybe we'll write
| it without caching and see how that goes first.
|
| How about an intricate system of locks and serializable
| transactions so that multiple requests can run at the same
| time? Or maybe we just queue things up and run them one at a
| time.
|
| Nothing to do with nested for loops.
| femiagbabiaka wrote:
| I think of it as being more of a spectrum where abstractions
| get introduced as they're needed. The case where one has
| thousands of lines of imperative code that is terrible to debug
| and probably not unit tested is one where the correct
| abstractions were never introduced at the place and time they
| were appropriate. Getting this right is almost impossible,
| that's why we have refactoring practices.
| jfoutz wrote:
| could you give an example of (1)?
|
| Only because i have run into weirdness with printf calling
| malloc, back in the day. Even hello world makes me a little
| nervous about those claims.
|
| But I'd love to see a sample with explicit assertions about the
| environment, so I could be sure there are obviously no errors.
| emilsedgh wrote:
| > a giant mud-ball of for-loops, while-loops, variable
| assignments, and other wonderful side effects. Instead of
| addressing complexity head-on with abstraction
|
| I very much prefer to work in a codebase of poorly written
| loops and variable assignments rather than one with poor
| abstractions.
|
| Poor abstractions can harm way, way more than spaghetti code.
| Their harm usually spreads out through system.
|
| Imagine this:
|
| * 1 single poorly written function which takes a number of
| inputs and has an output, but internally it's long and messy.
|
| * A bunch of abstracted entities, which interact throughout the
| system, but are poorly designed.
|
| The complexity of 1 is isolated to the implementation. There's
| a nice encapsulation. Removing/Rewriting is easy.
|
| But 2 becomes a complete mess which is not isolated. You'd have
| to skin it layer by layer. Thats way more scary to me.
| [deleted]
| kinbiko wrote:
| Kevin, is that you?
| beaker52 wrote:
| 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.
| armatav wrote:
| 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 wrote:
| > 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 wrote:
| Hehe, good one!
|
| Oh, you're serious? :D
| recursive wrote:
| npm, babel, webpack, module compatibility, et al
| koonsolo wrote:
| You are free to develop everything in vanilla JavaScript
| and run your coded scripts straight in the browser. Very
| non-complex.
|
| But the team that uses npm, babel, webpack etc will crush
| you both on development speed and stability.
| crooked-v wrote:
| The whole CJS/AMD/UMD/ESM nightmare has included some
| prominent devs intentionally breaking packages for certain
| build types because 'ESM has been around for a while, why
| haven't you updated yet?'
| bobkazamakis wrote:
| this is art and all of us should be ashamed.
| DevKoala wrote:
| > 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.
| MrPatan wrote:
| 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.
| TheOtherHobbes wrote:
| 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.
| vlunkr wrote:
| 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.
| pyrolistical wrote:
| Heh, me not grug brained right?
___________________________________________________________________
(page generated 2022-06-22 23:00 UTC)