Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Grug Brained Developer

grugbrain.dev

Post reply on HN
Print view View original

211–220 of 394 posts

Re: The Grug Brained Developer

#211

Post by residualmind »

eurasiantiger wrote: post #39
TranquilMarmot wrote: post #10

I think this nicely captures everything I've learned about programming over the past n years that I wish other people would realize too.

What have been the most complex business requirements for a project you have worked on, and what made them complex? Was the resulting system less complex than the requirements?

Sorry to hijack without being asked. I totally agree with the original piece and this comment. For me the most important part is: no matter how complex your requirements are, how you deal with complexity and abstraction in your codebase and architecture, will make or break it. Abstractions should match what's actually happening (with just the minimal right amount of future telling). Useless abstractions and missing abstractions are both bad. Getting rid of a bad abstraction in a system is harder than introducing one, though. Erring on the side of fewer abstractions and dumber (not bad, just boring) code especially in early stages can save you literally thousands of hours of debugging, fixing, scratching your head. I may be wrong, this is how I feel right now.

Re: The Grug Brained Developer

#212

Post by titzer »

joshuamorton wrote: post #94
titzer wrote: post #38

Earlier quoted context omitted.

Undoing someone's copy-pasted for-loops and while-loops is called "factoring" and undoing someone's bad abstractions is called "re-factoring" and is about 10x as slow. At this point in my career I have seen way more crappy abstractions and needlessly abstracted code than grug-brain code. And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reaso…

I've seen a massive, "simple", abstraction-free function of 500-1000 lines take smart engineers quarters to safely "factor". I've seen this same thing happen a handful of times. Big spaghetti function requires someone to build a new test suite from scratch so that they can refactor safely, because everything ends up having spooky surprising distant effects, because there isn't any abstraction to contain things. They'…

Sure, this happens. But imagine it was 10 times that size and factory poorly. If you had the same lack of tests, I'd contend it'd be a worse nightmare, because you have to first reverse engineer the confusing old design, unconfuse it, and then incrementally refactor it.

You can write bad code in any language with any constructs. The more code you do write the worse bad ideas just metastasize like cancer.

Re: The Grug Brained Developer

#213

Post by throwaway892238 »

zero_shift wrote: post #183
throwaway892238 wrote: post #178

Earlier quoted context omitted.

developer see javascript think "looks frozen yogurt came out wrong end, but can do job". end up building castle of wrong end frozen yogurt. some say better than no castle. grug say why building with no-no soft serve in first place. (grug know answer: more shiny rock)

Please stop the grugposting, it is impossible to read.

you in thread for grug story! no like, no read!

Re: The Grug Brained Developer

#214

Post by majormajor »

maest wrote: post #87

> sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overworked and dealing with many grugs. In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going. I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing…

How are you hiring your devs?

The more abstract-problem/algorithmic the hiring process, the more I see this.

Ask practical coding problems instead, screen for practical devs who can find 80/20 style shortcuts.

(You probably still want some of the abstract folks too, though, to round things out.)

Re: The Grug Brained Developer

#215

Post by lmm »

titzer wrote: post #203
lmm wrote: post #85

Earlier quoted context omitted.

> And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reason about. > Sometimes loops are better! That I think is backwards. A loop could be doing literally anything - it probably is futzing with global variables - so there's no way to reason about it except by executing the whole thing in your head. A map (or mapA) or a fold (or foldM) or a fi…

> it probably is futzing with global variables The opposite is true in my experience. Loops working over variables local to a function is a lot easier to reason about then a series of intricately intertwined lambdas, if they share state. If everything you do is functional then a series of pipelines might be alright, but it might not. If the functions are spread all over the place it can take a larger amount of mental…

> Loops working over variables local to a function is a lot easier to reason about then a series of intricately intertwined lambdas, if they share state.

I mean accessing a mutable variable from a lambda is obviously insane, agreed. The whole point of using the functional combinators is that you don't do that.

