Move content around to bring code review together and benefits together

source/standards/pair-programming.html.md.erb

@@ -20,10 +20,6 @@ Studies show that [the reduction in defect rates](https://www.sciencedirect.com/
 The continuous discussion and review that pairing introduces, compared to a non-collaborative approach, results in better designs with fewer mistakes.
 [Another study](https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF) found that pair programming reduces development and staffing risk, enhances technical skills and improves team communications.
 
-On codebases where changes require an additional review, which is the vast majority of codebases at GDS, a pair can self-review their work; however you should follow your program’s own guidance around required reviews first.
-A pair working independently, and able to self-review their work, is going to context-shift considerably less than a person working alone.
-[Reducing the amount of context-shifting](https://blog.ninlabs.com/2013/01/programmer-interrupted/) will enable the pair to focus, and therefore be productive, for longer periods of time.
-
 Pair programming is a practical way of building collective code ownership between members of the team.
 Distributing the understanding of the service being built means that teams are more resilient to people being ill, on leave, or leaving GDS, and as such are less likely to have delivery hiccups from sudden loss of expertise.
 
@@ -64,16 +60,16 @@ People in teams that have embraced concepts like [psychological safety](https://
 
 ## Reviewing code as a pair
 
-The standard approach to code review in GDS is that teams should use a pull-request (PR) process to ensure that all code is reviewed by a second pair of eyes.
-Some teams allow PRs worked on in a pair to be approved by one of the members of the pair, rather than ask for a review from an external third person.
+The standard approach to code review in GDS is that teams should use a pull-request (PR) process to ensure that all code is reviewed by another person.
+A pair can approve their own PRs on codebases where changes require an additional review, which is the vast majority of codebases at GDS.
 
 This has several benefits, such as:
 
 - speeding up the flow of work.
-- enabling the pair to move on to another task without context switching.
+- enabling the pair to move on to another task without [context switching](https://blog.ninlabs.com/2013/01/programmer-interrupted/).
 - avoiding a third person having to context switch to review the code.
 
-However, teams should adjust their policy on this approach depending on the risk tolerance of their team, service, or programme.
+However, teams should adjust their policy on this approach depending on the risk tolerance of the codebase, team, or programme.
 
 ## Further reading