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

351–360 of 603 posts

Re: The Grug Brained Developer (2022)

#351

Post by roryirvine »

arkh wrote: post #283
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…

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

Yeah, exactly, and you see it all over the place. It's not even cargo-culting, it's more half-arsed than that.

"We're all-in on using Kanban here"

"Ah, great. What's your current WIP limit?"

"Um, what's a whip limit?"

As a consultant, I don't actually mind finding myself in the midst of that sort of situation - at the very least, it means I'm going to be able to have a positive impact on the team just by putting in a bit of thought and consistent effort.

Re: The Grug Brained Developer (2022)

#352

Post by foldr »

strken wrote: post #231
AdieuToLogic wrote: post #225

Earlier quoted context omitted.

> It's absolutely not an anti-pattern if you have appropriate tools to handle different levels of logging, and especially not if you can filter debug output by area. It is an anti-pattern due to what was originally espoused: I add logging code, that stays forever. For a major interface, I'll usually start with INFO level debugging, to document function entry/exit, with param values. There is no value for logging "fun…

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…

The whole concept of an “anti-pattern” is a discussion ender. It’s basically a signal that one party isn’t willing to consider the specific advantages and disadvantages of a particular approach in a given context.

Re: The Grug Brained Developer (2022)

#353

Post by [deleted] »

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…

[deleted]

Re: The Grug Brained Developer (2022)

#354

Post by isoprophlex »

withinboredom wrote: post #336
isoprophlex wrote: post #330

Earlier quoted context omitted.

I swear I'm not making this up; a guy at my current client needed to join two CSV files. A one off thing for some business request. He wrote a REST api in Java, where you get the merged csv after POSTing your inputs. I must scream but I'm in a vacuum. Everyone is fine with this. (Also it takes a few seconds to process a 500 line test file and runs for ten minutes on the real 20k line input.)

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.

Re: The Grug Brained Developer (2022)

#356

Post by balamatom »

someothherguyy wrote: post #62
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…

> Now I understand that “architecture” and “patterns” is a jobs program for useless developers. Yet, developers are always using patterns and are thinking about architecture. Here you are doing so too, a pattern, "form submission" and an architecture, "request-response".

A word and its meaning are usually antonyms.

Re: The Grug Brained Developer (2022)

#357

Post by cfiggers »

isoprophlex wrote: post #330
default-kramer wrote: post #95

Earlier quoted context omitted.

I'm convinced that some people don't know any other way to break down a system into smaller parts. To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.

I swear I'm not making this up; a guy at my current client needed to join two CSV files. A one off thing for some business request. He wrote a REST api in Java, where you get the merged csv after POSTing your inputs. I must scream but I'm in a vacuum. Everyone is fine with this. (Also it takes a few seconds to process a 500 line test file and runs for ten minutes on the real 20k line input.)

I'm really dumb, genuinely asking the question—when people do such things, where are they generally running the actual code? Would it be in a VM on generally available infra that their company provides...? Or like... On a spare laptop under their desk? I have use cases for similar things (more valid use cases than this one, at least my smooth brain likes to think) but I literally don't know how to deploy it once it's written. I've never been shown or done it before.

Re: The Grug Brained Developer (2022)

#358

Post by strogonoff »

4hg4ufxhy wrote: post #221
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…

It depends on the domain. Any complex long lived mutable state, precise memory management or visual rendering probably benefits from debuggers. Most people who work on crud services do not see any benefit from it, as there is practically nothing going on. Observing input, outputs and databases is usually enough, and when it's not a well placed log will suffice. Debuggers will also not help you in distributed environm…

Is there a name for an approach to debugging that requires neither debuggers nor print calls? It works like this:

1. When you get a stack trace from a failure, without knowing anything else find the right level and make sure it has sensible error handling and reporting.

1a. If the bug is reproduced but the program experiences no failure & associated stack trace, change the logic such that if this bug occurs then there is a failure and a stack trace.

1b. If the failure is already appropriately handled but too high up or relevant details are missing, fix that by adding handling at a lower level, etc.

That is the first step, you make the program fail politely to the user and allow through some debug option recover/report enough state to explain what happened (likely with a combination of logging, stack trace, possibly app-specific state).

Often it can also be the last step, because you can now dogfood that very error handling to solve this issue along with any other future issue that may bubble up to that level.

If it is not enough you may have to resort to debugging anyway, but the goal is to make changes that long-term make the use of either debuggers or print statements unnecessary in the first place, ideally even before the actual fix.

Re: The Grug Brained Developer (2022)

#359

Post by lhamil64 »

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…

I work with some pretty niche tech where it's usually, ironically, easier to use a debugger than to add print statements. Unfortunately the debugger is pretty primitive, it can't really show the call stack for example. But even just stopping at a line of code and printing variables or poking around in memory is pretty powerful.

Re: The Grug Brained Developer (2022)

#360

Post by notnullorvoid »

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…

Sounds like Rob does use a debugger and it's name is Brian.
Post reply on HN