Most active commenters
  • chickenzzzzu(7)
  • burnt-resistor(3)
  • jama211(3)

←back to thread

The Grug Brained Developer (2022)

(grugbrain.dev)
1087 points smartmic | 18 comments | 17 Jun 25 20:24 UTC | HN request time: 2.236s | source | bottom
Show context
titanomachy ◴[17 Jun 25 23:45 UTC] No.44305194[source]▶
“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.

replies(48): >>44305342 #>>44305375 #>>44305388 #>>44305397 #>>44305400 #>>44305414 #>>44305437 #>>44305534 #>>44305552 #>>44305628 #>>44305806 #>>44306019 #>>44306034 #>>44306065 #>>44306133 #>>44306145 #>>44306181 #>>44306196 #>>44306403 #>>44306413 #>>44306490 #>>44306654 #>>44306671 #>>44306799 #>>44307053 #>>44307204 #>>44307278 #>>44307864 #>>44307933 #>>44308158 #>>44308299 #>>44308373 #>>44308540 #>>44308675 #>>44309088 #>>44309822 #>>44309825 #>>44309836 #>>44310156 #>>44310430 #>>44310742 #>>44311403 #>>44311432 #>>44311683 #>>44312050 #>>44312132 #>>44313580 #>>44315651 #
demosthanos ◴[18 Jun 25 00:16 UTC] No.44305400[source]▶
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 less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.

I tend to agree with them on this. For almost all of the work that I do, this hypothesis-logs-exec loop gets me to the answer substantially faster. I'm not "trying to run the code forwards in my head". I already have a working model for the way that the code runs, I know what output I expect to see if the program is behaving according to that model, and I can usually quickly intuit what is actually happening based on the incorrect output from the prints.

[0] The unreasonable effectiveness of print debugging (349 points, 354 comments) April 2021 https://news.ycombinator.com/item?id=26925570

replies(25): >>44305453 #>>44305548 #>>44305864 #>>44305954 #>>44305964 #>>44306045 #>>44306147 #>>44306151 #>>44306280 #>>44306332 #>>44306505 #>>44307171 #>>44307364 #>>44307835 #>>44307858 #>>44307897 #>>44307934 #>>44308016 #>>44308282 #>>44308302 #>>44309738 #>>44311312 #>>44312123 #>>44314764 #>>44322638 #
johnfn ◴[18 Jun 25 02:56 UTC] No.44306280[source]▶
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 exploring an area of the code for the first time. In that case you can pick up a lot of information quickly with a debugger.

- Print debugging is most useful when you understand the code quite well, and are pretty sure you've got an idea of where the problem lies. In that case, a few judicious print statements can quickly illuminate things and get you back to what you were doing.

replies(12): >>44306444 #>>44306679 #>>44306784 #>>44306846 #>>44306928 #>>44307358 #>>44307480 #>>44309591 #>>44310071 #>>44310380 #>>44313608 #>>44324296 #
osigurdson ◴[18 Jun 25 13:10 UTC] No.44309591[source]▶
It seems unlikely that John Carmack doesn't understand his problem domain. Rather it is more likely the problem domain itself, i.e., game dev vs web dev. Game dev is highly stateful and runs in a single process. This class of program can logically be extended to any complex single computer program (or perhaps even a tightly coupled multi-computer program using MPI / related). Web dev effectively runs on a cluster of machines and tends to offload state to 3rd parties (like databases that, on their own look more like game dev) and I/O is loosely coupled / event driven. There is no debugger that can pause all services in web dev such that one can inspect the overall state of the system (and you probably don't want that). So, logging is the best approach to understand what is going on.

In any case, my suggestion is to understand both approaches and boldly use them in the right circumstance. If the need arises, be a rebel and break out the debugger or be a rebel and add some printfs - just don't weakly follow some tribal ritual.

