Every developer I've spoken to on a team >1 has complained about PR review burnout, no understanding of the codebase anymore and even a lost love for the craft. I think this is primarily happening because every PR reads like its written by a distinguished engineer. (Why say lot word when few word do trick??!!)
Everyone reviews PRs differently but I've personally started relying more on visualisations to get an initial sense of what's happening. So this is my attempt at a skill and a UI kit to help me understand PRs faster. Bugbots help find bugs, but the primary purpose of reviews is to build shared understanding! Shoutout to Blake Smith (https://blakesmith.me/2015/02/09/code-review-essentials-for-...).
Agree that shared understanding is the hard part. Bugbots find bugs. Review is how the team stays aligned on the change. Visuals help a lot for that first pass.
Another cause of burnout for us was noisy bot comments on top of diffs that already look AI-written. We only want findings we would actually act on.
I checked your skill and looks really good, however I find it to be very complex already, we do many PRs and maybe visualizing graphs for every one is too much. I think ideally could filter the complexity of PRs and adapt the visualizer depending on that, being just two sentences on some and complete graphics on some.
I myself created Revix AI and we internally created some rules that we found that served educational purpose as well, we started linking that rules to the PR comments that Revix did so the devs could access that information if they wanted. Following what I said, it's always better to keep it simple and only expand if the human wants to get deeper or if the pull request requires it.
Yeah that's definitely true, a future direction would be to filter PRs as Chore/Operational/Feature/etc and only create visualisations for Feature Requests - maybe Jev can help here ;)
I checked out your website and found it quite abstract, I understand enforcing team standards on each PR but I don't see more meat beyond that for reviews. Would be keen to see what y'all do in the review space!
Every developer I've spoken to on a team >1 has complained about PR review burnout, no understanding of the codebase anymore and even a lost love for the craft. I think this is primarily happening because every PR reads like its written by a distinguished engineer. (Why say lot word when few word do trick??!!)
Everyone reviews PRs differently but I've personally started relying more on visualisations to get an initial sense of what's happening. So this is my attempt at a skill and a UI kit to help me understand PRs faster. Bugbots help find bugs, but the primary purpose of reviews is to build shared understanding! Shoutout to Blake Smith (https://blakesmith.me/2015/02/09/code-review-essentials-for-...).
I'd love to get HN's take on this :)
Agree that shared understanding is the hard part. Bugbots find bugs. Review is how the team stays aligned on the change. Visuals help a lot for that first pass.
Another cause of burnout for us was noisy bot comments on top of diffs that already look AI-written. We only want findings we would actually act on.
I checked your skill and looks really good, however I find it to be very complex already, we do many PRs and maybe visualizing graphs for every one is too much. I think ideally could filter the complexity of PRs and adapt the visualizer depending on that, being just two sentences on some and complete graphics on some.
I myself created Revix AI and we internally created some rules that we found that served educational purpose as well, we started linking that rules to the PR comments that Revix did so the devs could access that information if they wanted. Following what I said, it's always better to keep it simple and only expand if the human wants to get deeper or if the pull request requires it.
Yeah that's definitely true, a future direction would be to filter PRs as Chore/Operational/Feature/etc and only create visualisations for Feature Requests - maybe Jev can help here ;)
I checked out your website and found it quite abstract, I understand enforcing team standards on each PR but I don't see more meat beyond that for reviews. Would be keen to see what y'all do in the review space!