I can't tell who this article is making fun of.
The Grug Brained Developer
141–150 of 394 posts
Re: The Grug Brained Developer
#142Love 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.
Re: The Grug Brained Developer
#143> 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…
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.
Re: The Grug Brained Developer
#144Nice 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?
Re: The Grug Brained Developer
#145As 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…
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]
Re: The Grug Brained Developer
#146Grug 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
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.
Re: The Grug Brained Developer
#147> 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…
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 t…
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.
Re: The Grug Brained Developer
#148Earlier quoted context omitted.
> 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 fi…
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-intent…
I think a loop is ok if it only modifies variables whose scope is the loop.
And that's what map() basically does.
Re: The Grug Brained Developer
#149sometime grugbrain sometime complexitybrain
Re: The Grug Brained Developer
#150cf. '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.