Return to Answer

It is very important you make code that satisfies what your Lead / Management request. Any other detail would just be a "nice to have". If you are an expert (read that: "if you are not a Junior developer") in your field, then you are "eligible" to address minor issues you find along the way without consulting your leaders every time.

If you think something is wrong and you are relatively expert in your field then chances are high your are right.

Here are some statements that could be useful to you:

• I was requested to do X, code reviewer suggests also doing Y, should I do it or should I move on to more important stuff
• You are suggesting Y to me, so can you figure out at least one test case that would catch that behaviour so I can test it? I believe that code won't be called.
• Maybe shouldn't we develop a safe fallback for uncovered cases first? So we catch them early and fix on the go so we can focus on more important stuff.
• Ok, while I am implementing Y, could you be so kind to write some test cases for it so we get that thing done once and for all?
• I was requested to do X, I think I could do Y unless there are other priorities, next time why don't you file a feature request instead of putting it as a review comment on my code? At least we can hear further opinions from other team members on that feature before implementing it (generally any important stuff should be a feature and should be handled by more than one person; usually code review should be about reviewing code and solutions approaches, the rest is bugfixing and features.)

Do you seriously think that the attitude of your reviewer is damaging the project or do you think he's right most times (except maybe sometimes he just makes minor errors in evaluation and exaggerates that)?

Too me it sounds more like he's writing stuff that does not belong in a code review, which is bad practice because it makes it harder for everyone to track stuff. However I don't know what other review comments he made, so I can't say anything on other cases.

In general try to avoid both of the following:

• You are not doing what has been requested
• You make your reviewer feel dumb

If he's actually reviewing your code, it's because management trust him more than you.

It is very important you make code that satisfies what your lead / management request. Any other detail would just be a "nice to have". If you are an expert (read that: "if you are not a junior developer") in your field, then you are "eligible" to address minor issues you find along the way without consulting your leaders every time.

If you think something is wrong and you are relatively expert in your field then chances are high you are right.

Here are some statements that could be useful to you:

• I was requested to do X, code reviewer suggests also doing Y, should I do it or should I move on to more important stuff?
• You are suggesting Y to me, so can you figure out at least one test case that would catch that behaviour so I can test it? I believe that code won't be called.
• Maybe shouldn't we develop a safe fallback for uncovered cases first? So we catch them early and fix on the go so we can focus on more important stuff.
• OK, while I am implementing Y, could you be so kind to write some test cases for it so we get that thing done once and for all?
• I was requested to do X, and I think I could do Y unless there are other priorities. Next time why don't you file a feature request instead of putting it as a review comment on my code? At least we can hear further opinions from other team members on that feature before implementing it (generally any important stuff should be a feature and should be handled by more than one person; usually code review should be about reviewing code and solutions approaches; the rest is bug-fixing and features).

Do you seriously think that the attitude of your reviewer is damaging the project or do you think he's right most times (except maybe sometimes he just makes minor errors in evaluation and exaggerates that)?

To me it sounds more like he's writing stuff that does not belong in a code review, which is bad practice because it makes it harder for everyone to track stuff. However I don't know what other review comments he made, so I can't say anything on other cases.

In general try to avoid both of the following:

• You are not doing what has been requested
• You make your reviewer feel dumb

If he's actually reviewing your code, it's because management trust him more than you.

It is very important you make code that satisfy what your Lead / Management request. Any other detail would just be a "nice to have". If you are an expert (read that: "if you are not a Junior developer") in your field, then you are "eligible" to address minor issues you find along the way without consulting everytime your leaders.

If you think something is wrong and you are relatively expert in your field then chances are high your are right.

Here are some statements that could be usefull to you.

• I was requested to do X, code reviewer suggest also Y, should I do it or should I move to more important stuff
• You are suggesting me Y, then you can figure out at least 1 test case that would catch that behaviour so I can test it? I believe that code won't be called.
• Maybe shouldn't we develop a safe fall back for uncovered cases first? so we catch them early and fix on the go so we can focus on more important stuff.
• Ok, in the meanwhile I implement Y, could you be so kind to write some test cases for it so we get that thing done once and forever?
• I Was requested X, I think I could do Y unless there are other priorities, why next time don't you file a feature request instead of putting it as review to my code? At least we can hear further opinions from other team members on that feature before implementing it (generally any important stuff should be a feature and should be handled by more than 1 person, usually code review should be about reviewing code and solutions approaches, the rest is bugfixing and features.)

Do you seriously think that the attitude of your reviewer is damagin the project or do you think he's right most times (except maybe sometimes he just make minor errors in evaluation and eggxagerate that)?

Too me sounds more like he's writing stuff that does not belong to a code-review, which is bad practie because makes harder to track stuff for everyone. However I don't know what other reviews he made, so I can't say anything on other cases.

