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

281–290 of 603 posts

Re: The Grug Brained Developer (2022)

#281

Post by mrkeen »

anonymars wrote: post #185
jonstewart wrote: post #167

Related, https://en.wikipedia.org/wiki/Anti-intellectualism_in_Americ...

In what way would you say they are related? I've read both but don't see it

Introducing a needless us/them dynamic. Don't do it the way those elites do it, do it like us real grugs.

That's why it's so easy to rush in and agree with everything. In another article, you might have to read 3 points for microservices, and 4 against. But here? Nope.

Factoring? Just something you do with your gut. Know it when ya see it. Grug isn't going to offer up the why or how, because that's something a reader could disagree with.

Re: The Grug Brained Developer (2022)

#282

Post by phito »

idontwantthis wrote: post #157
roncesvalles wrote: post #123

Earlier quoted context omitted.

I'd love to use a real debugger but as someone who has only ever worked at large companies, this was just never an option. In a microservices mesh architecture, you can't really run anything locally at all, and the test environment is often not configured to allow hooking up a stepping debugger. Print debugging is all you have. If there's a problem with the logging system itself or something that crashes the program…

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.

Re: The Grug Brained Developer (2022)

#283

Post by arkh »

mattmanser wrote: post #69
jiggawatts wrote: post #56

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

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…

> They'd also semi-implemented DDD.

One of my pet-peeves. "We're doing DDD, hexagonal architecture, CQRS". So, when was the last time your dev team had a conversation with your domain experts? You have access to domain experts don't you? What does your ubiquitous language look like?

So no, some "senior" read a blog post (and usually just diagonally) and ran with it and now monkey see monkey does is in full effect.

And you get the same shit with everything. How many "manager" read one of the books about the method they tell you they're implementing (or any book about management) ? How many TDD shop where QA and dev are still separate silos? How many CI/CD with no test suite at all? Kanban with no physical board, no agreed upon WIP limits, no queue replenishing system but we use the Kanban board in JIRA.

Re: The Grug Brained Developer (2022)

#284

Post by rusk »

kibibu wrote: post #243
johnfn wrote: post #208

Earlier quoted context omitted.

On the other hand, John Carmack loves debuggers - he talks about the importance of knowing your debugging tools and using them to step through a complex system in his interview with Lex Friedman. I think it's fair to say that there's some nuance to the conversation. My guess is that: - Debuggers are most useful when you have a very poor understanding of the problem domain. Maybe you just joined a new company or are e…

I'm sorry, but this juxtaposition is very funny to me: - John Carmack loves debuggers - Debuggers are most useful when you have a very poor understanding of the problem domain

I think you should substitute “code” for “domain” in the last paragraph.

John Carmack knows his domain very well. He knows what he expects to see. The debugger gives him insight into what “other” developers are doing without having to modify their code.

For Carmack, managing the code of others the debug environment is their safe space. For Kernighan et al in the role of progenitorous developer it is the code itself that is the safe space.

Re: The Grug Brained Developer (2022)

#285

Post by rcxdude »

closeparen wrote: post #258
jakewins wrote: post #256

Earlier quoted context omitted.

Any language that offers a mechanism for libraries has formal or informal support for defining modules with public APIs? Or maybe I’m missing what you mean - can you explain with an example an API boundary you can’t define by interfaces in Go, Java, C# etc? Or by Protocols in Python?

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.

Re: The Grug Brained Developer (2022)

#286

Post by discreteevent »

vharish wrote: post #273
dkarl wrote: post #103

Earlier quoted context omitted.

That's what I've observed empirically over my last half-dozen jobs. Many developers treat decomposition and contract design between services seriously, and work until they get it right. I've seen very few developers who put the same effort into decomposing the modules of a monolith and designing the interfaces between them, and never enough in the same team to stop a monolith from turning into a highly coupled amorph…

I think monoliths are not such a good idea anymore. Particularly with the direction development is going w.r.t the usage of LLMs, I think it's best to break things down. Ofcourse, it shouldn't be overdone.

> grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

> I think it's best to break things down

Factoring system = break things down.

Re: The Grug Brained Developer (2022)

#287

Post by rusk »

josephg wrote: post #194
demosthanos wrote: post #127

Earlier quoted context omitted.

There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program les…

There's another story I heard once from Rob Pike about debugging. (And this was many years ago - I hope I get the details right). He said that him and Brian K would pair while debugging. As Rob Pike told it, he would often drive the computer, putting in print statements, rerunning the program and so on. Brian Kernighan would stand behind him and quietly just think about the bug and the output the program was generati…

It’s amazing what even the most subtle perturbation in output can tell you about the internal state of the code.

Re: The Grug Brained Developer (2022)

#288

Post by mrkeen »

Buttons840 wrote: post #199
titanomachy wrote: post #115

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

Another underutilized debugging superpower is debug-level logging. I've never worked somewhere where logging is taken seriously. Like, our AWS systems produce logs and they get collected somewhere, but none of our code ever does any serious logging. If people like print-statement debugging so much, then double down on it and do it right, with a proper logging framework and putting quality debug statements into all co…

If you want to double-down on logging and do it right: make your logs fit for computer consumption and the source of truth.

That's all event-sourcing is.

Re: The Grug Brained Developer (2022)

#289

Post by rcxdude »

nyarlathotep_ wrote: post #146
mattmanser wrote: post #69

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

>Software is really an utterly bizarre field where there's really nothing that even acts as valuable credentials or experience without complete understanding of what that "experience" is actually comprised of. I think about this a lot.

Most other fields are similar, frankly.

Re: The Grug Brained Developer (2022)

#290

Post by roncesvalles »

idontwantthis wrote: post #157
roncesvalles wrote: post #123

Earlier quoted context omitted.

I'd love to use a real debugger but as someone who has only ever worked at large companies, this was just never an option. In a microservices mesh architecture, you can't really run anything locally at all, and the test environment is often not configured to allow hooking up a stepping debugger. Print debugging is all you have. If there's a problem with the logging system itself or something that crashes the program…

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.

Where do configs and secrets come from? Also, big company = hundreds of microservices.
Post reply on HN