Live data from Hacker News

The Grug Brained Developer

grugbrain.dev

161–170 of 394 posts

Re: The Grug Brained Developer

#161
post #67

Earlier quoted context omitted.

> frontend Complexity Demon having a grip on the entire industry Is frontend web development more complex than it needs to be? If so, how?

Hehe, good one! Oh, you're serious? :D

If it's so bad, you're welcome to write your applications in vanilla JavaScript, with no shims, in flat files without modules calling 1998 era DOM APIs.

There's a reason most people don't, however.

Re: The Grug Brained Developer

#162
post #54

this grug read article, but author grug big brain, article too long. If article was smaller with less complexity, easier for regular grug to read and remember.

grug read one sentence, grug feel smarter already. grug read next sentence, grug feel smart on different subject. grug hope have one sentence in inbox every day. or maybe little bird chirp sentence at grug. but no complex, just many subject.

Re: The Grug Brained Developer

#163
post #38

Earlier quoted context omitted.

Undoing someone's copy-pasted for-loops and while-loops is called "factoring" and undoing someone's bad abstractions is called "re-factoring" and is about 10x as slow. At this point in my career I have seen way more crappy abstractions and needlessly abstracted code than grug-brain code. And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reaso…

I think you found the head of the nail, so let me hit it: ”Simple” code is simple to reason about, but it is not as expressive. ”Complex” code is just as simple to reason about, but being more expressive, it requires more intimate knowledge of the language features and abstractions used. Then there is ”bad” code, which is confusing for reasons other than domain complexity. Sometimes complexity just gets handed to a d…

> ”Complex” code is just as simple to reason about, but being more expressive, it requires more intimate knowledge of the language features and abstractions used.

> Then there is ”bad” code, which is confusing for reasons other than domain complexity.

I've previously seen these two summarized as "the difference between complex and complicated".

Re: The Grug Brained Developer

#164

I can't tell who this article is making fun of.

not who, what. grug make fun spirit of complexity, but many time grug git blame who summon spirit, see grug summon spirit. grug humility. everyone complexity sometime. grug make fun frontend, put grug write frontend sometime.

Re: The Grug Brained Developer

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

> _THEN_ I want developers from that company to share their opinions about how they do it.

Beware of survivorship bias.

For every successful company using a technique, there might be 10 others using the same technique but running into the ground.

And not sharing the embarassing failure.

Microservices strike me as a pertinent example. It might fit huge companies very well, but not if your customer base might as well be served by a cheap Raspberry Pi.

Re: The Grug Brained Developer

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

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

Re: The Grug Brained Developer

#168

This reads a lot like like commit comments, status reports, e-mails and tickets in a company in which everyone is from a different country from around the globe. If you can't read grug English, you will find it hard to navigate in the global workforce.

Thankfully this is not totally correct. I personally found grug English to be harder to understand/read as a non-native English reader.

Re: The Grug Brained Developer

#169
post #110

Earlier quoted context omitted.

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.

Inheriting someone else's mess can really hurt.

Especially when you are not given the time to improve things. Worse when you're told they've negotiated 20% extra time to clean up, but every estimate gets shortened by more than 20% to please the customer.

Then you're in the firing line when new features don't ship in time and bugs keep popping up everywhere.

It makes you question your ability as a developer. Sapping your motivation to the point where you feel drained even thinking about the next task.

Re: The Grug Brained Developer

#170
post #167

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…

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. Some of the best work of my career has been when I've gone off piste and prototyped something that has surprised my managers or disrupted the way a team thought they had to work.

You can't go rogue often, and you have to expend your political capital carefully. But you will never do the best work of your career waiting for someone to assign you it in JIRA.

Post reply on HN