A backup developer is not a pair programming partner. The backup developer is the “go to” person if the developer that owns a component becomes unavailable for some reason like going on vacation, sickness, or leaves the company. If the primary developer leaves the company, then having a backup developer provides someone to go to in the short-term until a new developer can be brought on board. The backup developer would then be in a position to mentor and train a new developer in the old developer’s components.
The backup developer spends perhaps 5% of his time per week on average reviewing changes to the requirements, design, code, and test cases for the primary developer. He participates in the requirements, pseudocode, and code design reviews. Review of the pseudocode and code should only take place after it has been checked into the repository. The primary and backup developers should never back each other up.
If the backup developer believes that there are missing requirements, the pseudocode or code does not meet the requirements, is poorly designed, has defects, etc. then he should meet with the primary developer privately and explain his concerns and perhaps offer a suggestion or two. If after meeting with the backup developer the primary developer believes there is no problem and/or is simply a matter of style, then the matter should be escalated to the group lead or manager by the backup developer if he is still convinced that there is a problem.
Style issues like using an algorithm instead of 3 layers of inheritance or using too many nested loops should never be used as the basis to initiate action. The main point the backup developer should consider before initiating action is whether or not the solution meets the requirements or not, has defects, or is so poorly written that it would be too difficult to maintain.