Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Grug Brained Developer (2022)

grugbrain.dev

Post reply on HN
Print view View original

101–110 of 603 posts

Re: The Grug Brained Developer (2022)

#101

Post by [deleted] »

jiggawatts wrote: post #76
djeastm wrote: post #65

Earlier quoted context omitted.

>I keep trying to explain this to tiny dev teams I'm curious what role you have where you're doing this repeatedly

The customer is a government department formed by the merger of a bunch of only vaguely related agencies. They have “inherited” dozens of developers from these mergers, maybe over a hundred if you count the random foreign outsourcers. As you can imagine there’s no consistency or organisational structure because it wasn’t built up as a cohesive team from the beginning. The agencies are similarly uncoordinated and will…

[deleted]

Re: The Grug Brained Developer (2022)

#102

Post by tayo42 »

dgb23 wrote: post #45
12_throw_away wrote: post #11

This has by far the best discussion of the visitor pattern I've yet to come across.

I don't work in typical OO codebases, so I wasn't aware of what the visitor pattern even is. But there's an _excellent_ book about building an interpreter (and vm) "crafting interpreters". It has a section where it uses the visitor pattern. https://craftinginterpreters.com/representing-code.html#the-... I remember reading through it and not understanding why it had to be this complicated and then just used a tagged u…

What do you mean by tagged union? And how does it make the visitor pattern not needed?

Re: The Grug Brained Developer (2022)

#103

Post by dkarl »

default-kramer wrote: post #95
anthomtb wrote: post #13

So many gems in here but this one about microservices is my favorite: grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

I'm convinced that some people don't know any other way to break down a system into smaller parts. To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.

That's what I've observed empirically over my last half-dozen jobs. Many developers treat decomposition and contract design between services seriously, and work until they get it right. I've seen very few developers who put the same effort into decomposing the modules of a monolith and designing the interfaces between them, and never enough in the same team to stop a monolith from turning into a highly coupled amorphous blob.

My grug brain conclusion: Grug see good microservice in many valley. Grug see grug tribe carry good microservice home and roast on spit. Grug taste good microservice, many time. Shaman tell of good monolith in vision. Grug also dream of good monolith. Maybe grug taste good monolith after die. Grug go hunt good microservice now.

Re: The Grug Brained Developer (2022)

#104

Post by vermilingua »

jiggawatts wrote: post #76
djeastm wrote: post #65

Earlier quoted context omitted.

>I keep trying to explain this to tiny dev teams I'm curious what role you have where you're doing this repeatedly

The customer is a government department formed by the merger of a bunch of only vaguely related agencies. They have “inherited” dozens of developers from these mergers, maybe over a hundred if you count the random foreign outsourcers. As you can imagine there’s no consistency or organisational structure because it wasn’t built up as a cohesive team from the beginning. The agencies are similarly uncoordinated and will…

Is this DCS in NSW? If so that would explain so much about my own work interactions with them.

Re: The Grug Brained Developer (2022)

#105

Post by Sparkyte »

OMG is that the technical name for my development style? I'm not like super deep in technobabble since there are so many coined names and references that it is nearly impossible to assign the correct one.

Grug brained dev I am I guess.

Re: The Grug Brained Developer (2022)

#107

Post by demosthanos »

default-kramer wrote: post #95
anthomtb wrote: post #13

So many gems in here but this one about microservices is my favorite: grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

I'm convinced that some people don't know any other way to break down a system into smaller parts. To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.

> To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.

I think this is correct as an explanation for the phenomenon, but it's not just a false perception on their part: for a lot of organizations it is actually true that the only way to preserve boundaries between systems over the course of years is to stick the network in between. Without a network layer enforcing module boundaries code does, in fact, tend to morph into a big ball of mud.

I blame a few things for this:

1. Developers almost universally lack discipline.

2. Most programming languages are not designed to sufficiently account for #1.

It's not a coincidence that microservices became popular shortly after Node.js and Python became the dominant web backend languages. A strong static type system is generally necessary (but not sufficient) to create clear boundaries between modules, and both Python and JavaScript have historically been even worse than usual for dynamic languages when it comes to having a strong modularity story.

And while Python and JS have it worse than most, even most of our popular static languages are pretty lousy at giving developers the tools needed to clearly delineate module boundaries. Rust has a pretty decent starting point but it too could stand to be improved.

Re: The Grug Brained Developer (2022)

#108

Post by jongjong »

I used to be against complexity and worried about such narratives making fun of people who tried to avoid it but now I'm grateful. If software developers didn't have such strong biases in favor of complexity, LLMs would probably be producing really high quality code and have replaced us all by now... Instead, because the average code online is over-engineered, un-reusable junk, their training set is a mess and hence they can only produce overengineered junk code. Also, this may provide long term job safety since now LLMs are producing more and more code online, further soiling the training set.

Re: The Grug Brained Developer (2022)

#109

Post by pixelatedindex »

magarnicle wrote: post #99

I know, I get it, but I've realised that I'm not actually grug-brained. The way my brain works, I remember things pretty well; I like to get into the details of systems. So if more complexity in the code means the app can do more or a task is automated away I'll make the change and know I'll be able to remember how it works in the future. This doesn't mean OP is bad advice, just make a conscious decision about what t…

The knowing how it works in the future should really just be comments, right? And if it’s a bit more complex, perhaps a markdown file in a docs folder or stuffed in a README? When working with a large enough organization, tribal knowledge is an invisible t-rex

Re: The Grug Brained Developer (2022)

#110

Post by [deleted] »

PaulHoule wrote: post #2

Content 1, Style 0 Thinking you are too smart leads to all sorts of trouble, like using C++ and being proud of it. If you think your intelligence is a limited resource however you'll conserve it and not waste it on tools, process and the wrong sort of design.

[deleted]
Post reply on HN