Very good point and wise. I find this more applicable as a leader when reviewing designs. It's so easy to poke holes and complain, but it is hard to find the good and value that. It is worth it because I can then focus my comments on what is essential and then drive accountability to get all the details done well enough.
Is there a review system (code, design, writing, whatever) that allows you to color code chunks of what you're reviewing and has a well defined color scheme? E. G. Shades of green for mildly to very good, shades of red for mildly to very bad, and some other colors to denote confusion, etc.
It would be useful to see feedback of where you did stuff right, but allow you to focus on where you did stuff wrong. Making sure you're aware of what you did well is important both for being able to repeat it and psychologically, and as a reviewer it can help you make sure you are providing that positive feedback (a bunch of red with no green should be obvious).
Thats bit to say it shouldn't include specific comments, but sometimes there's not a lot to say about a large chunk of what you're reviewing that you're generally pleased with, but the person that produced it could definitely benefit from knowing that.
So, the best way to provide feedback is via good questions.
This is why tools like quip/gdocs can be great for design documents because I can pinpoint a detail and then ask a good question.
Most junior engineers are bright, and they can solve the (or a) problem at hand. However, the lack both experience in the field and within the domain. Questions are a great way to express concern and share experience.
For software, if they can reasonable code, then it is not so much an issue of right/wrong but "hey, what problem are you solving?" and then aligning on the right problem via questions.
The power of good questions work at every level, and you can drive a lot of good growth and progress via them.
I'm not suggesting this in lieu of questions, but in addition to. The problem with questions by themselves is sometimes it's ambiguous if it applies to a small portion or a larger portion. Also, questions are not always a good way to indicate doing something right, and any good review will also highlight what was done well.
In the end, it's an additional channel of information, which may expose miscommunication on either side. I don't think it's that uncommon to have a comment next to something that the reviewer might think should cover a larger portion of the work than the creator thinks, either because it's unclear, or the creator slightly misinterpreted what the reviewer meant and didn't see how it applied.
Providing structure that requires active categorization of all of a work (or all of it that's being reviewed), even if it's just to mark it the equivalent of "eh, no real comment" removes ambiguity. If for nothing else than because different reviewers have different standards, and some will mark and question everything, and you can assume anything left unmarked is good or better, and some will only mark egregious stuff, and the rest can be considered to range from mediocre to excellent, which isn't as useful if you goal is also to foster improvement.
> The power of good questions work at every level, and you can drive a lot of good growth and progress via them.
Good questions means well defined questions, and I think anything that could make those easier to output by default (or reduce the minimum quality) might be extremely beneficial.
