達人プログラマー 第2版 — 教えにくいことほど、差が出る
プログラミングを教えていると、質問の種類が2つに分かれることに気づきます。
ひとつは「この書き方が分からない」。これは調べれば答えが出ます。もうひとつは「どっちがいいですか」。こちらは答えが1つに決まりません。
後者に答えるとき、自分が何を根拠に喋っているのかが曖昧でした。経験からそう思う、としか言えない。教える側としては、そこが一番あやしい部分でした。
「書き方」ではなく「進め方」を教えるときに何が足りなかったか、この本がそこにどう効いたか、そして教材として使うときの注意点です。
教えやすいことと、伝えたいことがずれている
教材にしやすいのは、正解のあるものです。文法、関数の使い方、エラーの読み方。手順が決まっていて、できたかどうかも判定できます。
ところが、実務で差が出るのはそこではありません。
| 教えやすいこと | 実際に差が出ること |
|---|---|
| 書き方を覚える | どこまで作り込むかを決める |
| エラーを直す | 同じエラーが起きない形にする |
| 言われたとおりに作る | 言われていない前提を確認する |
右の列は、教科書の形になりにくい。正解が状況によって変わるので、「こうしなさい」と言えないからです。
この本は、右の列について書かれている
この本が扱っているのは、ほぼ全部が右の列です。原題は The Pragmatic Programmer で、日本語版は第2版が出ています。
言語の解説はほとんどありません。代わりに、仕事の進め方そのものが並んでいます。同じことを2か所に書かない。壊れたまま放置しない。自分の道具を選んで使い込む。見積もりをどう扱うか。
ひとつひとつは短く、独立しています。順番に読まなくても成立する構成なので、必要なところだけ拾えます。
助かったのは、それぞれの考え方に名前が付いていることでした。
「同じ情報を2か所に置かない」という話は、経験があれば誰でも何となく分かっています。ただ、名前が無いと会話のたびに一から説明することになります。名前があると、一言で指して、その先の話ができます。
教える側として、いちばん効いたところ
この本を読んで、自分の説明の仕方が変わった部分があります。
それまでは「こう書くといい」と結論だけを渡していました。読んだあとは、「こうすると後で何が起きるか」を先に話すようにしています。
たとえば、同じ設定値を2か所に書いた場合。その場では動きます。問題が出るのは、片方だけ変えたときです。「今は動くが、変えるときに壊れる」という形で伝えると、納得の仕方が変わりました。禁止として覚えるのではなく、理由として残ります。
ただし、この本の内容は失敗した経験があって初めて刺さるものが多いです。
「壊れたまま放置しない」と書かれていても、放置して痛い目を見たことが無ければ、当たり前の標語として素通りします。初学者にそのまま渡すと、たぶん響きません。
このサイトを作るときにも使った
教える側の話だけではなく、自分の作業にも効きました。
このサイトでは、ドメイン名やRSSの場所といった値が、いつの間にか複数のファイルに散っていました。どれも画面に出ない値で、書き換え漏れがあっても見た目では分かりません。
気づいたときに1か所へまとめたのですが、その判断の速さは、この本で読んだ考え方が下敷きになっています。「今は動いている」を理由に放置しない、という部分です。
教材として使うときの注意
そのまま課題図書にするのは向いていないと考えています。読ませるなら、ある程度の期間、自分で作って詰まった経験があってからのほうが効きます。
自分の場合は、必要な項目だけを取り出して、目の前の作業と結びつけて話す使い方をしています。本そのものを渡すのではなく、本から取った言葉を渡す形です。
達人プログラマー（第2版）Andrew Hunt・David Thomas 著／村上雅章 訳／オーム社
- 使っている理由
- プログラミングを教えるとき、「どちらがいいか」という質問に経験だけで答えていた。書き方ではなく進め方の部分を、根拠を持って伝えられるようにしたかった。
- 効いた点
- 仕事の進め方そのものが短い項目に分かれていて、順番に読まなくても成立する。それぞれに名前が付いているので、指導のときに一言で指して先の話へ進める。
- 合わなかった点
- 失敗した経験があって初めて刺さる内容が多い。初学者にそのまま渡しても標語として素通りするので、目の前の作業と結びつけて一部を取り出す使い方が向いている。
リンクは広告を含みます。
今回の学び
まず、教えにくいことほど、実務では差が出るということ。正解のあるものは教材にしやすいのですが、そこは調べれば済む部分でもあります。時間をかけて伝える価値があるのは、判定しにくいほうでした。
次に、考え方に名前が付くと、会話が短くなること。感覚として持っているだけだと、毎回説明が必要です。名前があれば指し示せて、その先の議論に進めます。
そして、結論ではなく、後で起きることを渡すこと。「こう書きなさい」は覚えるだけで終わりますが、「こうしないと何が起きるか」は判断の材料になります。次に似た場面が来たとき、自分で決められる形になっていました。
関連記事
フロントエンドエンジニア養成読本 — 知らないものは、検索できない
フロントエンドの知識が、断片のまま溜まっていました。 必要になるたびに調べて、動いたら次へ進む。それを繰り返していたので、個々のやり方は知っているのに、全体のどこに位置する話なのかが分かっていない状態でした。 この記事で […]
リーダブルコード — 引き継ぐ側に回って分かったこと
自分で書いていないコードを直す仕事が続いた時期がありました。書いた人はもういません。仕様書もありません。あるのは動いているコードだけです。 読んでいて思ったのは、これを書いた人を責めても何も進まないということでした。同時 […]
7日間でハッキングをはじめる本 — 守り方は分かる。何から守るのかは分からない
脆弱性の監視を作ったあと、読んでいた情報が全部守る側のものだと気づきました。対策は並べられても、どれを先にやるかは攻撃の手順を知らないと決まりませんでした。