悪いフィードバック耐性をつけないとひよこエンジニアから抜け出せない

何かを上手くなりたいときはフィードバックを早くもらえるような習慣を身につけると良い。

プログラミング初学者が陥りがちなこと

最初から完成形を作ろうとしてしまう。完成形には次のものが含まれる。

実装後にどのように動けば良いか（仕様）
どのようにプログラムを作るか（設計）
どのように動作を確かめるか（テスト）
プログラムを書くには何が必要か（タスクリスト）

4つを同時に考えてしまうので頭が混乱する。混乱すると手が止まってしまう。すると時間ばかり経って焦り、さらに頭が混乱する…という具合で状況が悪化する。

また、「自分の考えたことが予想通りいきそうか」を確かめるタイミングが遅い。具体的にはプログラムを書いてから動かす・テストコードを実行するまでの時間が長い。

結果、着手・実装・質問しに行くのを決める・質問をするまで全てに時間がかかる。進捗が悪いと周囲からあれこれ言われてしまう。焦ってしまうので思考がうまくできず更に状況が悪くなる。

なぜ完成系を作ろうとしてしまうのか

悪いフィードバックに対する耐性が低いため。具体的には実装どおりに動かないことや、自分の意図通りに進められないなどが当てはまる。テストの失敗やエラーの出力も怖がってしまう。

悪いフィードバック耐性が低いと、最初から完成系を作りたい気持ちが働いてしまう。結果、何をどう作るのかを実装の詳細と一緒に考えてしまう。全ての問題を一度に解決しようとするが、能力が不足しているためできない。それが悪いフィードバックになるため「完成系に近づけないと」という焦りが生まれてしまう。

対策

初学者かつ悪いフィードバック耐性が低い兆候が見られる場合、最初はペアワークをしてした方が良いと感じる。ペアワークでは、次の内容に一緒に取り組む。

何ができれば完成か？のゴールを明確にする
ゴールを確かめるためのTODOリストを立てる
TODOリストを元にTDD（テスト駆動開発）的に進める

可能な限りTDDで進めるのがポイントだと感じる。TDDはテストを失敗させてから成功する進め方をする。初学者に取ってはテストの失敗は悪いフィードバックである。わざとテストを落としてから実装することで、「実装していないんだからテストが通らないよね」という風に認識を変えてもらう。

TDDで悪いフィードバック耐性をつけると、普段の仕事でも慌てなくなることが多い。意図通りの悪いフィードバックを作り出すのがポイントなのだと感じる。

また、TDDはTODOリストを元に進めて行くやり方をとる。TDDで進めることで、何をするか？とどう実装するか？を分けるようになる。実装の段階では実装だけに集中できるので、早く終わる。

試したけど上手く行かなかった対策

最初はリモートでできないか？と思いリモートでペアワークした。しかし、改善されなかった。リモートでは「悪いフィードバックを受けても平気だよね」という態度を示すのが難しい。また、トレーニー側が焦っているかも読み取りづらい。操作を認識するのにタイムラグがあるためTDDで進めることを強制するのも難しい。なので対面でないと難しいと感じた。

また、リモートで作業するとき時間を決めて必ず提出させるようにしたが、これも効果がなかった。締め切りがあればとにかく前に進めるだろう、結果フィードバックを受けにくるだろうと考えた。

実際は、ずっと手が止まってしまい「終わりません」とだけ言ってくることが繰り返されていた。止まっていた分の経験量が減るため時間がかかる割に身につかないことが続いた。