The Grug Brained Developer (2022) • Hacker News Board

Re: The Grug Brained Developer (2022)

#111

Post by Defletter » Tue, Oct 31, 2023, 7:27 AM UTC

lawn wrote: post #96

Trasmatta wrote: post #18

Earlier quoted context omitted.

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

My hobby projects are always over-engineered despite my best efforts. There's absolutely no monetary incentives here so anecdotally I agree with you.

Yup, but it goes both ways. I end up over-eningeering as some feeble attempt to avoid technical debt, only to realise my over-eningeering /is/ the technical debt. Or I end up with relatively simplistic / specialised code that needs an entire rewrite and migration process any time something is added. Either way, it's a bunch of rewritten code mixed with paralysing anxiety about writing bad code.

Re: The Grug Brained Developer (2022)

#112

Post by gofixurcode » Tue, Oct 31, 2023, 7:29 AM UTC

lartin_muther wrote: post #65

ok. so grug make good, good point. many good point. now say others no listen and do opposite of what grug say for month after month. code complex. code very complex what grug do now

grug sad. grug make complexity demon more power. grug look at code. complexity demon look back. grug raises club. grug factor. complexity demon no more. grug tired. grug sleep.

Re: The Grug Brained Developer (2022)

#113

Post by gofixurcode » Tue, Oct 31, 2023, 7:32 AM UTC

dartos wrote: post #13

jiveturkey wrote: post #8

very hard to read, but worth it

Easy read. This grug turn off brain. Only grok from page for this grug.

big brain is not use brain make brain read grug.

Re: The Grug Brained Developer (2022)

#114

Post by juliangmp » Tue, Oct 31, 2023, 7:33 AM UTC

>sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice

grug speak only true

Re: The Grug Brained Developer (2022)

#115

Post by brettermeier » Tue, Oct 31, 2023, 7:36 AM UTC

jiveturkey wrote: post #8

very hard to read, but worth it

Some sentences are, but the whole thing is a pleasure to read, I really enjoyed it :)

Re: The Grug Brained Developer (2022)

#116

Post by brettermeier » Tue, Oct 31, 2023, 7:44 AM UTC

This is my favourite read this year I think :D

Re: The Grug Brained Developer (2022)

#117

Post by jongjong » Tue, Oct 31, 2023, 7:49 AM UTC

lawn wrote: post #96

Trasmatta wrote: post #18

Earlier quoted context omitted.

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

My hobby projects are always over-engineered despite my best efforts. There's absolutely no monetary incentives here so anecdotally I agree with you.

I also did a lot of hobby projects and open source work. Still, in my early career, I was over-engineering everything including my own hobby projects. I think I was trying to put my signature on the work and I unwittingly achieved this through unnecessary complexity.

I was thinking of good code as something I had to invent, but now I feel like it's more like something I have to discover.

Re: The Grug Brained Developer (2022)

#118

Post by barrysteve » Tue, Oct 31, 2023, 7:54 AM UTC

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…

Electronics can absorb superhuman levels of code complexity, without protest or guardrails.

At least STEM subjects are tested against repeatable natural phenomena or mathematic validation.

A CPU is indifferent to you complexifying yourself, ad infinitum. It didn't have to be like that.

Re: The Grug Brained Developer (2022)

#119

Post by danjac » Tue, Oct 31, 2023, 8:02 AM UTC

lawn wrote: post #96

Trasmatta wrote: post #18

Earlier quoted context omitted.

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

My hobby projects are always over-engineered despite my best efforts. There's absolutely no monetary incentives here so anecdotally I agree with you.

My tendency now is to aim for over-simplicity in hobby projects. I already have to deal with over-engineered garbage at work I have no choice but to accept, so I don't want to bring those headaches home.

Re: The Grug Brained Developer (2022)

#120

Post by cjfd » Tue, Oct 31, 2023, 8:34 AM UTC

hudon wrote: post #56

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…

> 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

This is a very simplistic approach to simplicity. Simplicity is not just counting the number of characters you see. A function in a statically typed language may have a signature that says 'it takes an integer and returns an integer'. That is very simple. A function in a dynamically type language says 'this can take something, anything really, and returns something, anything, really. That is very complicated and unspecified even if it takes a few characters less to type.