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

The Grug Brained Developer

grugbrain.dev

Post reply on HN
Print view View original

311–320 of 394 posts

Re: The Grug Brained Developer

#311

Post by euroderf »

csours wrote: post #14

Even big brain developer is grug brain when read code later.

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.

Re: The Grug Brained Developer

#312

Post by rovek »

BlargMcLarg wrote: post #198
twhitmore wrote: post #107

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…

>The microservices madness of the past decade is now starting to settle down Meanwhile, I feel it has just started outside SV. Is the remainder of the world just perpetually 5-10 years behind?

Depends what you mean by "the remainder of the world". Most mid-tier companies I've worked at or know people who work at in London started moving on from microservices some time ago. So I guess, unsurprisingly, no.

Re: The Grug Brained Developer

#313

Post by necovek »

dangerface wrote: post #302
timr wrote: post #193

Earlier quoted context omitted.

Hi. Former engineer turned PM here. Wow, you're spinning some wild stereotypes here, and while some are based in truth (as are all good stereotypes), I'm going to take issue with this: > 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 many PMs will _never_ manage expectations with their superiors if…

> Former engineer turned PM here. I think you'r experience as an engineer has biased your view. For example number 3 with your engineering experience you might think that but ultimately it's the engineering team that has to deal with the scaling not you. Your incentives are to scale everything back to meet dead lines while the engineers incentive is to make every thing work so that when it goes live they don't get ca…

As mostly an engineer (though I've spent time as a tech/team lead and engineering manager in the past), I think you've missed the point.

Most of the things will not need to be "scaled" at all. Ever.

As an engineer, I mostly struggle to come up with a simple solution while accommodating all the crappy, leaky abstractions in the rest of the code: that's the hard part of the job. And 20 years in, I still wonder why people think it's smarter to introduce seventeen layers of abstractions for things that have one or at most two implementations, but that's what they do.

Re: The Grug Brained Developer

#314

Post by Nextgrid »

rovek wrote: post #312
BlargMcLarg wrote: post #198

Earlier quoted context omitted.

>The microservices madness of the past decade is now starting to settle down Meanwhile, I feel it has just started outside SV. Is the remainder of the world just perpetually 5-10 years behind?

Depends what you mean by "the remainder of the world". Most mid-tier companies I've worked at or know people who work at in London started moving on from microservices some time ago. So I guess, unsurprisingly, no.

> Most mid-tier companies I've worked at or know people who work at in London started moving on from microservices some time ago

Are we talking about the same London? The market is still flooded with engineering playgrounds and microservices are still considered a perk and bragging point by many companies.

Finding a company with a sane tech stack that doesn't do complexity for the sake of complexity is impossible. It makes sense though - those companies already have their developers, they are happy and the company doesn't need to hire more.

Re: The Grug Brained Developer

#315

Post by discreteevent »

agentultra wrote: post #257
Barrin92 wrote: post #81

Earlier quoted context omitted.

> 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 inh…

I can see where one can build upon that intuition. If one replaces “abstraction” with “indirection” it becomes apparent what is happening. When programs are defined in terms of operational semantics, that is procedurally, it must still be reasoned about in some way if your goal is to write a program so simple there are obviously no errors. Patterns of indirection are not abstractions. It’s a fine practice for control…

> One doesn’t arrive at such an abstraction by writing a bunch of spaghetti code and encapsulating common patterns.

No you don't get an abstraction like the one you described. But you often can hide a huge mess of complex code behind an interface and make it simple for your part of the system to deal with it. e.g. Think of the interface to a search engine or a machine learning system.

> It’s not “simple” because it doesn’t require anyone to learn anything or work hard to understand it. It’s simple because once the abstraction is established and proven you’re free to think about bigger, more interesting ideas.

In many systems there aren't any more interesting ideas and in that case making an abstraction where you work hard to understand it is a liability. People don't have time for that. People particularly don't have time for changing it when the outside world changes such that the abstraction no longer fits. And the outside world changes quite frequently.

Re: The Grug Brained Developer

#316

Post by pif »

maest wrote: post #87

> 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…

> 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.

Re: The Grug Brained Developer

#317

Post by spoiler »

timr wrote: post #193
zero_shift wrote: post #128

Earlier quoted context omitted.

It's a question of incentives and accountability. PMs aren't usually 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 too many PMs will _never_ manage expectations with their superiors if t…

Hi. Former engineer turned PM here. Wow, you're spinning some wild stereotypes here, and while some are based in truth (as are all good stereotypes), I'm going to take issue with this: > 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 many PMs will _never_ manage expectations with their superiors if…

I think some harsh language was used (probably because of frustration), but I think they didn't mean to imply outright _malice_.

More like "incompetence" (eg poor people skills, planning skills, and often lack of technical understanding), followed by shallow human nature which gives in to survival instinct, which generally leads the PM to "blaming developers", so they they don't themselves get in trouble (and a lot of people have problems owning mistakes in general, but that's enough misanthropy for one post).

Also, they don't really _blame_ the developers by point a finger at them and shouting "he did it" like some childish display. They try to soften the blow (humans usually try to be decent; we just can't agree what decent is always) by adding an adversary into the story (like the technical debt, or hidden complexity).

Edit: Forgot to address this, but talking to a PM can often backfire, because you need exceptional interpersonal skills to have difficult those kinds of conversations with a PM. And if they're insecure and take it the wrong anyway, they can make you even more miserable.

Re: The Grug Brained Developer

#318

Post by Chris2048 »

timr wrote: post #253
bb88 wrote: post #240

Earlier quoted context omitted.

> Anyway, it might be good to talk to your PMs and not assume they're evil villains. I've always thought PM's to be more or less aliens with a ray gun tapping at their watch. Communicating with them goes nowhere since they don't empathize with your point of view. The only thing they're concerned with is when something's going to get done. The only form of motivation is threat of existence in the company. > While I've…

I've been the guy who gets called at 4am when postgres takes a dump. I've also been the guy doing the calling (well, not really as a PM, since again, we don't generally have the ability to tell anyone what to do at 4AM , but I digress.) > Communicating with them goes nowhere since they don't empathize with your point of view. Can't speak for everyone, but again, I've been on both sides of the table, and I've never se…

> I've never seen an example of this

Without knowing what your experiences are, as context, it's not possible to see the value in this. How many places (for how long) did you work as a dev?

Re: The Grug Brained Developer

#319

Post by juki »

residualmind wrote: post #218
mattmanser wrote: post #98

Earlier quoted context omitted.

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…

Some debuggers take longer(1-3 secs) to spin up than it takes me to add a print, compile and run and see my theory confirmed or not. If I want a debugger and see e.g. the complete variable scope at a breakpoint, I'll use a debugger. If I just want a very quick sanity check I'll use a simple print. Once you enter debugger land you're there. When I'm currently not in the debugger but rather compiling and executing "for…

> You have to step through the breakpoints, right?

This seems to be a common misunderstanding, but debuggers generally also support logpoints (print statements that you can add/remove on the fly without having to close, compile and restart the application).

Re: The Grug Brained Developer

#320

Post by collyw »

thaneross wrote: post #283
zero_shift wrote: post #128

Earlier quoted context omitted.

It's a question of incentives and accountability. PMs aren't usually 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 too many PMs will _never_ manage expectations with their superiors if t…

It's almost like there might be better alternatives than command-and-control structures when building software.

We are doing a democratic design by committee. I am fairly sure that will work out worse in most cases.
Post reply on HN