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

131–140 of 201 posts

Re: The Grug Brained Developer (2022)

#131

Post by bjornsing »

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. Even developers who appear to be totally robotic and ego-less are often guilty of over-engineering. It works on the subconscious mind. Few are ever able to escape the mindset because they are not fully conscious.

I suspect this phenomenon explains a lot about how this industry has developed over the last few decades. Any significant software nowadays requires a team of baby sitters just to keep operating. Nothing is ever done and everything keeps changing for no good reason.

Re: The Grug Brained Developer (2022)

#132

Post by ColonelPhantom »

gemstones wrote: post #104
jauntywundrkind wrote: post #74

Earlier quoted context omitted.

Ah! Carson Gross is author of grug brained developer, and htmx! I'd love to see some real critiques of htmx. Personally I think the web's big ongoing challenge has been figuring out how to update the page well, and we keep trying all kinds of attempts. That causes fatigue, and some of the ideas are wild or grow crufty over time. Htmx seems like a back-reaction, to insist on grug brained less/YAGNI. And even though th…

The best critique of HTMX is the same critique of Rails + partials + a bit of helper JS for inserts (the popular stack that predates modern SPAs.) Say you’re writing a true web app. You’re making a mobile view, and the user has scrolled down and loaded some items (and partially inserted them as the scroll bar has moved down.) They add a card representing a few items to a cart, which 1. changes the look of the card an…

https://htmx.org/examples/update-other-content/

If you need to modify the card and something else, probably using hx-swap-oob is the best approach to update the cart icon.

Re: The Grug Brained Developer (2022)

#133

Post by Mikhail_Edoshin »

If you need nuanced behavior, you need a complex controller. And you always need more nuanced behavior, this is the inherent nature of software development. Sometimes the appearance of simplicity is achieved by making the behavior simpler (e.g. dropping the support for old versions, not implementing parts of the specification, and so on). This is degradation, not simplicity. The right simplicity is an art of having the required complexity yet somehow manage it internally. So complexity is not bad. It is given. What is deficient is our skill.

Re: The Grug Brained Developer (2022)

#134

Post by sesm »

jamil7 wrote: post #121

A lot resonates with this, particularly factoring code and carving out barriers later on when the project has settled. I believe there are some antipatterns like singletons and globals that on the surface look grug-brained but are actually complexity multipliers.

Saying "complexity bad" without giving a definition of complexity is not very meaningful. In reality it means "I'll use my personal judgement and anything I don't like will be marked as complexity".

Rich Hickey gave his own practical definition of complexity and followed it in his design, and sometimes the results are very unintuitive. For example, transducers in Clojure are actually simple (by his definition) because they de-couple transformation from the context. Also, by his definition HTMX approach (aka PJAX, aka HTML-over-the-wire) would be more complex then JSON + client side rendering, because it couples together multiple things: network, routing and rendering.

Re: The Grug Brained Developer (2022)

#135

Post by sanitycheck »

jakelazaroff wrote: post #67
lucasyvas wrote: post #58

Earlier quoted context omitted.

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

When I've seen this (and found myself doing it) it's been because we're trying to do something with TS which we would have done easily in JS.

But the JS function we would have written would have required someone using it to read and understand it, and the TS function (without using 'any') needs to fully express what its inputs and outputs can look like.

Because of this TS actually tends to guide me towards writing more "Grug brained" code, because I refuse to use 'any' (and throw away TS benefits) and using generics usually requires a trip downstairs for a fresh cup of tea.

Re: The Grug Brained Developer (2022)

#136

Post by sanitycheck »

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 don't think it's lock-in or billable hours. I think "staying current and employable" is a much bigger influence on behaviour than either of those.

Also, I think most developers just don't want to do the same thing twice. And most developers really are writing the same software over and over again through their careers, with minor changes. So they need to change something to keep it interesting, and the only things they can easily change are technology and methodology.

Re: The Grug Brained Developer (2022)

#137

Post by dryanau »

mordae wrote: post #106

I have a beef with the typing section: > grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug Juniors at my job routinely ship code that breaks due to null access in production, Sentry tells me. During intensive development periods that's about 1 detected null-a…

I'm confused. The original article is in favour of typed languages. Aren't you in agreement?

Re: The Grug Brained Developer (2022)

#138

Post by ColonelPhantom »

bredren wrote: post #93
jauntywundrkind wrote: post #74

Earlier quoted context omitted.

Ah! Carson Gross is author of grug brained developer, and htmx! I'd love to see some real critiques of htmx. Personally I think the web's big ongoing challenge has been figuring out how to update the page well, and we keep trying all kinds of attempts. That causes fatigue, and some of the ideas are wild or grow crufty over time. Htmx seems like a back-reaction, to insist on grug brained less/YAGNI. And even though th…

Some critiques focus on the developer insecurities that make them vulnerable to HTMX's charms: - Writing Vanilla JS ES6+ is not that hard, actually it is pretty fun. - Toolchain for JS/TS/CSS was bad but is pretty good now. esbuild is simple and great. - Dodging learning the above two things does not serve the dev. Others have to do with foundational aspects of the project: - HTMX is in denial of need to support nati…

Why would I write my own JS when "hx-get" does the job? Writing your own JS makes sense in some cases, but using HTML partials is also useful in many cases where you need to talk to the server anyways (since they e.g. prevent logic duplication). HTMX just makes it easy to work with them, as they're a single attribute away, rather than doing the request and insertion by hand.

Native clients are deliberately out of scope, but scraping HTML isn't the suggested solution. Rather, it is having a JSON API next to the hypermedia API: https://htmx.org/essays/splitting-your-apis/. This does have the downside of duplicate work, but does bring stability to the API without introducing something like GraphQL.

And yes, you will need to learn HTMX to use HTMX. But the surface of HTMX is generally quite small, and composes well with knowledge about HTML/CSS.

Post reply on HN