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

191–200 of 394 posts

Re: The Grug Brained Developer

#191

Post by throwaway892238 »

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.

Re: The Grug Brained Developer

#192

Post by bigiain »

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…

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

I've worked with my share of them, but I've also worked with my share orders who'll hack together the quickest possible kludge that meets enough of the requirements to seem to work on the surface.

Interestingly, given the choice, I'd have some of both those types on my team. I really like having the "architecture astronauts" being involved in the very early stage of greenfield projects. Their desire to push the boundaries can help ensure you start off on a great foundation. I also really like having "that guy" who can hack minified javascript and manually deploy it on prod servers to fix a critical bug _right now_ while someone else goes through the "proper process" to get it into the repo and through the CICD...

But you really really need a majority of your dev team who'll take the proper pragmatic approach, or at least who can be cajoled into doing so.

Re: The Grug Brained Developer

#193

Post by timr »

zero_shift wrote: post #128
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…

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 they can harangue developers into overtime, out-of-hours alerts or death marches.

While I've certainly seen incompetent, bureaucratic and/or poorly incentivized PMs, I don't think I've ever met one who wants to throw their developers under the bus to get a job done. I'm not saying it doesn't exist anywhere, ever (big world out there), but you've made a couple faulty assumptions:

1) A PM is not "a middle manager". It's generally a non-management position, despite the title. The classical "PM" has to use soft force for everything, and only gains authority through a history of doing the job well. We're constantly managing expectations in every direction, and "up" is just one more.

2) Even if we were "middle managers", those amongst us who have been working for a while realize it's bad practice to leave a trail of burned-out colleagues behind us, due to a history of bad decision-making.

I'll add a third, specific to my own history:

3) one reason PMs might not "care" about scaling up that database, is that it almost never needs to be scaled. Seriously.

The engineer side of my brain wants to optimize everything. The PM side is always having to remind that side that most of my engineering life was spent in a cycle of useless premature optimization. The war continues.

Anyway, it might be good to talk to your PMs and not assume they're evil villains. And if I'm wrong and you're working in a truly Machiavellian hellhole...you should look around. I hear it's a pretty good job market.

Re: The Grug Brained Developer

#194

Post by codethief »

strix_varius wrote: post #140
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…

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.

Oh lawd, at our client people recently pushed that idea, too. Unfortunately, managers were all on board ("Every team will be able to release autonomously and much faster!!!11") and it became politically impossible to argue for alternatives that won't result in dependency and infrastructure hell. So here we are now, splitting off every single page of a god damn legacy web shop into a separate micro frontend, each of which will be running on a completely different stack (some SPA, some traditional SSR with jQuery), living in a separate repository and with a separate microservice in the backend. But how does one share common UI components, you ask? Well, obviously by enabling Server-Side Includes on the ingress server. Duh.

Re: The Grug Brained Developer

#195

Post by strikelaserclaw »

strix_varius wrote: post #140
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…

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.

microfront ends work well for self contained components that need to be used in multiple pages, they don't even need to have a "separate" backend, as long as there is an area or code file for the backend code that deals with whatever data the microfront end needs.

Re: The Grug Brained Developer

#196

Post by unphased »

zero_shift wrote: post #170
lukasb wrote: post #167

Earlier quoted context omitted.

I'm sorry that you've apparently only worked with bad PMs.

Unfortunately, you don't have to work with bad PMs very often, to occasionally experience a year or more of misery due to their ineptitude. Good PMs are a bit of a paradox. They are immensely impactful and bring value to every project they touch. Yet they are also far overqualified for what is often a thankless job. I also have come to the view that even good PMs will rarely allocate the work that is truly impactful.…

I think it could actually be a pretty good strategy to optimize your job search for the degree to which you might be able to go rogue and get away with it.

Re: The Grug Brained Developer

#197

Post by strikelaserclaw »

koonsolo wrote: post #120
recursive wrote: post #90

Earlier quoted context omitted.

npm, babel, webpack, module compatibility, et al

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.

i think the crux of the matter is to use the right tool for the job once you fought hard not to use that tool. Too many devs see something shiny and want to incorporate it into their workflow somehow, this is what introduces bad complexity, instead you should try very hard not to use something shiny until you realize overwhelmingly that using it would be a net win.

Re: The Grug Brained Developer

#198

Post by BlargMcLarg »

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?

Re: The Grug Brained Developer

#199

Post by recursive »

koonsolo wrote: post #120
recursive wrote: post #90

Earlier quoted context omitted.

npm, babel, webpack, module compatibility, et al

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.

Speed maybe. But stability? Hard to imagine how that stack of build tools is going to provide more stability.

Re: The Grug Brained Developer

#200

Post by residualmind »

deltarholamda wrote: post #186
dack wrote: post #102

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…

I wonder if the key word in there is "company." Modern companies tend to be VC funded monstrosities that onboard a lot of programmers to do things to make VC firms find more seed capital. This selects for complexity, not finished product. We've seen a lot of one-man or small-team companies do some pretty amazing stuff, because usually they are solving a problem that they have. If you're high on VC cash (or are trying…

Thanks, I needed to hear that, be reminded of it.
Post reply on HN