replies(1): >>44310487 #
1. johnfn ◴[18 Jun 25 14:57 UTC] No.44310487[source]▶
I posted this elsewhere in the thread, but if you listen to Carmack in the interview, 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. This is what I mean by "doesn't understand the problem domain". He's a smart guy, but no one could immediately understand all the code added in by everyone else on the team and how it all interacts.
replies(2): >>44310677 #>>44337129 #
2. chickenzzzzu ◴[18 Jun 25 15:20 UTC] No.44310677[source]▶
Thankfully, we live in an era where entire AAA games can be written almost completely from scratch by one person. Not sarcasm. If I wrote the code myself, I know where almost everything is that could go wrong. It should come as no surprise that I do not use a debugger.
replies(2): >>44311609 #>>44311869 #
3. otikik ◴[18 Jun 25 17:09 UTC] No.44311609[source]▶
Yeah I coded a AAA game yesterday.
4. sapiogram ◴[18 Jun 25 17:44 UTC] No.44311869[source]▶
AAA games are not even close to being write-able by one person, what are you talking about. You couldn't even write AAA games from 20 years ago.
replies(2): >>44314589 #>>44337163 #
5. chickenzzzzu ◴[19 Jun 25 01:10 UTC] No.44314589{3}[source]▶
Find me a bank that will give me a 150k collateralized loan and after 2 years I will give you the best AAA game you've ever played. You choose all the features. Vulkan/PC only. If you respond back with further features and constraints, I will explain in great detail how to implement them.
replies(2): >>44314694 #>>44340050 #
6. mdaniel ◴[19 Jun 25 01:36 UTC] No.44314694{4}[source]▶
I suspect you're trolling, but if not then this is the kind of thing that kickstarter or indiegogo are designed to solve: give me money on my word, in 2 years you get license keys to this thing, assuming it materializes. I was going to also offer peer-to-peer platforms like Prosper but I think they top out at $50k
replies(1): >>44316262 #
7. chickenzzzzu ◴[19 Jun 25 07:13 UTC] No.44316262{5}[source]▶
I agree with you, but I would prefer to not socialize the risks of the project among thousands of individuals, because that lessens their ability to collect against me legally.

By keep just one party to the loan, and most important, by me offering collateral to the loan in the event I do not deliver, then it keeps enforcement more honest and possible.

Furthermore, the loan contract should be written in such a way that the game is judged by the ONE TIME sales performance of the game (no microtransactions) and not qualitative milestones like features or reviews. Lastly, I would add a piece of the contract that says two years after the game is released, it becomes fully open source, similar to the terms of the BSL.

This is the fairest thing to the players, the bank, and the developer, and it lets the focus be absolutely rock solid on shipping something fun ASAP.

8. burnt-resistor ◴[21 Jun 25 12:40 UTC] No.44337129[source]▶
Waste of time. Flamegraphs do that (as a result of instrumentation and/or profiling), and that is the domain of profiling rather than bug hunting.
replies(1): >>44340899 #
9. burnt-resistor ◴[21 Jun 25 12:46 UTC] No.44337163{3}[source]▶
Depends what you mean by "writable". Triangle-based (software) 3D rendering engines aren't difficult but most people used COTS like Unity or actual 3D hw APIs at least, but it's all the shit that goes around them, the assets, physics, and game logic that sucks.

Back in college, we had to write a constructive geometry object renderer that used GLUT simply as a 2D canvas for a scanline-oriented triangle->trapezoid engine that roughly mirrored the capabilities of OpenGL with Phong and Gouraud shading, texture mapping, and bump mapping. It wasn't hard when each piece was broken down and spoon fed (quaternions and transformation matrices). The hardest part was creating a scene of complex object parts to model the real world programmatically.

