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

61–70 of 201 posts

Re: The Grug Brained Developer (2022)

#61

Post by recursivedoubts »

JamesLeonis wrote: post #53
pjs_ wrote: post #22

OK I reckon everyone is going to get on the HTMX wagon over the course of the next few months, and it's going to blow a ton of young minds and save a huge amount of global energy and make a lot of people very happy. And then these same inquisitive young people are going to click enough links on htmx.org that they stumble across hyperscript and it's gonna be like that moment in Dusk till Dawn where the vampires come o…

> And then these same inquisitive young people are going to click enough links on htmx.org that they stumble across hyperscript and it's gonna be like that moment in Dusk till Dawn where the vampires come out I laughed at this, then I checked. _="on load wait 5s then transition opacity to 0 then remove me" Oh no! _="on htmx:error(errorInfo) fetch /errors {method:'POST', body:{errorInfo:errorInfo} as JSON} " Oh No!

it gets so much worse, trust me, i created it

Re: The Grug Brained Developer (2022)

#63

Post by BD103 »

kirse wrote: post #37
pjs_ wrote: post #22

OK I reckon everyone is going to get on the HTMX wagon over the course of the next few months, and it's going to blow a ton of young minds and save a huge amount of global energy and make a lot of people very happy. And then these same inquisitive young people are going to click enough links on htmx.org that they stumble across hyperscript and it's gonna be like that moment in Dusk till Dawn where the vampires come o…

everyone is going to get on the HTMX wagon This is an infinite cycle with JS though. Someone tired of JS complexity writes a simple JS lib (SJSLib), SJSLib attracts people for simplicity, SJSLib grows complex because it has to support all the web things, someone tired of SJSLib complexity writes a simple JS lib... I say this as someone who started with raw JS and fought IE5/6 for years, jQuery then saved us all, skip…

Obligatory Vanilla JS link: http://vanilla-js.com

Re: The Grug Brained Developer (2022)

#66

Post by luxuryballs »

jongjong wrote: post #6

It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…

I think sometimes I’m just trying to be lazy, ironically enough. Rather than just write a bunch of these classes, I’ll just make an abstract one… grug create many new problem to help solve problem

Re: The Grug Brained Developer (2022)

#67

Post by jakelazaroff »

lucasyvas wrote: post #58
hudon wrote: post #56

Earlier quoted context omitted.

> smart people are naturally attracted to complexity like moth to a flame I think the general inclination here towards static typing is due to this, rather than any evidence that statically typed languages lead to higher quality software. Engineers just love puzzles. I'm also looking at you, Rustaceans... runs for his life

I don't agree with this - types do not imply abstractions, and simple types make simple code. Every tool has the potential to be misused in accidental complexity.

I don't know, man — I see a lot of TypeScript developers who lean hard into generics (I am occasionally one of them).

Re: The Grug Brained Developer (2022)

#68

Post by JauntyHatAngle »

Trasmatta wrote: post #18
jongjong wrote: post #6

It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…

> The developer's incentive to maximize their own lock-in factor and billable hours are powerful forces. In my experience these are rarely, if ever, the reasons for over engineering.

I never though so either, but then I worked at a place that had a stale product, product teams powerless and developers rejecting most features/writing random code all the time.

It took me a month to realise that the staff developers very much revelled in and protected their bad code and bizarre domain choices.

It was so far gone that there was no way to get rid of them and the product was just slowly dying and burning the remaining cash.

Then the mergers happened and they all got let go, only retaining the name for brand power and the entire stack was quietly moved over to another similar product which was rebranded.

Separately, there were absolutely very large consultancies that had a programming style/rules based on making their implementations difficult to read/modify, needing to call their COE back in to fix their code or add features - with it being very hard to modify. Talking entire codebase structured with ridiculous levels of abstraction and annoying code style. Bad integrations requiring their tooling to work and make sense of etc.

They target traditional orgs where the management just wants to get a project through and then bleed them over years.

Re: The Grug Brained Developer (2022)

#69

Post by arsdragonfly »

Willish42 wrote: post #38
jongjong wrote: post #6

It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…

I'm reminded of that one quote from a letter of some author [paraphrasing, and I've seen it (mis-)attributed to Mark Twain and too many people to look the real quote up] "Apologies for the length, I did not have time to write a shorter letter". EDIT: I ironically wrote way too long here. Grug say better: > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in ch…

[dead]

Re: The Grug Brained Developer (2022)

#70

Post by neilv »

Trasmatta wrote: post #18
jongjong wrote: post #6

It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…

> The developer's incentive to maximize their own lock-in factor and billable hours are powerful forces. In my experience these are rarely, if ever, the reasons for over engineering.

Lock-in factor and billable hours can be motivations for contractors.

But, for contemporary software developers in general, I'd guess more often it's either resume-driven development (e.g., add the big complex new framework keyword to your resume) or not yet having enough experience to know what complexity is worthwhile for a situation.

Post reply on HN