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

181–190 of 201 posts

Re: The Grug Brained Developer (2022)

#181

Post by stnmtn »

p0nce wrote: post #124
p0nce wrote: post #105

OK, this was better than expected.

While I agree mostly, you can overdo the "grug". For example it is possible to underengineer (underabstract?) a software for years until realizing that simple things are still complicated, and you forget to built good abstractions once the patterns have emerged. If you build abstractions, you need a way to correct them anyway, making breaking changes to their contract.

The point is that "underengineering" then having to tie up the abstractions when it's really needed is oftentimes (read: not always) better than overengineering and entering the domain of the complexity demon

Re: The Grug Brained Developer (2022)

#182

Post by mrkeen »

hitchstory wrote: post #178
mrkeen wrote: post #171

Earlier quoted context omitted.

That's precisely what I meant by my comment. The 'cleaner' the integration test, the less it will behave like the real-world system. > Bad integration tests will share state with each other The real-world system shares state. > If I set up an integration test that sets up a database from scratch and tears it down and tests only the behavior of the app in that rigidly defined context ... constructing a particular set…

>... constructing a particular set of circumstances which will never occur in the real-world system. What do you find unlikely about a scenario where a test uses an app in a realistic way (e.g. with a browser) set up in a realistic context (e.g. with some fixed sample data) to reproduce a realistic scenario (e.g. a bug that already happened)? I wouldn't say that isolation and realism are completely orthogonal but I f…

> I wouldn't say that isolation and realism are completely orthogonal

Neither would I. I'm arguing that when you write a test method, you deliberately make the choice to include some kind of 'before-all' method, or not.

The reasons you would choose to include a 'before-all' method will vary from case to case. Let's say you're testing an addUser method. If you choose to isolate its state to avoid 'test flakiness', it is you making the call that addUser is flaky when run against shared state.

What is it about your application code that would make you think that addUser is flaky enough to need a clean slate to run against? Why not change the application code instead?

Re: The Grug Brained Developer (2022)

#183

Post by randomdata »

n4r9 wrote: post #177
dryanau wrote: post #137

Earlier quoted context omitted.

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

I think they differ about the why . The article claims that types are useful mainly because they allow sophisticated auto-completions. u/mordae thinks there are more important benefits re avoiding bugs in production.

In the link, Grug acknowledges the benefits of correctness established by types to an extent, but is highlighting the diminishing returns. After all, if one truly valued type system-enforced correctness, they would be writing code in something like Coq, not C and typed Python.

Re: The Grug Brained Developer (2022)

#185

Post by xavierlint »

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…

> That's just rude and uncalled for

I think you're not the "shaman" he's referring to.

By "big brain type system shaman" I understood someone who doesn't necessarily write code, but instead, e.g. sells courses around the topic, getting people hyped about it, etc.

He uses the word "shaman" previously when talking about Agile, and there are many who fit that picture of working on selling courses, and not on developing software.

Re: The Grug Brained Developer (2022)

#186

Post by zogrodea »

pphysch wrote: post #89
kirse wrote: post #37

Earlier quoted context omitted.

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…

HTMX is pretty much feature complete though.

To this comment’s replies: The dev of HTMX has said and is well aware that HTMX/hypermedia-based approaches don’t work well for every type of web app, but claims that it fits well with the vast majority of them, so the chance of it becoming bloated for want of fitting every single use case is pretty low. Greg says that a developer’s most valuable weapon against the complexity demon is limiting features by saying “no”, so I think the chance is pretty minimal.

So the cycle spoken of would be broken at this sentence. “SJSLib grows complex because it has to support all the web things.”

Re: The Grug Brained Developer (2022)

#187

Post by nameless912 »

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've worked with a "big brain type system shaman" before. If anything, this is a very kind and charitable analysis. People who are obsessed with type hierarchies are _insufferable_ to work with, and their justifications often live in the land of "well what if"'s and "but that's not _sound_"'s. A lot of the enshittification that's induced by type systems comes from folks who believe that simply with enough types they will be able to completely prevent bugs, and that's just not true.

Re: The Grug Brained Developer (2022)

#188

Post by meiraleal »

jauntywundrkind wrote: post #78
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.

Today's best post on complexity to me was the I accidentally saved my company half a million dollars , which is a story filled yes with a lot of poor developers but much much worse is a story filled with Conway's Law style lessons. Of madcap organizations & wild legacy systems that we live atop & typically just have to make do with. https://news.ycombinator.com/item?id=38069710 https://ludic.mataroa.blog/blog/i-accid…

> Stop hating on devs, please

I don't think this makes sense. For example currently I have a big inclination to think bad about developers working for Vercel/recommending NextJs because they are invariably the same ppl and do it because of monetary benefits. The intentional over engineering they are adding to make a profit is insane and evil. There is no way I can make this point without "hating" the people doing it.

Re: The Grug Brained Developer (2022)

#189

Post by nuancebydefault »

Defletter wrote: post #111
lawn wrote: post #96

Earlier quoted context omitted.

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.

How refreshing it is to read these very honest findings about oneself's abilities!

Re: The Grug Brained Developer (2022)

#190

Post by Willish42 »

bluefirebrand wrote: post #47
Willish42 wrote: post #38

Earlier quoted context omitted.

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…

> People can write perfect, simple, DRY code if they have the time to and are incentivized to. In my experience, people trying to make code DRY also wind up writing over-complicated patterns and abstractions to make it so. I think a large amount of over-engineering is likely due to people applying patterns where they don't need to, or building unnecessary abstractions, or otherwise doing what they think is "good code…

Totally. Sometimes [Hanlon's Razor](https://en.wikipedia.org/wiki/Hanlon%27s_razor) applies too -- often times the easiest thing to do is pile on without refactoring anything. And what makes sense in the scope of one PR doesn't necessarily make sense holistically over several years of changes.

Most folks aren't incentivized or simply don't bother to think through things and try harder. The "this way looks more smart so I made it all complicated" thing definitely happens too, but in eng orgs like I'm part of where we go through design reviews to try and cull that sort of thinking, the other less-intentional version is still common enough to be a problem at scale.

Post reply on HN