私の経験を説明し、そこから「戦略」を引き出すようにします。
私はかつて完全な非プログラマーとペアプログラミングしました。彼は、開発したソフトウェア製品の主題に関する専門家でした。それどころか、問題の領域での経験はありませんでした。また、彼は現時点で私のスーパーバイザーでした(これは奇妙に聞こえるかもしれませんが:)
この方法論の主な利点は、彼の知識領域から多くの事柄の実装を説明する必要があったことです。したがって、実装の正確さとプロセスの理解を確保しました。
もう1つの利点は、作業に集中できることです。気を散らすことはありません(ははは、上司の前でTwitterを開くことを想像してください)。
しかし、ティーブレイクでさえ「仕事から気をそらす」ものになったので(時には彼の観点からではなく、ブレイクなどを求めるのは不便でした)、それは時には非常に威圧的でした。
したがって、入力されたコードをほとんどレビューできなかったため、これは実際にはペアプログラミングではありません。ただし、(少なくともしばらくの間)健全な戦略であるように見えました。開発方法論(つまり、OOPパターンのような複雑なソフトウェア設計手法は含まれていなかった)と主題の両方が比較的単純だったため、最終的にはまったく機能しました。これは、コンパイラを開発する必要がある場合には機能しません。プログラマーではないオブザーバーが明確に定義された小さな作品の開発プロセスに参加している場合でも、それはまだ機能すると考えています。たとえば、「与えられたアルゴリズムによってYとZからパラメータXを計算する」関数のプログラミングを見てもらうことは問題ありませんが、システム設計プロセス全体(ソフトウェアアーキテクチャの開発、つまりクラス、
「配列とは何か」を説明する必要はないので、彼が基本的なプログラマーのスキルを持っている場合は、さらにうまくいくと思います。
それが役に立てば幸い :)