I’ve been experimenting with a way to make code reviews more understandable - turning tricky pull requests into short comic strips.
The blog post shows an example generated from a real PR: summarizing the changes, anthropomorphizing the components, and making the flow visually obvious. It’s meant to help reviewers grasp intent quickly and make reviews a bit more fun.
Curious whether others have tried visual or narrative aids in their review process, and whether this could be practical for real teams.
I really like the idea... but I have to admit my first visceral reaction was "I hate this". I think it's because the tone and style is quite infantile/childish. A good experiment nonetheless. Maybe there's a middle ground somewhere?
Using visual approaches, including comics, is a reasonable idea I've been looking into personally as well (mostly using style transfer from manga). :)
But, the actual concepts communicated need to be clear. In your example strip here, it doesn't seem to be meeting that bar for a reviewer. :(
Keep at it though, as I get the feeling this is the kind of thing that will work after a few important "aha!" ideas and tweaks happen to the generating process. :)
As far as I know, the order of hook calls is important to link them to the correct components: the important point of the linked list is not the ordering of built-in hooks depending ob name.
Although it's true that useEffect runs code after render. The picture places useReducer after useEffect, which would not even make sense in this interpretation?
Could be that I'm misremembering details, but I find it more interesting to read, for example, a good description, when a PR is large, dense, or hard to understand.
You actually might be on to something... AI aside, it's often a good idea to include visuals in a PR such as diagrams.
But having something like a comic where it's both visual and communicative in a more conversational/narrative way could prove pretty effective. Also if you can throw some humour in there, it could potentially add even more comprehensibility, etc.
It seems to me the level this comic is at is such that anyone who needs an aid like this would not be capable of providing a meaningful review on the pull request.
If the goal is to encourage rubber-stamping by bystanders, it might help.
not sure about for pull requests, but for protocols it could be interesting.
I asked it to generate a comic for https negotiation over tcp https://imgur.com/a/0p0Pzum I think with a bit more prodding it might be interesting for documenting protocols
In the same way that many people would rather read imperfect ESL than LLM text, I would rather you draw stick figures yourself. The fact that this is a product of AI means anything I see in it may be 'hallucinated' or otherwise incorrect.
20 comments
[ 3.3 ms ] story [ 37.7 ms ] threadThe blog post shows an example generated from a real PR: summarizing the changes, anthropomorphizing the components, and making the flow visually obvious. It’s meant to help reviewers grasp intent quickly and make reviews a bit more fun.
Curious whether others have tried visual or narrative aids in their review process, and whether this could be practical for real teams.
Sadly, the fun would end with a reprimand or sanctions order. Cf. https://news.ycombinator.com/item?id=43866303 ("Don't watermark your legal PDFs with purple dragons in suits").
Might work for bringing associate attorneys up to speed in a new case, or for teaching concepts to law students, though!
Not sure if it would be used, though. Being on HN front page helps.
It would also have to contain a lot of content, and be indexed well.
But, the actual concepts communicated need to be clear. In your example strip here, it doesn't seem to be meeting that bar for a reviewer. :(
Keep at it though, as I get the feeling this is the kind of thing that will work after a few important "aha!" ideas and tweaks happen to the generating process. :)
As far as I know, the order of hook calls is important to link them to the correct components: the important point of the linked list is not the ordering of built-in hooks depending ob name.
Although it's true that useEffect runs code after render. The picture places useReducer after useEffect, which would not even make sense in this interpretation?
Could be that I'm misremembering details, but I find it more interesting to read, for example, a good description, when a PR is large, dense, or hard to understand.
In the case of hooks, this blog post was good:
https://overreacted.io/why-do-hooks-rely-on-call-order/
I'm not sure whether the explanation in the picture is useful to anyone who doesn't already know the information.
Same issue with most AI-generated doc-blocks I've seem, often misleading, or explaining the obvious, instead of the "why".
But having something like a comic where it's both visual and communicative in a more conversational/narrative way could prove pretty effective. Also if you can throw some humour in there, it could potentially add even more comprehensibility, etc.
Thanks for sharing!
If the goal is to encourage rubber-stamping by bystanders, it might help.
It was difficult to parse even as someone who's familiar with these concepts, and I think it will hurt more than help any newbies.
I asked it to generate a comic for https negotiation over tcp https://imgur.com/a/0p0Pzum I think with a bit more prodding it might be interesting for documenting protocols
BTW, amazing they chose a review that exemplifies why hooks are a horrible horrible mistake for public API.
https://en.wikipedia.org/wiki/Comics_Code_Authority
I know this is hacker news but you do get all sorts posted here, that's my excuse.