Re: The Grug Brained Developer

#217

Post by majormajor »

zero_shift wrote: post #170
lukasb wrote: post #167

Earlier quoted context omitted.

I'm sorry that you've apparently only worked with bad PMs.

Unfortunately, you don't have to work with bad PMs very often, to occasionally experience a year or more of misery due to their ineptitude. Good PMs are a bit of a paradox. They are immensely impactful and bring value to every project they touch. Yet they are also far overqualified for what is often a thankless job. I also have come to the view that even good PMs will rarely allocate the work that is truly impactful.…

I've had more job misery due to bad other devs than bad PMs.

I can negotiate with my PM. I can't negotiate with the bad dev who made every method call in every file depend implicitly/somewhat indirectly on 20+ things two years ago because "long argument lists = bad" but "dependency injection = good". That ship sailed and it still hurting me every time I need to add a new feature.

Re: The Grug Brained Developer

#218

Post by residualmind »

mattmanser wrote: post #98
nullptr_deref wrote: post #61

> good debugger worth weight in shiney rocks, in fact also more: when faced with bug grug would often trade all shiney rock and perhaps few children for good debugger and anyway debugger no weigh anything far as grug can tell grug know debugger good but grug often realize grug no need debugger on smaller cases and only run it when grug need it, grug try simple code like print and log first, if grug sad and no underst…

Relying on log and print statements is like giving up. I would claim that's not simplicity, that's inexperience, but I have no idea what language you're referring to. Sometimes I do it with JavaScript when I didn't setup the project, it's using a framework I don't know and I'm not willing to spend the time figuring out how to get real debugging working so there are caveats. But you definitely should not be doing that…

Some debuggers take longer(1-3 secs) to spin up than it takes me to add a print, compile and run and see my theory confirmed or not.

If I want a debugger and see e.g. the complete variable scope at a breakpoint, I'll use a debugger. If I just want a very quick sanity check I'll use a simple print.

Once you enter debugger land you're there. When I'm currently not in the debugger but rather compiling and executing "for real", it seems more straightforward to me to not enter debugger land when I really don't need it. Personal preference.

There are scenarios, where 2 print statements can tell you more quicker, than breakpoints. You have to step through the breakpoints, right? 2 print statements in different parts of the control flow can tell me everything I need to know at a single glance.

Re: The Grug Brained Developer

#219

Post by 3np »

strix_varius wrote: post #140
twhitmore wrote: post #107

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too That made me laugh. The microservices madness of the past decade is now starting to settle down to more mature understandings, but there are still a lot people biting off large testing, operational, and data transactionality/ reporting costs. People often don't recognise beforehand the magnitude of…

I don't know if this is universal, but in my circles "microfrontends" are now all the rage. How do you bring up concerns with that in good faith? It's so obviously terrible that I've no idea where to begin.

First time I encounter the term, immediate reaction "hmm, maybe we're already kind of doing this?", thinking about mapping a dozen or so services to different HTTP endpoints/prefixes under the same root.

Then I did a search. Oh lord. One of the top results[0] is an illustrative guide on how to split out a Button component into an independent deployment... I can only hope that applying this on a Button is not supposed to be taken literally but I can also only assume that thousands of professional have now made it their calling to split out every component into its own "microfrontend"...

EDIT: Nope, looks idiomatic. [1]

[0] https://levelup.gitconnected.com/micro-frontends-step-by-ste...

[1] https://microfrontends.info/microfrontends/

Re: The Grug Brained Developer

#220

Post by Trasmatta »

maest wrote: post #87

> sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overworked and dealing with many grugs. In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going. I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing…

Do you have enough of an understanding of the codebase to know what is over engineering and what isn't? If not, that's the problem I have with a lot of project managers. If you can't understand the codebase, how can you make judgment calls like that? It can be very hard to make the right call between over and under engineered, even if you're intimately familiar with the codebase.
Post reply on HN