Live data from Hacker News

The Grug Brained Developer (2022)

grugbrain.dev

101–110 of 201 posts

Re: The Grug Brained Developer (2022)

#101
post #70

Earlier quoted context omitted.

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.

In my experience most over-engineering can be explained by a lack of understanding. When we design it, we don't know what matters and our guesses are wrong; and when we modify it later, we don't have time to figure out how it really works. Both of those problems can be fixed by simply spending more time to understand, but time is money.

Not a lack of understanding, a misalignment of values.

I had a team once implement the MediatR pattern for a When I asked them to remove it, it became a political fight that went to the VP because they were convinced that sort of flexibility was a good idea. Fast forward a year and they have a new technical leader and he thought I wanted that complexity until we had a conversation and when I mentioned I didn't like it he confessed to me he wanted to rip it all out.

People value the wrong thing too often.

Re: The Grug Brained Developer (2022)

#102
post #20

Earlier quoted context omitted.

> There's real skill in creating simple solutions to complex problems. Not entirely facetiously, I think that, for engineers, there's real skill in creating simple solutions to simple problems—not, for example, finding the general instance of the problem and solving that, when the problem is unlikely to recur and crafting the perfect general solution delays delivery on what's actually in front of you. (I know Perl's…

I actually think this is the opposite of the case, for some definition of “generic”: the more generic problem has fewer possible solutions (there is only one pure function of type x=>x) so, if you hit on the right general problem to solve, your code will almost always be simpler. The problem is this is one of those “$1 to solve the problem/$99 to know which problem to solve” situations.

generic is being used in two different ways.

1. linked list is a generic data structure with a relatively simple interface

2. an application with 1k configuration values is generic in that it can handle everything, but is in no way simple.

Re: The Grug Brained Developer (2022)

#103

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

Because generics are actually a powerful tool for simplifying the data flow. They make it possible to promise not to do anything specific to and based on the data involved.

Re: The Grug Brained Developer (2022)

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

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 and 2. the number that floats above the cart icon in the header.

Do you

1. Return the updated card and insert it as normal, then pass the HTML to figure out the number to change the cart icon with and call JS to change that icon?

2. Trigger a full page reload, meaning that both items update at the cost of losing the scroll position?

3. Break convention with HTMX and call a JSON API that will let you return the updates primitive values, and maintain the display logic changes in JS?

4. Have a weird hybrid JSON + HTML API that return multiple responses for each part of the DOM tree that needs changing and rely on some custom JS to do both updates?

Re: The Grug Brained Developer (2022)

#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-access bug per day per junior developer.

Using a proper type system with static checks would probably help immensely by pointing out "Hey, this can be null. You sure?" in their IDEs...

Also, you can have completion even without static typing.

> big brain type system shaman often say type correctness main point type system, but grug note some big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct

That's just rude and uncalled for.

I have shipped code mainly in in C, PHP, Python, Haskell and typed Python. The incidence of bugs that make it into production is much lower with typed languages. That's one reason to like it.

It also makes refactoring much, much easier. I can check whole code base for broken callers when I change something widely used and get reliable results in seconds. That helps immensely with iterating on a growing code base.

Re: The Grug Brained Developer (2022)

#107

Everyone's blub paradoxed about simple. Anything below your chosen level of simplicity has no features. Anything above is too complex. You are at the true simplicity optimum. Your manager is the one who doesn't get it. Terrible guy. Understands nothing. Unlike you, true artist, pure simplicity.

The only reasonable comment here

Re: The Grug Brained Developer (2022)

#108

very hard to read, but worth it

I asked chatgpt to fix it:

``` Intwoduction

this cowwection of thoughts on softwawe devewopment gathewed by gwug bwain devewopew

gwug bwain devewopew not so smawt, but gwug bwain devewopew pwogwam many wong yeaw and weawn some things awthough mostwy stiww confused

gwug bwain devewopew twy cowwect weawns into smaww, easiwy digestibwe and funny page, not onwy fow you, the young gwug, but awso fow him because as gwug bwain devewopew get owdew he fowget impowtant things, wike what had fow bweakfast or if put pants on

big bwained devewopews awe many, and some not expected to wike this, make souw face

THINK they awe big bwained devewopews many, many mowe, and mowe even definitewy pwobabwy maybe not wike this, many souw face (such is intewnet) ```

Re: The Grug Brained Developer (2022)

#109

Grug Inc. -- Fantastic! I really enjoyed reading this and feel like im guilty of unleashing the complexity spirit demon, even though im not even a big brain. Out of curiosity, are there any programming languages that naturally steer people away from complexity? but still "get the job done".

Of the languages I’ve used, Go comes closest. The language is small and boring, but it means I stay focused on the problem and hand instead of getting fancy.

That's the first thing anyone has ever said about Go that makes me want to learn the language. That sounds like an ideal programming language.

Re: The Grug Brained Developer (2022)

#110

Grug Inc. -- Fantastic! I really enjoyed reading this and feel like im guilty of unleashing the complexity spirit demon, even though im not even a big brain. Out of curiosity, are there any programming languages that naturally steer people away from complexity? but still "get the job done".

Of the languages I’ve used, Go comes closest. The language is small and boring, but it means I stay focused on the problem and hand instead of getting fancy.

I second this but I will say that the complexity demon lives in the reflect package.
Post reply on HN