> You wrote some code, they don't understand it. So the ball's in your court
"The ball's in your court" is the part that is not in agreement. If it's that simple, then by saying "OK" the ball is back in your court.
I spent a lot of time in university. The one thing teachers don't want to hear is "I don't understand." Quite a few professors would give out information on how to handle it. Do not say "I don't understand," Start talking about what you do understand and what the gaps are.
> Maybe your code is too complex, or maybe it needs a comment explaining what's going on, or maybe the particular reviewer just needs some missing background info. Or maybe you don't know what's best and can ask them for help/advice.
As the author, I do not want to start playing a guessing game. And your list is way too short. I could sit for an hour and think of many more scenarios. I'm not going to explore all of them in the hope that I hit the main problem you are having. If it is too complex, say so with some explanation. If you want a comment describing this at a higher level, say so. Why should I ask for help? I have code that solves the problem. I do care about readability, of course, but it's not clear whether my code is the problem or your skills are the problem.
Your comment very much reads like what your parent is complaining about:
"A good code review is not a series of walls or hoops for the writer to jump through. It’s a critical discussion conducted by a team. Code reviewers should be collaborators not obstacles."
You have an obligation as a reviewer. Your obligation is not limited to asking questions or making statements. I know a lot of code reviews aren't structured as such, but the best code reviews are the ones where the reviewer and author have equal power. The worst ones are where the reviewer has the power to prevent a commit/merge because he/she wasn't happy with all the answers that were given. In my experience, the former are the ones where reviewers quickly learn not to give statements like "I don't understand."
> The reviewer didn't spend too long trying to guess which solution is best. They just gave you what you need to know to find the best solution.
And this is precisely the problem. I think I picked the best solution. If you don't like it, as a minimum suggest an alternative.
Now in reality, if I got such a statement, I probably would respond with "What aspect of the code is causing you trouble?" It's not a defensive response, nor is it an attack on you. And this is fine. But I could have skipped it altogether if you had led with this.
"The ball's in your court" is the part that is not in agreement. If it's that simple, then by saying "OK" the ball is back in your court.
I spent a lot of time in university. The one thing teachers don't want to hear is "I don't understand." Quite a few professors would give out information on how to handle it. Do not say "I don't understand," Start talking about what you do understand and what the gaps are.
> Maybe your code is too complex, or maybe it needs a comment explaining what's going on, or maybe the particular reviewer just needs some missing background info. Or maybe you don't know what's best and can ask them for help/advice.
As the author, I do not want to start playing a guessing game. And your list is way too short. I could sit for an hour and think of many more scenarios. I'm not going to explore all of them in the hope that I hit the main problem you are having. If it is too complex, say so with some explanation. If you want a comment describing this at a higher level, say so. Why should I ask for help? I have code that solves the problem. I do care about readability, of course, but it's not clear whether my code is the problem or your skills are the problem.
Your comment very much reads like what your parent is complaining about:
"A good code review is not a series of walls or hoops for the writer to jump through. It’s a critical discussion conducted by a team. Code reviewers should be collaborators not obstacles."
You have an obligation as a reviewer. Your obligation is not limited to asking questions or making statements. I know a lot of code reviews aren't structured as such, but the best code reviews are the ones where the reviewer and author have equal power. The worst ones are where the reviewer has the power to prevent a commit/merge because he/she wasn't happy with all the answers that were given. In my experience, the former are the ones where reviewers quickly learn not to give statements like "I don't understand."
> The reviewer didn't spend too long trying to guess which solution is best. They just gave you what you need to know to find the best solution.
And this is precisely the problem. I think I picked the best solution. If you don't like it, as a minimum suggest an alternative.
Now in reality, if I got such a statement, I probably would respond with "What aspect of the code is causing you trouble?" It's not a defensive response, nor is it an attack on you. And this is fine. But I could have skipped it altogether if you had led with this.