達人プログラマー 第2版 — 教えにくいことほど、差が出る

プログラミングを教えていると、質問の種類が2つに分かれることに気づきます。

ひとつは「この書き方が分からない」。これは調べれば答えが出ます。もうひとつは「どっちがいいですか」。こちらは答えが1つに決まりません。

後者に答えるとき、自分が何を根拠に喋っているのかが曖昧でした。経験からそう思う、としか言えない。教える側としては、そこが一番あやしい部分でした。

教えやすいことと、伝えたいことがずれている

教材にしやすいのは、正解のあるものです。文法、関数の使い方、エラーの読み方。手順が決まっていて、できたかどうかも判定できます。

ところが、実務で差が出るのはそこではありません。

右の列は、教科書の形になりにくい。正解が状況によって変わるので、「こうしなさい」と言えないからです。

この本は、右の列について書かれている

この本が扱っているのは、ほぼ全部が右の列です。原題は The Pragmatic Programmer で、日本語版は第2版が出ています。

言語の解説はほとんどありません。代わりに、仕事の進め方そのものが並んでいます。同じことを2か所に書かない。壊れたまま放置しない。自分の道具を選んで使い込む。見積もりをどう扱うか。

ひとつひとつは短く、独立しています。順番に読まなくても成立する構成なので、必要なところだけ拾えます。

教える側として、いちばん効いたところ

この本を読んで、自分の説明の仕方が変わった部分があります。

それまでは「こう書くといい」と結論だけを渡していました。読んだあとは、「こうすると後で何が起きるか」を先に話すようにしています。

たとえば、同じ設定値を2か所に書いた場合。その場では動きます。問題が出るのは、片方だけ変えたときです。「今は動くが、変えるときに壊れる」という形で伝えると、納得の仕方が変わりました。禁止として覚えるのではなく、理由として残ります。

このサイトを作るときにも使った

教える側の話だけではなく、自分の作業にも効きました。

このサイトでは、ドメイン名やRSSの場所といった値が、いつの間にか複数のファイルに散っていました。どれも画面に出ない値で、書き換え漏れがあっても見た目では分かりません。

気づいたときに1か所へまとめたのですが、その判断の速さは、この本で読んだ考え方が下敷きになっています。「今は動いている」を理由に放置しない、という部分です。

教材として使うときの注意

そのまま課題図書にするのは向いていないと考えています。読ませるなら、ある程度の期間、自分で作って詰まった経験があってからのほうが効きます。

自分の場合は、必要な項目だけを取り出して、目の前の作業と結びつけて話す使い方をしています。本そのものを渡すのではなく、本から取った言葉を渡す形です。

今回の学び

まず、教えにくいことほど、実務では差が出るということ。正解のあるものは教材にしやすいのですが、そこは調べれば済む部分でもあります。時間をかけて伝える価値があるのは、判定しにくいほうでした。

次に、考え方に名前が付くと、会話が短くなること。感覚として持っているだけだと、毎回説明が必要です。名前があれば指し示せて、その先の議論に進めます。

そして、結論ではなく、後で起きることを渡すこと。「こう書きなさい」は覚えるだけで終わりますが、「こうしないと何が起きるか」は判断の材料になります。次に似た場面が来たとき、自分で決められる形になっていました。