> big brain developer Bob Nystrom
Lies and slander, munificent is quite open about his grugness and his grug-brained approach is why his book is so good.
The Grug Brained Developer (2022)
361–370 of 603 posts
Re: The Grug Brained Developer (2022)
#362Earlier quoted context omitted.
At my company our system is composed of 2 dozen different services and all of them can run locally in minikube and easily be debugged in jetbrains.
Yes, it's perfectly doable even if you're doing microservices. Not being able to debug your application is an engineering failure.
can you say more? how do you do it?
Re: The Grug Brained Developer (2022)
#363Earlier quoted context omitted.
I mean, it would be faster to just import them into an in-memory sqlite database, run a `union all` query and then dump it to a csv... That's still probably the wrong way to do it, but 10 minutes for a 20k line file? That seems like poor engineering in the most basic sense.
It's a twenty line bash script. Pipe some shit into sqlite, done. But the guy 'is known to get the job done' apparently.
Maybe he’s recognized something brilliant. Management doesn’t know that the program he wrote was just a reimplementation of the Unix “cut” and “paste” commands, so he might as well get rewarded for their ignorance.
And to be fair, if folks didn’t get paid for reinventing basic Unix utilities with extra steps, the economy would probably collapse.
Re: The Grug Brained Developer (2022)
#364Earlier quoted context omitted.
I keep trying to explain this to tiny dev teams (1-2 people) that will cheerfully take a trivial web app with maybe five forms and split it up into “microservices” that share a database, an API Management layer, a queue for batch jobs to process “huge” volumes (megabytes) of data, an email notification system, an observablity platform (bespoke!) and then… and then… turn the trivial web forms into a SPA app because “t…
The only useful definition of a "service" I've ever heard is that it's a database. Doesn't matter what the jobs and network calls are. One job with two DBs is two services, one DB shared by two jobs is one service. We once had 10 teams sharing one DB, and for all intents and purposes, that was one huge service (a disaster too).
Yes! My viewpoint also. I've been very alone in that view over the last few decades. Nice to know there's someone else out there.
Re: The Grug Brained Developer (2022)
#365Related, https://en.wikipedia.org/wiki/Anti-intellectualism_in_Americ...
[dead]
Re: The Grug Brained Developer (2022)
#366One of the many ironies of modern software development is that we sometimes introduce complexity because we think it will "save time in the end". Sometimes we're right and it does save time--but not always and maybe not often. Three examples: DRY (Don't Repeat Yourself) sometimes leads to premature abstraction. We think, "hey, I bet this pattern will get used elsewhere, so we need to abstract out the common parts of…
On my laptop I have a yin-yang sticker with the yin labeled DRY and the yang labeled YAGNI.
Re: The Grug Brained Developer (2022)
#367Earlier quoted context omitted.
It's all they've seen. They don't get why they're doing it, because they're junior devs masquerading as architects. There's so many 'senior' or 'architect' level devs in our industry who are utterly useless. One app I got brought in late on the architect had done some complicated mediator pattern for saving data with a micro service architecture. They'd also semi-implemented DDD. It was a ten page form. Literally tha…
> It's all they've seen. They don't get why they're doing it, because they're junior devs masquerading as architects. There's so many 'senior' or 'architect' level devs in our industry who are utterly useless. This is the real, actual conversation to be had about "AI taking jobs." I've seen similar things a lot in the private sector. There's just loads of people just flailing around doing stuff without really having…
This is in no way unique to software. Virtually all fields I have insight in are the same and managment is one of the worst.
Re: The Grug Brained Developer (2022)
#368“Good debugger worth weight in shiny rocks, in fact also more” I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. I generally agree that it’s the best way to start understanding a s…
> Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow.
Sigh. Same. To a large extent, this is caused by debuggers just sucking for async/await code. And just sucking in general for webdev.
Re: The Grug Brained Developer (2022)
#369Earlier quoted context omitted.
Adding print statements sucks when you are working on native apps and you have to wait for the compiler and linker every time you add one. Debuggers hands down if you are working on something like C++ or Rust. You can add tracepoints in your debugger if you want to do print debugging in native code. In scripting languages print debugging makes sense especially when debugging a distributed system. Also logging works b…
How long are you realistically "waiting for the compiler and linker"? 3 seconds? You're not recompiling the whole project after all, just one source file typically If I wanna use a debugger though, now that means a full recompile to build the project without optimizations, which probably takes many minutes. And then I'll have to hope that I can reproduce the issue without optimizations.
> How long are you realistically “waiting for the compiler and linker”
Debugging kernel module issues on AL2 on bare metal ec2 with kprint. Issue does not reproduce in qemu. It happens
Re: The Grug Brained Developer (2022)
#370Earlier quoted context omitted.
The service I'm working on right now has about 25 packages. From the language's perspective, each package is a "module" with a "public" API. But from the microservices architecture's perspective, the whole thing is one module with only a few methods.
But why would users of the module care about the dependency packages? You could still have a module with only a few methods and that's the interface.
i’ve seen devs do stuff like this (heavily simplified example)
from submodule import pandas
microservices putting a network call in on the factoring is a feature in this case, not a bug. it’s a physical blocker stopping devs doing stuff like that. it’s the one thing i don’t agree with grug on.
HOWEVER — it’s only a useful club if you use it well. and most of the time it’s used because of expectations of shiny rocks, putting statements about microservices in the company website, big brain dev making more big brain resume.