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

391–400 of 603 posts

Re: The Grug Brained Developer (2022)

#391

Post by williamdclt »

stavros wrote: post #121
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…

We've solved this problem by making the modules in the monolith only able to call each other from well-defined APIs, otherwise CI fails.

I honestly think it's the only way outside of one-person projects (and even then...), you need _some_ design pressure.

Re: The Grug Brained Developer (2022)

#392

Post by jakewins »

dijksterhuis wrote: post #370
rcxdude wrote: post #285

Earlier quoted context omitted.

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 why? no idea. but they’ve done it. and it’s horrifying as it’s usually not done once. 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 yo…

True - but most languages make it much easier than Python to disallow this kind of accidental public API creation. Python inverts the public API thing - in most (all?) other mainstream languages I can think of you need to explicitly export the parts of your module you want to be public API.

You can do this in Python as well, but it does involve a bit of care; I like the pattern of a module named “internal” that has the bulk of the modules code in it, and a small public api.py or similar that explicitly exposes the public bits, like an informal version of the compiler-enforced pattern for this in Go

Re: The Grug Brained Developer (2022)

#393

Post by flmontpetit »

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…

My current position has implemented a toolchain that essentially makes debugging either impossible or extremely unwieldy for any backend projects and nobody seems to think it's a problem.

Re: The Grug Brained Developer (2022)

#394

Post by perrygeo »

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…

Running a debugger on test failure is a ridiculously effective workflow. Instead of getting a wall of text, you drop right into the call stack where the failure/error happened. `pytest --pdb` in python, worth its weight in shiny rocks for sure!

Re: The Grug Brained Developer (2022)

#395

Post by jmull »

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 find the differences between printf debugging and line debuggers (or whatever you call them) unimportant in most circumstances.

Line debuggers usually have some nice conveniences, but the major bottlenecks are between the ears, not in the tool.

Re: The Grug Brained Developer (2022)

#396

Post by osigurdson »

While I agree that complexity is bad the fact that we don't really have a shared understanding of what complexity is doesn't help. At worst, it can be just another synonym for "bad" that passes through the mental firewall without detection. For instance is having multiple files in a project "complex"? If I am unfamiliar with a codebase is it "complex" and I therefore have to re-write it?

Re: The Grug Brained Developer (2022)

#397

Post by CactusRocket »

mcqueenjordan wrote: post #183

One of my favorite LLM uses is to feed it this essay, then ask it to assume the persona of the grug-brained developer and comment on $ISSUE_IM_CURRENTLY_DEALING_WITH. Good stress relief.

I am not very proficient with LLMs yet, but this sounds awesome! How do you do that, to "feed it this essay"? Do you just start the prompt with something like "Act like the Grug Brained Developer from this essay "?

Re: The Grug Brained Developer (2022)

#398

Post by voidUpdate »

jmull wrote: post #395
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 find the differences between printf debugging and line debuggers (or whatever you call them) unimportant in most circumstances. Line debuggers usually have some nice conveniences, but the major bottlenecks are between the ears, not in the tool.

I usually use a normal debugger to find a problem when I can see its symptoms but not the original caus. That way I can break on the line that is causing the symptom, check what the variables are like and go back up the call stack to find the origin of the incorrect state. I can do all that in one shot (maybe a couple if I need to break somewhere else instead) rather than putting prints everywhere to try and work out what the call stack is, and a load of prints to list off all the local variables

Re: The Grug Brained Developer (2022)

#399

Post by cyberax »

sensanaty wrote: post #387
cyberax wrote: post #368

Earlier quoted context omitted.

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

I try all the time, but I always end up having to wrestle a trillion calls into some library code that has 0 relevance to me, and if the issue is happening at some undetermined point in the chain, you basically have to step through it all to get an idea for where things are going wrong. On the other hand, the humble console.log() just works without requiring insanely tedious and frustrating debugger steps.

I mean, "step over" and "go to line" exist...

Re: The Grug Brained Developer (2022)

#400

Post by recursivedoubts »

osigurdson wrote: post #396

While I agree that complexity is bad the fact that we don't really have a shared understanding of what complexity is doesn't help. At worst, it can be just another synonym for "bad" that passes through the mental firewall without detection. For instance is having multiple files in a project "complex"? If I am unfamiliar with a codebase is it "complex" and I therefore have to re-write it?

Part of the problem with complexity is that it is very easy for engineers to justify. Yes, there is an important distinction between necessary and accidental complexity, but, to take a point from the essay, even necessary complexity can be reduced by saying "no" to features.

This is why I treat "complexity bad" as a mantra to keep me in the right mindset when programming. Complexity bad. Even necessary complexity. We may have to deal with it, but, like fire, it's still dangerous.

Post reply on HN