I like this comment. I also have a lot of experience with lazy (my accusation!) reviewers who ask me to split a PR into smaller PRs. At some jobs, I felt like it was a strategy to sabotage my work (slow me down).
In my experience, the best was to ensure your code will be approved (ok, maybe some minor tweaks) is to assign a code reviewer before you start writing code. You (the coder) performs some quick analysis, then formulates a plan for how to fix the bug or implement a change or new feature. You verbally discuss this plan using screenshare (or side-by-side in-person) so both of you can see the code that will be changed. The code reviewer needs to verbally approve your plan. This way, you don't spend a lot of time writing code and tests, only to have the reviewer rejected it very quickly: "You should have done it this way instead." (Please note: That process that I described is intentionally informal, casual, and unrigid. Why? This grants permission for the coder and reviewer to decide the plan as intelligent adults, not as "Children of JIRA" [hint: unnecessary formality].)
Another thing that I do: After I write the code, but before I write tests, I ask the reviewer to review, but not approve. After looking at their comments, I quickly add another commit to the PR to address their concerns, then start work on the tests. When the reviewer does the final review, it is very quick, like 10% of the initial review. All of this really helps to reduce coder/reviewer friction, and nearly eliminate "Tyranny of the Reviewer". One last gripe about code reviewing: It hardly makes sense for someone much more junior than the coder to do the review. I have seen this too many times.
Yes this. As an author I see it as my responsibility to socialise my work early and get buy in from reviewers.
The more I think about PR review, which I've been doing a lot lately thanks to AI, the more I see it as social in nature. Built on trust and reputation. It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic.
> It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic.
Have you heard about Linus Torvald's opinion about using AI/LLMs for Linux kernel patches? He seems quite open-minded about it. Roughly: "It is a useful tool."
Yes I think his stance works well for established contributors who have a reputation. For infrequent contributors, with no rep, it's a large liability to try to figure out if their plausible-at-a-glance work is actually slop. Such a liability with uncertain ROI hence the sentiment in OSS frequently banning or at least heavily policing AI usage
What I'm trying to get at is if a PR comes in that looks decent at a glance, well in the past that was a strong signal and now it's not. But you can fall back on the relationship you have with the author. Trust , reputation. In OSS often you have no relationship with the author (of course ex established contributors or people who have well established public reputation). Whereas in a typical workplace you will quickly establish a relationship with those you work with
Comments
I like this comment. I also have a lot of experience with lazy (my accusation!) reviewers who ask me to split a PR into smaller PRs. At some jobs, I felt like it was a strategy to sabotage my work (slow me down).
In my experience, the best was to ensure your code will be approved (ok, maybe some minor tweaks) is to assign a code reviewer before you start writing code. You (the coder) performs some quick analysis, then formulates a plan for how to fix the bug or implement a change or new feature. You verbally discuss this plan using screenshare (or side-by-side in-person) so both of you can see the code that will be changed. The code reviewer needs to verbally approve your plan. This way, you don't spend a lot of time writing code and tests, only to have the reviewer rejected it very quickly: "You should have done it this way instead." (Please note: That process that I described is intentionally informal, casual, and unrigid. Why? This grants permission for the coder and reviewer to decide the plan as intelligent adults, not as "Children of JIRA" [hint: unnecessary formality].)
Another thing that I do: After I write the code, but before I write tests, I ask the reviewer to review, but not approve. After looking at their comments, I quickly add another commit to the PR to address their concerns, then start work on the tests. When the reviewer does the final review, it is very quick, like 10% of the initial review. All of this really helps to reduce coder/reviewer friction, and nearly eliminate "Tyranny of the Reviewer". One last gripe about code reviewing: It hardly makes sense for someone much more junior than the coder to do the review. I have seen this too many times.
Yes this. As an author I see it as my responsibility to socialise my work early and get buy in from reviewers.
The more I think about PR review, which I've been doing a lot lately thanks to AI, the more I see it as social in nature. Built on trust and reputation. It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic.
Yes I think his stance works well for established contributors who have a reputation. For infrequent contributors, with no rep, it's a large liability to try to figure out if their plausible-at-a-glance work is actually slop. Such a liability with uncertain ROI hence the sentiment in OSS frequently banning or at least heavily policing AI usage
"There's no trust or reputation in OSS" is a pretty interesting take.
What I'm trying to get at is if a PR comes in that looks decent at a glance, well in the past that was a strong signal and now it's not. But you can fall back on the relationship you have with the author. Trust , reputation. In OSS often you have no relationship with the author (of course ex established contributors or people who have well established public reputation). Whereas in a typical workplace you will quickly establish a relationship with those you work with