This is very profession specific..

But browsing code and reviewing code are two entirely different activities.

When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time. Are you helping to pass a review, or helping him to get past a small bump in the road?

If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.

If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.

If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.

This is very profession specific..

But browsing code and reviewing code are two entirely different activities.

When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time. Are you helping to pass a review, or helping him to get past a small bump in the road?

If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.

If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.

Make it clear you do not have all the answers. This is where you both had problems: they were treating you as an authority, an authority that could be pliable. Don't be the authority, and you can be as pliable as you want. Or be the authority, and expect nothing less than for them to respect it.

If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.

This is very profession specific..

But browsing code and reviewing code are two entirely different activities.

When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time.

If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.

If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.

If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.

This is very profession specific..

But browsing code and reviewing code are two entirely different activities.

When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time. Are you helping to pass a review, or helping him to get past a small bump in the road?

If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.

If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.

If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.