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

371–380 of 394 posts

Re: The Grug Brained Developer

#371

Post by maest »

jeffparsons wrote: post #157
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 think I have a near-pathological experience of coding these days that just so happens to make me the exact kind of developer you want: 1. I still want to produce excellent code that will deliver value, work predictably, be fast, and be robust against future grugs. I am driven to do this by forces I don't understand myself. 2. I also feel a deep dread of being stuck with a piece of code for any longer than absolutel…

Heh, that's the first time I've heard someone describe this, but I recognise the feeling. It's like constantly rushing and wondering if you're being inefficient and if there isn't a faster way to deliver what you need.

Re: The Grug Brained Developer

#372

Post by bbkane »

pvillano wrote: post #343
bpicolo wrote: post #152

Earlier quoted context omitted.

The other big one is I think Rust style enums (especially to enable null-safe types) are amazing. Lots of real world problems are solved well by really darn good enums.

grug hate magic number, magic string

Rust enums eliminate those (unlike C enums)

Re: The Grug Brained Developer

#373

Post by Aeolun »

michaelcampbell wrote: post #359
Aeolun wrote: post #337

Earlier quoted context omitted.

> Developers (and people in general) are bad at prediction the future. Right now I can safely say that 80% of the times I foresee changes they actually happen. I won’t stop pre-empting stuff for the 20% I get wrong.

It couldn't possibly be that you remember 80% of the things you foresaw that happened vs. the ones that didn't.

I’m fairly certain it’s above 50%, otherwise I wouldn’t have that feeling. 80 just makes for a good number because we were talking about 80/20.

It’s also possible I have a selective memory, but I imagine I’d be a bit different if it often came back to bite me in the ass.

Re: The Grug Brained Developer

#375

Post by jnash »

Developers talk about reducing/avoiding complexity all the time. And yet the very same developers keep making things more complex. I am starting to realize that most developers don't understand what complexity is. So they say crazy things like "microservices are less complex than monoliths". And they actually believe it! When I then step by step show them that microservices are actually objectively more complex than a well designed monolith they agree with every step of my explanation but somehow still don't get it. Very strange.

Re: The Grug Brained Developer

#376

Post by laputan_machine »

dgroshev wrote: post #360
timr wrote: post #355

Earlier quoted context omitted.

Check my profile. I was an engineer for a long time, and I enjoyed it. Been writing code in a professional capacity for multiple decades. I became a PM because I wanted a new challenge while not being totally divorced from making things. It's a harder job, in multiple ways, and one of the things that makes it hard is convincing (mostly junior) engineers that I know what I'm talking about. There are many days when I w…

Thank you for your pushback, seriously. This "us vs them" mentality, especially applied to PMs, is outright toxic and counterproductive. I was blessed to be able to build a team of developers who understand business value and prioritise accordingly, who like building things for others and not just a shrine to their intellect [1], and I wouldn't want to have it any other way. It's amazing to work in a team where most…

"I hate this 'us vs them' mentality, but I need to keep my developers in check and make sure they prioritise business value accordingly"

Is exactly the kind of paternalistic nonsense that developers have to endure.

PMs exist to shield us from the shit. I work with a great one who does this, trusts the team and lets us get on with it without introducing ridiculous process, but the vast, vast majority of PMs I've had to work with are utter garbage.

Re: The Grug Brained Developer

#377

Post by Tade0 »

collyw wrote: post #367
Tade0 wrote: post #351

Earlier quoted context omitted.

That's just React, which both has the highest market share and a culture of following the latest fad combined with piecing together applications from multiple tiny modules(because "it's a library not a framework"). Also jQuery becomes slow and unmaintainable very fast, especially considering that modern frameworks do a lot of tricks to increase performance, like detecting a row swap in a list. Next gen frameworks lik…

Angular is at least as bad. The whole thing is a mess. I miss the days of server side rendering and JQuery.

You can have that today. In fact, 90%+ of the web is exactly this.

I don't miss it though. Especially enterprise apps based on this model are just hell to maintain.

Re: The Grug Brained Developer

#378

Post by dgroshev »

laputan_machine wrote: post #376
dgroshev wrote: post #360

Earlier quoted context omitted.

Thank you for your pushback, seriously. This "us vs them" mentality, especially applied to PMs, is outright toxic and counterproductive. I was blessed to be able to build a team of developers who understand business value and prioritise accordingly, who like building things for others and not just a shrine to their intellect [1], and I wouldn't want to have it any other way. It's amazing to work in a team where most…

"I hate this 'us vs them' mentality, but I need to keep my developers in check and make sure they prioritise business value accordingly" Is exactly the kind of paternalistic nonsense that developers have to endure. PMs exist to shield us from the shit. I work with a great one who does this, trusts the team and lets us get on with it without introducing ridiculous process, but the vast, vast majority of PMs I've had t…

What do you mean "keep in check"? In my experience people caring about the product and value that it brings to the world and having real visible impact on it don't need "keeping in check". It is important to screen for that during interviews, yes, and it won't work in feature factories and bullshit adtech that no one actually cares about, but when it's smart people in a small team working on something generally good for the world it just happens on its own. There is nothing paternalistic about it.

Maybe when it's a large dysfunctional org, yes. Ideally PMs exist to facilitate, not to "shield".

Re: The Grug Brained Developer

#379

Post by NateEag »

galaxyLogic wrote: post #294
NateEag wrote: post #252

Earlier quoted context omitted.

The key to having prototypes and PoCs work out okay is to leave some important piece of UX out entirely. Such an approach gets you the benefits of being able to explore a problem space with code in a quick, sloppy manner, without any risk of anyone actually deploying what you wrote.

That's a great idea. Prototype must look like a prototype

Not even just "look like a prototype" - a prototype must be _incomplete_.

If it's not? You have a solution, so of course it's going to be deployed.

The fact that your solution is gonna fall over due to being brittle code is really unfortunate, but it was avoidable if you'd just built a prototype instead of a product.

Re: The Grug Brained Developer

#380

Post by stnmtn »

bigDinosaur wrote: post #277
koonsolo wrote: post #120

Earlier quoted context omitted.

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.

Webpack is by far the worst tool I've ever used in my development career so far. I never want to see it again, yet using it has allowed me to do things that otherwise would have been a major problem. Something can be useful, but still hideous beyond belief in terms of complexity.

I feel similarly after diving into Terraform for the first time
Post reply on HN