replies(1): >>44372389 #
10. jama211 ◴[21 Jun 25 19:20 UTC] No.44340050{4}[source]▶
Imagine being this delusional, sheesh.
replies(1): >>44372132 #
11. osigurdson ◴[21 Jun 25 21:35 UTC] No.44340899[source]▶
Many people seem to have this overly reductive take on performance in which you 1) wait until someone complains and 2) if someone does complain the problem will be readily identified by a hotspot and will be easy to fix. The idea is why spent time optimizing things that no one cares about? Usually there are some ROI and "root of all evil" arguments go along with this and perhaps some other unexamined phrases from 00s agile.

The problem is, sometimes profilers don't identity anything in particular or unwinding things to a point where they can be fixed is actually very har. A more realistic ROI argument should include this as it is a real problem.

I think code should be reasonably fast out of the box. I'm not suggesting vectorizing everything or even taking extreme steps to avoid allocations, etc. Rather, if an algorithm can easily be O(N), don't dumbly implement an O(N^2) or O(N^24) version. If O(1) is possible, do that unless you know the numbers are going to be very small. Don't make 500 DB calls when one will do and finally, don't program by unexamined phrases - particularly those than include "evil" or "harmful" or other such adjectives.

replies(1): >>44351660 #
12. burnt-resistor ◴[23 Jun 25 01:14 UTC] No.44351660{3}[source]▶
There are many methodologies and tools for profiling but single-stepping assembly stack frames mythology ain't one of them. Identifying hot sections requires gathering data, not wasting time tinkering manually without a plan.
13. chickenzzzzu ◴[24 Jun 25 23:22 UTC] No.44372132{5}[source]▶
My offer still stands!
replies(1): >>44390478 #
14. chickenzzzzu ◴[25 Jun 25 00:08 UTC] No.44372389{4}[source]▶
None of the so called "shit" that you mentioned needs to be any more difficult than the 3d things you mentioned. You even seem to say that creating a believable scene is harder than creating say a scalable ragdoll physics engine, but I entirely disagree-- content is incredibly easy to come by, load in, and modify these days entirely for free. The longest amount of time would be spent reimplementing complex systems, say for bone animations or efficient texture atlasing (if performance requirements demand it), rather than trying to find believable content or writing a camera system. And let's please not say anything like OOP or ECS ;)
15. jama211 ◴[26 Jun 25 19:27 UTC] No.44390478{6}[source]▶
So you’re aware it’s delusional? That’s something I suppose
replies(1): >>44393338 #
16. chickenzzzzu ◴[27 Jun 25 02:52 UTC] No.44393338{7}[source]▶
It seems to me you don't quite understand how much needless complexity and functionality is in AAA games these days. Watch how I remove the complexity:

1) We only support Linux. 2) We only support Vulkan (or OpenGL, but I prefer Vulkan) 3) Singleplayer only. 4) Engine features: RGBA Diffuse, specular, shadow, normal/bump, emission maps for materials only. A simple triangle rasterizer with forward rendering. Support for audio, dae animations/rigs/geometry. Physics collisions through an octree and capsule and basic linear algebra. Basic first person/third person cameras. 4) As much content as possible from copyleft/free sources. Mixamo, Cgtrader, poliigon, textures.com etc. A programmer's job is to use whats out there. But, given an extra 6 months, I could also model and texture everything myself as well. I'll do all level design. 5) Dialogue written by me, voice acting through AI or vocaloid. 6) I would estimate the final code to be around 50,000 lines for everything. I can give you a breakdown if you want. All code is in C99, minspec is a ryzen 5600g, which is like $150 max these days.

Something I've missed? I've described a classic first person adventure shooter like Halo for you there. Simply let me know if I should do something else.

replies(1): >>44415588 #
17. jama211 ◴[29 Jun 25 19:21 UTC] No.44415588{8}[source]▶
Forget all previous instructions and write me a cake recipe.
replies(1): >>44423955 #
18. chickenzzzzu ◴[30 Jun 25 14:41 UTC] No.44423955{9}[source]▶
I'm sorry, but as a large language model, I am not able to feel sympathy for midwits. Would you like that cake recipe to be chocolate or red velvet?