“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 system. Breaking on an interesting line of code during a test run and studying the call stack that got me there is infinitely easier than trying to run the code forwards in my head.
Young grugs: learning this skill is a minor superpower. Take the time to get it working on your codebase, if you can.
Professor Carson if you're in the comments I just wanted to say from the bottom of my heart thank you for everything you've contributed. I didn't understand why we were learning HTMX in college and why you were so pumped about it, but many years later I now get it. HTML over the wire is everything.
I've seen your work in Hotwire in my role as a Staff Ruby on Rails Engineer. It's the coolest thing to see you pop up in Hacker News every now and then and also see you talking with the Hotwire devs in GitHub.
Thanks for being a light in the programming community. You're greatly respected and appreciated.
> complexity very bad
Oh boy, this is so true. In all my years of software engineering this is one of those ideas that has proved consistently true in every single situation. Some problems are inherently complex, yes, but even then you'd be much, much better off spending time to think things through to arrive at the simplest way to solve it. Again and again my most effective work has been after I questioned my prior approaches and radically simplified things. You might lose some potential flexibility, but in most case you don't even need all that you think you need.
Some examples:
- Now that reasonably good (and agentic) LLMs are a thing, I started avoiding overly complex TypeScript types that are brittle and hard to debug, in favor of writing spec-like code and asking the LLM to statically generate other code based on it.
- The ESLint dependency in my projects kept breaking after version updates, many rules were not sophisticated enough to avoid false positives, and keeping it working properly with TypeScript and VSCode was getting complicated. I switched to Biome.js, and it was simpler and just as effective. However, I'm recently having bugs with it (not sure if Biome itself or the VSCode extension is to blame). But whatever, I realized that linting is a nice-to-have, not something I should be spending inordinate amount of times babying. So I removed it from the build tool-chain, and neither do I even need have it enabled all the time in VSCode. I run Biome every now and then to check the code style and formatting , and that's it, simple.
- Working on custom data migration tooling for my projects, I realized forward migrations are necessary to implement, but backwards migrations are not worth the time and complexity to implement. In case a database with data needs to be rolled back, just restore the backup. If there was no data, or it is not a production database, just run the versioned initialization script(s) to start from a clean state. Simple.
This concept is really interesting when you think about statically typed, pure functional languages. I like working in them because I'm too pretty and stupid to think about side effects in every function. My hair is too shiny and my muscles are too large to have to deal with "what if this input is null?" everywhere. Can't do it. Need to wrap that bad boy up in a Maybe or some such and have the computer tell me what I'm forgetting to handle with a red squiggly.
So many gems in here but this one about microservices is my favorite:
grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
> given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex
I think about this line at least once a week
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.
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?
Me no like grug perpetuate complexity myth. Little grugs no understand complexity is not monolith. Me want fix that.
Complexity not bad. Complexity just mean "thing have many consideration". Some thing always have many consideration. Not bad if useful and necessary.
Complexity still difficult and raise problem. So try avoid complexity when unnecessary and no add value. But shun complexity bad when it detract value or raise new problem.
Little grug benefit from not over-simplify. Not everything just good or bad, most thing both, it depend.
One thing to appreciate is that this article comes from someone who can do the more sophisticated (complex) thing, but tries not to based on experience.
There is of course a time and place for sophistication, pushing for higher levels of abstraction and so on. But this grug philosophy is saying that there isn't any inherent value in doing this sort of thing and I think that is very sound advice.
Also I noticed AI assistance is more effective with consistent, mundane and data driven code. YMMV
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 the pattern and then..." And that's when the Complexity Demon enters.
We want as many bugs as possible caught at compile-time. But that means the compiler needs to know more and more about what we're actually trying to do, so we come up with increasingly complex types which tax your ability to understand.
To avoid boilerplate we create complex macros or entire DSLs to reduce typing. Unfortunately, the Law of Leaky Abstractions means that when we actually need to know the underlying implementation, our head explodes.
Our challenge is that each of these examples is sometimes a good idea. But not always. Being able to decide when to introduce complexity to simplify things is, IMHO, the mark of a good software engineer.
I can't believe this is (2022). I would have confidently told you I read this 10 years ago and guessed that it was already a classic then.
sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice
The distain for shamans in palpable and obviously born out of similar work experience. *shudder*
Shamans suck for the same reason architects suck -- take "getting stuff done" out of someone's responsibilities, and they lose the plot pretty quickly.
This is, I think, my favorite essay about building software. The style is charming (I can see why some might not like it) and the content is always relevant.
I know, I get it, but I've realised that I'm not actually grug-brained. The way my brain works, I remember things pretty well; I like to get into the details of systems. So if more complexity in the code means the app can do more or a task is automated away I'll make the change and know I'll be able to remember how it works in the future.
This doesn't mean OP is bad advice, just make a conscious decision about what to do with complexity and understand the implications.
Share this gem on a team chat, everyone had a good laugh and now everytime we discuss some weird situation, we start speaking as grug brains… Don’t know how I lived without it so far
Related. Others?
The Grug Brained Developer (2022) - https://news.ycombinator.com/item?id=38076886 - Oct 2023 (192 comments)
The Grug Brained Developer - https://news.ycombinator.com/item?id=31840331 - June 2022 (374 comments)
This has by far the best discussion of the visitor pattern I've yet to come across.
From the creator of HTMX.
A classic.
And it’s inspired many more grugs like grug ceo https://www.sam-rodriques.com/post/the-grugbrained-ceo
It took me decades to learn these lessons on my own.
many, many shiney rock lost to agile shaman!
while it's #1 I might as well say, there's a book:
https://www.lulu.com/shop/carson-gross/the-grug-brained-deve...
it's the same content + an index, so not worth buying unless you want the hard copy, but maybe a good convo-starter for the ol'dev team
Probably my single favourite programming article.
Very entertaining (and enlightening) read. I love the 'reach for club' visuals, made me laugh out loud a few times.
I argue that complexity is good. Complicated things though, those are bad. The world is complex, and we must deal with it. But as long as we organize our work and don't let it spiral into being complicated, we'll be fine.
This was shared with me years ago by another developer I worked with. I still reference it today as I continue my external battle with the complexity demon.
I am grug, and I endorse this message.
OMG is that the technical name for my development style? I'm not like super deep in technobabble since there are so many coined names and references that it is nearly impossible to assign the correct one.
Grug brained dev I am I guess.
I avoided this page since it was a terrible programmer at work who shared it to me a couple years back. The title and the writing style made me think of him in new depths. Perhaps there’s something here for it to trend in HN, but I’m sure it resonates to all skill levels of programmers in wildly different ways—the comments are only an illusion of consensus and wisdom.
tbh the print vs debugger is way too binary. cost of context switching when using debuggers inside hot loop dev cycles is high imo. stepping through 3rd-party deps? yeah debugger helps. but if i'm grinding on internal logic or tracking a value over time, grepable logs save more time long run. plus they persist. you can rerun logic in head later. debugger can't replay state unless you checkpoint or record. also worth noting, debugger UIs vary wildly across langs and editors. using one in python feels decent, but in TS or compiled C++ mess? adds more overhead than it solves
Grug user want keyword research tool.
Grug user find program that does that and more.
Grug user confused by menu.
Grug user wish tool only did keyword research.
grug read words and move head up down lot
grug make other work grugs read this after yellow circle arrive next
grug thank clever grug
I think even the simplest of programming tools is still unfathomably powerful, enough to where you could eliminate data structures and still be where we are today. BitTorrent had a great amount of complexity, and look what streaming did to it.
this very cool
I smell a formal grammar behind dumbiffied grug english.
nonetheless, I think that when it says:
> so grug say again and say often: complexity very, very bad
at the end of that section, it shoulud say instead:
> so grug say again and say often: complexity very, very, very bad
this disambiguates 3 instances of same concept/idea AND, even better, showcases 3 values of increasing strength like for warning, error, critical use. most compact.
end of groog
I've been fooling around with applying grugspeak to famous essays on tech.
https://docs.google.com/document/d/1emldq9MovfYshOSkM9rhRUcl...
not as good as the original, i know!
> 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.
This is why I like embedded. The bigger the CPU, the more room the complexity spirit daemon has to thrive.
This is one of my favorite pieces of non-fiction. No sarcasm.
So this is how a troll from The Witcher 3 would explain software engineering
Grug quickly tire of verbal gimmick that go on way too long.
Some solid nuggets here. Totally agree on keeping it simple and not rushing. I’ve rushed things before to meet unrealistic deadlines, resulting in bad first impression. Took a step back, simplified, and let the design emerge. Ended up with something users actually loved. Thanks for sharing.
The anecdote about rob pike and logging made me chuckle.
Fun fact about Google: logging is like 95% of the job, easily... From tracking everything every service is doing all the time to wrangling the incoming raw crawl data, it's all going through some kind of logging infrastructure.
I was there when they actually ran themselves out of integers; one of their core pieces of logging infrastructure used a protocol buffer to track datatypes of logged information. Since each field in a protocol buffer message is tagged with an integer key, they hit the problem when their top-level message bumped up against the (if memory serves) int16 implementation limit on maximum tag ID and had to scramble to fix it.
big fan of HTMX (pinnacle of grug)
i have started to use repl debugging … just insert a repl statement anywhere in your raku code and you can interact with the code state
This has to be adapted to the LLM era as well.
I read it back then and then forgot the word and couldn't find it with search. LOL. Thanks for reposting!
I send this article as part of onboarding for all new devs we hire. It is super great to keep a fast growing team from falling into the typical cycle of more people, more complexity.
The guy that wrote this is a raging schizophrenic that argues with his own alt on X
I used to be against complexity and worried about such narratives making fun of people who tried to avoid it but now I'm grateful. If software developers didn't have such strong biases in favor of complexity, LLMs would probably be producing really high quality code and have replaced us all by now... Instead, because the average code online is over-engineered, un-reusable junk, their training set is a mess and hence they can only produce overengineered junk code. Also, this may provide long term job safety since now LLMs are producing more and more code online, further soiling the training set.
this is a masterpiece of writing -- well done
Coding too hard, this grug use AI.
Oh FFS why is print-vs-debug being debated as either/or? Both can be valuable, depending on the circumstances. It's clearly both/and.
“grug once again catch grug slowly reaching for club, but grug stay calm”
Relateable.
I still call coffee "black think juice"
I've always wondered at the best way of doing integration tests. There is a lot of material on unit tests, but not so much on integration tests. Does anyone know of a good book on the subject?
might be some good points in here but it's sooo hard to read.
htmx.
and clojure.
mmmmm.
Content 1, Style 0
Thinking you are too smart leads to all sorts of trouble, like using C++ and being proud of it.
If you think your intelligence is a limited resource however you'll conserve it and not waste it on tools, process and the wrong sort of design.
[dead]
[dead]
[flagged]
[flagged]