Let's think about writing for a moment... Many forms of writing heavily benefit from having a clear goal to start, followed by an outline, followed by many iter

Let's think about writing for a moment... Many forms of writing heavily benefit from having a clear goal to start, followed by an outline, followed by many iterations of the content. One analogous challenge with code reviews occurs when the reviewer can't quickly see something like a (a) goal and (b) outline. Without these two, it can make it hard to "navigate" what kind of feedback would be helpful. a. In many cases, the reviewer and reviewee might think they have the same goal, but this is often subtly or blaringly wrong. Even people in the same organization can serve different masters. b. Different software cultures have different ideas of planning, outlines, design documents, whatever. Some cultures wing it. Some people keep this kind of thing in their head, but it is hard to quickly share your head with someone else. Without some notion of the contours of the problem, how can you properly assess the the code?