In general try to avoid both of followings:

• You are not doing what requested
• You make your reviewer feel dumb

If he's actually reviewing your code, it's because management trust him more than you.

It is very important you make code that satisfies what your Lead / Management request. Any other detail would just be a "nice to have". If you are an expert (read that: "if you are not a Junior developer") in your field, then you are "eligible" to address minor issues you find along the way without consulting your leaders every time.

If you think something is wrong and you are relatively expert in your field then chances are high your are right.

Here are some statements that could be useful to you:

• I was requested to do X, code reviewer suggests also doing Y, should I do it or should I move on to more important stuff
• You are suggesting Y to me, so can you figure out at least one test case that would catch that behaviour so I can test it? I believe that code won't be called.
• Maybe shouldn't we develop a safe fallback for uncovered cases first? So we catch them early and fix on the go so we can focus on more important stuff.
• Ok, while I am implementing Y, could you be so kind to write some test cases for it so we get that thing done once and for all?
• I was requested to do X, I think I could do Y unless there are other priorities, next time why don't you file a feature request instead of putting it as a review comment on my code? At least we can hear further opinions from other team members on that feature before implementing it (generally any important stuff should be a feature and should be handled by more than one person; usually code review should be about reviewing code and solutions approaches, the rest is bugfixing and features.)

Do you seriously think that the attitude of your reviewer is damaging the project or do you think he's right most times (except maybe sometimes he just makes minor errors in evaluation and exaggerates that)?

Too me it sounds more like he's writing stuff that does not belong in a code review, which is bad practice because it makes it harder for everyone to track stuff. However I don't know what other review comments he made, so I can't say anything on other cases.

In general try to avoid both of the following:

• You are not doing what has been requested
• You make your reviewer feel dumb

If he's actually reviewing your code, it's because management trust him more than you.

It is very important you make code that satisfy what your Lead / Management request. Any other detail would just be a "nice to have". If you are an expert (read that: "if you are not a Junior developer") in your field, then you are "eligible" to address minor issues you find along the way without consulting everytime your leaders.

If you think something is wrong and you are relatively expert in your field then chances are high your are right.

Here are some statements that could be usefull to you.

• I was requested to do X, code reviewer suggest also Y, should I do it or should I move to more important stuff
• You are suggesting me Y, then you can figure out at least 1 test case that would catch that behaviour so I can test it? I believe that code won't be called.
• Maybe shouldn't we develop a safe fall back for uncovered cases first? so we catch them early and fix on the go so we can focus on more important stuff.
• I Was requested X, I think I could do Y unless there are other priorities, why next time don't you file a feature request instead of putting it as review to my code? At least we can hear further opinions from other team members on that feature before implementing it (generally any important stuff should be a feature and should be handled by more than 1 person, usually code review should be about reviewing code and solutions approaches, the rest is bugfixing and features.)

Do you seriously think that the attitude of your reviewer is damagin the project or do you think he's right most times (except maybe sometimes he just make minor errors in evaluation and eggxagerate that)?

Too me sounds more like he's writing stuff that does not belong to a code-review, which is bad practie because makes harder to track stuff for everyone. However I don't know what other reviews he made, so I can't say anything on other cases.

It is very important you make code that satisfy what your Lead / Management request. Any other detail would just be a "nice to have". If you are an expert (read that: "if you are not a Junior developer") in your field, then you are "eligible" to address minor issues you find along the way without consulting everytime your leaders.

If you think something is wrong and you are relatively expert in your field then chances are high your are right.

Here are some statements that could be usefull to you.

• I was requested to do X, code reviewer suggest also Y, should I do it or should I move to more important stuff
• You are suggesting me Y, then you can figure out at least 1 test case that would catch that behaviour so I can test it? I believe that code won't be called.
• Maybe shouldn't we develop a safe fall back for uncovered cases first? so we catch them early and fix on the go so we can focus on more important stuff.
• Ok, in the meanwhile I implement Y, could you be so kind to write some test cases for it so we get that thing done once and forever?
• I Was requested X, I think I could do Y unless there are other priorities, why next time don't you file a feature request instead of putting it as review to my code? At least we can hear further opinions from other team members on that feature before implementing it (generally any important stuff should be a feature and should be handled by more than 1 person, usually code review should be about reviewing code and solutions approaches, the rest is bugfixing and features.)

Do you seriously think that the attitude of your reviewer is damagin the project or do you think he's right most times (except maybe sometimes he just make minor errors in evaluation and eggxagerate that)?

Too me sounds more like he's writing stuff that does not belong to a code-review, which is bad practie because makes harder to track stuff for everyone. However I don't know what other reviews he made, so I can't say anything on other cases.

In general try to avoid both of followings:

• You are not doing what requested
• You make your reviewer feel dumb

If he's actually reviewing your code, it's because management trust him more than you.