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

261–270 of 603 posts

Re: The Grug Brained Developer (2022)

#261

Post by bluefirebrand »

mplanchard wrote: post #137
GMoromisato wrote: post #98

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

For folks who seek a rule of thumb, I’ve found SPoT (single point of truth) a better maxim than DRY: there should be ideally one place where business logic is defined. Other stuff can be duplicated as needed and it isn’t inherently a bad thing. To modulate DRY, I try to emphasize the “rule of three”: up to three duplicates of some copy/paste code is fine, and after that we should think about abstracting. Of course no…

> To modulate DRY, I try to emphasize the “rule of three”: up to three duplicates of some copy/paste code is fine, and after that we should think about abstracting

Just for fun, this more or less already exists as another acronym: WET. Write Everything Twice

It basically just means exactly what you said. Don't bother DRYing your code until you find yourself writing it for the third time.

Re: The Grug Brained Developer (2022)

#262

Post by tannhaeuser »

factorialboy wrote: post #4

From the creator of HTMX.

grug guy THINK big brain and make up hypermedia api and so complicated words like revealed religion but only in his imagination.

more important app is like how programmer intended. web only for docs like unix files anyway no good to think too much.

Re: The Grug Brained Developer (2022)

#264

Post by nardi »

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…

Having worked in many languages and debuggers across many kinds of backend and front end systems, I think what some folks miss here is that some debuggers are great and fast, and some suck and are extremely slow. For example, using LLDB with Swift is hot garbage. It lies to you and frequently takes 30 seconds or more to evaluate statements or show you local variable values. But e.g. JavaScript debuggers tend to be fantastic and very fast. In addition, some kinds of systems are very easy to exercise in a debugger, and some are very difficult. Some bugs resist debugging, and must be printf’d.

In short, which is better? It depends, and varies wildly by domain.

Re: The Grug Brained Developer (2022)

#265

Post by johnfn »

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

If you listen to what he has to say, it’s quite interesting. He would occasionally use one to step through an entire frame of gameplay to get an idea of performance and see if there were any redundancies.

Re: The Grug Brained Developer (2022)

#267

Post by jiggawatts »

vermilingua wrote: post #104
jiggawatts wrote: post #76

Earlier quoted context omitted.

The customer is a government department formed by the merger of a bunch of only vaguely related agencies. They have “inherited” dozens of developers from these mergers, maybe over a hundred if you count the random foreign outsourcers. As you can imagine there’s no consistency or organisational structure because it wasn’t built up as a cohesive team from the beginning. The agencies are similarly uncoordinated and will…

Is this DCS in NSW? If so that would explain so much about my own work interactions with them.

No… but you’re close with your guess!

These new superdepartments all have the same issues to the point that I sometimes confuse them.

Re: The Grug Brained Developer (2022)

#269

Post by strken »

AdieuToLogic wrote: post #249
strken wrote: post #231

Earlier quoted context omitted.

I understand that you explained some exceptions to the rule, but I disagree with two things: the assumption of incompetence on the part of geophile to not make logging conditional in some way, and adding the label of "anti-pattern" to something that's evidently got so much nuance to it. > the non-trivial cost implications of voluminous log output If log output is conditional at compile time there are no non-trivial c…

> ... I disagree with two things: the assumption of incompetence on the part of geophile to not make logging conditional in some way ... I assumed nothing of the sort. What I did was identify an anti-pattern and describe an alternative which experience has shown to be a better approach. "Incompetence" is your word, not mine. > ... and adding the label of "anti-pattern" to something that's evidently got so much nuance…

As I said, conditional. As in, you add logging to your code but you either remove it at compile time or you check your config at run time. By definition, work you don't do is not done.
Post reply on HN