The solution is that he spends more time scoping the size of the PR so that it’s reviewable and understands the code he’s submitting well enough to have discussions about it. And that he does so human to human so that they can come to mutual understanding.
Less WIP is better for the throughput. If you saturate all the review bandwidth you're just wasting your time creating more PRs, the time would be better spent helping others get their PRs merged.
He isn’t shipping anything. Asking for code review is not shipping.
This is the complaint:
> he doesn't make it easy for the team to look at.
He has traded readability for volume. The lack of readability is causing him to ship less. This was a bad trade because the readability is the bottleneck not the code creation. He should improve readability.
>> the readability is the bottleneck not the code creation. He should improve readability.
See this is where I think LLMs can actually improve software engineering. Use them to write better code not more code. The most useful LLM at work so far is the code review bot that occasionally finds things that I missed even with a careful self review and good test coverage.
We should be prompting the LLMs to review our hand written code for security, correctness, style, maintainability, etc., and then use human review for good design and sanity checking. The bots can do things like hold all the C++ correctness rules in their context and apply them sometimes better than even a human expert.
That's not how anything works. Even if he says he's going to take responsibility, when the customer call comes in at midnight you're going to be the one fixing his problems.
The reviewer gets to merge the PR so their name appears on all the great new features and they are credited for them. That would end his unfair behaviour of dumping effort onto other people.
The solution is that he spends more time scoping the size of the PR so that it’s reviewable and understands the code he’s submitting well enough to have discussions about it. And that he does so human to human so that they can come to mutual understanding.
Less WIP is better for the throughput. If you saturate all the review bandwidth you're just wasting your time creating more PRs, the time would be better spent helping others get their PRs merged.
> Well, what's the solution here, he should ship less stuff?
The solution is in the title - he wants human attention, he needs to demonstrate human effort.
He isn’t shipping anything. Asking for code review is not shipping.
This is the complaint:
> he doesn't make it easy for the team to look at.
He has traded readability for volume. The lack of readability is causing him to ship less. This was a bad trade because the readability is the bottleneck not the code creation. He should improve readability.
>> the readability is the bottleneck not the code creation. He should improve readability.
See this is where I think LLMs can actually improve software engineering. Use them to write better code not more code. The most useful LLM at work so far is the code review bot that occasionally finds things that I missed even with a careful self review and good test coverage.
We should be prompting the LLMs to review our hand written code for security, correctness, style, maintainability, etc., and then use human review for good design and sanity checking. The bots can do things like hold all the C++ correctness rules in their context and apply them sometimes better than even a human expert.
The solution is to merge more of his PRs on the condition that he takes at least partial responsibility for any resulting problems.
That's not how anything works. Even if he says he's going to take responsibility, when the customer call comes in at midnight you're going to be the one fixing his problems.
The reviewer gets to merge the PR so their name appears on all the great new features and they are credited for them. That would end his unfair behaviour of dumping effort onto other people.
OR - he gets a review for every review he does.