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

171–180 of 394 posts

Re: The Grug Brained Developer

#171

Post by nickysielicki »

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…

Yes, I am using a shitty language.

> Thus, I fully support high-level languages in which pointers are hidden and types are strong and the declaration of data structures does not require you to solve a syntactical puzzle generated by a malevolent extraterrestrial species. That being said, if you find yourself drinking a martini and writing programs in garbage-collected, object-oriented Esperanto, be aware that the only reason that the Esperanto runtime works is because there are systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge.

https://www.usenix.org/system/files/1311_05-08_mickens.pdf

Re: The Grug Brained Developer

#172

Post by throwaway892238 »

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

you want eat cake and have cake.

Re: The Grug Brained Developer

#173

Post by ryanmcbride »

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

Best PMs I've had were former engineers. They aren't ALL great but at least when we'd tell them that to build a feature we have to lay new groundwork instead of blasting out a hack, they generally understand why that's a good idea.

Re: The Grug Brained Developer

#174

Post by e111077 »

koonsolo wrote: post #120
recursive wrote: post #90

Earlier quoted context omitted.

npm, babel, webpack, module compatibility, et al

You are free to develop everything in vanilla JavaScript and run your coded scripts straight in the browser. Very non-complex. But the team that uses npm, babel, webpack etc will crush you both on development speed and stability.

let's be real. nobody is crushing anybody in development speed with webpack. Use rollup esbuild or vite

Re: The Grug Brained Developer

#175

Post by greatpostman »

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 actually disagree. I think people disparaging micro services are working at companies or on problems that are too small for that solution

Re: The Grug Brained Developer

#176

Post by geekbird »

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 simple set of services into a dozen microservices each in their own disconnected container is excessive too. If any of those fragments depend too closely on other fragments to operate (like, say, a timer service and a session renewal service that depends on the timer) it will easily fall over and be nearly impossible to tell why.

If you are going to shard up your application into microservices, be sure to split out your functions conservatively, so that like goes with like. It's easier to split stuff out more later than to try to split every little jot and tittle into its own dinky container. That way you don't end up with little containers of nothing wasting processor and I/O just for the sake of dogma.

Re: The Grug Brained Developer

#177

Post by verve_rat »

xupybd wrote: post #169
verve_rat wrote: post #147

Earlier quoted context omitted.

100% A bad code base is a mental health hazard, and that shit hurts. Of course time crunch isn't the only thing that makes a bad code base. Devs bike shedding to much, or just not being good at maintaining a code base can have the same effect, but not having the time to protect your own future mental health really starts to weigh on a workplace.

Inheriting someone else's mess can really hurt. Especially when you are not given the time to improve things. Worse when you're told they've negotiated 20% extra time to clean up, but every estimate gets shortened by more than 20% to please the customer. Then you're in the firing line when new features don't ship in time and bugs keep popping up everywhere. It makes you question your ability as a developer. Sapping y…

Agreed. And I've found that agile doesn't really help here either.

Sometimes I wonder how we got to be highly paid, but sometimes, completely lacking the authority to do our own jobs.

Re: The Grug Brained Developer

#178

Post by throwaway892238 »

zero_shift wrote: post #161
aaaaaaaaaaab wrote: post #79

Earlier quoted context omitted.

Hehe, good one! Oh, you're serious? :D

If it's so bad, you're welcome to write your applications in vanilla JavaScript, with no shims, in flat files without modules calling 1998 era DOM APIs. There's a reason most people don't, however.

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)

Re: The Grug Brained Developer

#179

Post by ryanmcbride »

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.

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 since each app was basically a single form, but tons of upsides like less code complexity, easier data persistence, and fewer versioning issues, faster build time. But they didn't care. To this day I don't know what manager was sold so firmly on building 3 apps when one would do, but not my problem anymore.

Re: The Grug Brained Developer

#180

Post by pixelrevision »

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.

Sounds like a big brained term for web pages. I’d lean into that.
Post reply on HN