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

221–230 of 394 posts

Re: The Grug Brained Developer

#221

Post by wildrhythms »

geekbird wrote: post #176
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…

This. Premature and excessive fragmenting into unmaintainable and operationally microse5rvices is the bane of my existence. It's often done by zealots, who see microservice architecture as a matter of religious faith, not operability convenience. Sure, some monoliths are harder to debug if there are multiple distinct packages that need to operate together if they are all in the same container. But fragmenting a simpl…

i can't tell you how many teams I've seen spend months and months engineering some vast microservice system only to end up serving maybe 500 DAU. It could have been a single executable on a $5 VPS

Re: The Grug Brained Developer

#222

Post by 3np »

ryanmcbride wrote: post #179
strix_varius wrote: post #140

Earlier quoted context omitted.

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.

GOD I hate microfrontends. Had a client that had a single, relatively simple application that they wanted as 3 separate angular apps. The reasoning was that they wanted to be able to autoscale them separately? Was unable to convince them that the gains from that would be negligible, especially for an internal tool, and that scaling the whole frontend instead of a single part of it would have virtually no downside sin…

Could you have done "the monorepo approach" and just have the same code deployed in 3 instances with different `APP_MODE` configuration value or something like that? :P

Re: The Grug Brained Developer

#223

Post by wildrhythms »

codethief wrote: post #194
strix_varius wrote: post #140

Earlier quoted context omitted.

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.

Oh lawd, at our client people recently pushed that idea, too. Unfortunately, managers were all on board ("Every team will be able to release autonomously and much faster!!!11") and it became politically impossible to argue for alternatives that won't result in dependency and infrastructure hell. So here we are now, splitting off every single page of a god damn legacy web shop into a separate micro frontend, each of w…

we are slowly returning to iframes :)

Re: The Grug Brained Developer

#224

Post by strix_varius »

strikelaserclaw wrote: post #195
strix_varius wrote: post #140

Earlier quoted context omitted.

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.

microfront ends work well for self contained components that need to be used in multiple pages, they don't even need to have a "separate" backend, as long as there is an area or code file for the backend code that deals with whatever data the microfront end needs.

In such a component-oriented circumstance, what is the motivation for choosing a “microfrontend” approach instead of, say, a component?

Re: The Grug Brained Developer

#225

Post by asddubs »

recursive wrote: post #207
dack wrote: post #102

As funny as this post is to read, I don't want to see yet another developer say "complexity bad". I want to see a company deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down. _THEN_ I want developers from that company to share their opinions about how they do it. Do such companies/products even exist? Software is so bad these…

> I want to see a company deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down. I think maybe Reaper fits the bill. http://reaper.fm/ As far as I can tell, it's two people.

few people touching the code is easy mode IMO. much easier to not introduce bugs if you've designed half the system and are deeply familiar with its various idiosyncrasies. good architecture is not a must here, although fewer people obviously also make it easier to stay consistent and make larger refactors at once without stepping on anyones toes.

sometimes that bug free thing that just works and was written all by one guy is just a real pig behind the scenes, but hey, that guy always knew what not to do, no matter how messy the APIs.

Re: The Grug Brained Developer

#226

Post by titzer »

lmm wrote: post #215
titzer wrote: post #203

Earlier quoted context omitted.

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

I think we probably agree in a lot of concrete cases but discussing in the abstract tends to bring out polarizing statements. That's why I qualified most of my remarks, because I'll happily ham it up with a functional style...in tests, and other places where I don't feel strongly about what's going on.

When you are forced to use some accumulating global state, that leaves you with writing in a different style--loopy, if you will--which maybe is a good signal to the reader that something is weird or different, but then again maybe it isn't.

One thing that bit me using Java streams recently is that it completely broke down when I had a concurrent data structure that needed to have the coarseness of locking tuned for performance. Laziness and functional streaming operators had to just go out the window to even make it clear where a lock was taken and released. So loops it was.

Re: The Grug Brained Developer

#227

Post by 3np »

residualmind wrote: post #211
eurasiantiger wrote: post #39

Earlier quoted context omitted.

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 a…

grug think two is company but three is crowd. no refactoring new abstraction until same code in three places. sometimes crowd is fine too, if divided nicely. grug never saw point of new class with only fetchAndParseMany function.

also why grog keep putting state in mutable instance properties on acting class when can just be parameter arguments? save so little typing but will for get curse. grug remembers making big object-oriented python2 app multi-threaded. and all that c# when in consulting on legacy codebase. grug avoid such pattern now.

Re: The Grug Brained Developer

#228

Post by wildrhythms »

recursive wrote: post #209
whiskyagogo wrote: post #205

Earlier quoted context omitted.

Modularization, encapsulation, coordination, safely scaling contributors/features.

Vanilla js can do all that. Just `import` and done. No build steps.

As a front end dev I am all-for vanilla JS. I hate maintaining a webpack, postcss, dependency hell. I still long for the simpler days of plugging javascript into a static page for some helpful dynamic utility.

Where I find vanilla JS struggles is (for example) rendering a big tree of data, and then needing to update some data dynamically within the tree without re-rendering the whole thing. You end up with some horrible queryselector hell, or keeping some immense table of pointers to the elements. Fortunately for us, we have some tiny libraries like lit-html that can help accomplish this. In the theme of grug I think the ideal solution is somewhere in between.

Re: The Grug Brained Developer

#229

Post by raphlinus »

raphlinus wrote: post #86
tines wrote: post #2

As a grug-brained developer, I love the spirit of this, but it's kinda hard to read. Maybe the author can publish an English translation? :)

I might be willing to give this a shot. I appreciated the charm and humor in the original, but especially for readers who don't have English as a first language it probably gets in the way of the message.

Here are the first few sections: https://gist.github.com/raphlinus/f6b34f85d63c4b73a0242481ed...

I'll keep going if there's positive feedback, delete it if the author doesn't appreciate it.

Re: The Grug Brained Developer

#230

Post by llamataboot »

unphased wrote: post #196
zero_shift wrote: post #170

Earlier quoted context omitted.

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 think it could actually be a pretty good strategy to optimize your job search for the degree to which you might be able to go rogue and get away with it.

I am pretty up front about being chaotic good and seeing that historically I add a ton of value when I am given some free rein to fix things or just make some (or a bunch of people's) lives easier, I often seek forgiveness rather than permission but - I am also willing to accept push back (always a hey, this fixes this and that, what do people think? not a "I made the terrible code perfect and you must accept this), I try to be clear about where my time is going is my own assigned work is going slower, not usually because I'm off over-engineering some internal tool. but because when you get a reputation as someone that can help people fix things, lots of your time is about unblocking others cause they trust that they can come to you (which levels the whole team up, but sometimes means individual commitments fall behind), and I am try to push for the whole team to have less fear and more freedom to have a day a month where they just work on whatever tech debt they want, or throw up a quick PR for discussion about something they see, etc etc. And I'm also clear that if the org doesn't see value in what I'm doing, that's their call to make, because I also know I can find one that will.

But in my experience the devs that want to /optimize/ for going rogue, are the ones you least want re-engineering your entire auth system overnight with code no one else understands and/or the most abrasive when it comes to arguing about why they are right. It's a gentle balance and being honest, kind, and collaborative goes pretty far....

Post reply on HN