「公式を読む」話と、その派生 - 習慣づくりとバッドパターン -

※元になったものがQiitadonのトゥートなので、口語体になっています。
公式を読む話と勉強の習慣についての話です。

きっかけとなった記事とコメント

以下の記事にコメントしたところから、一連の考察がスタート。

https://qiita.com/hiraike32/items/f0a211cceb0ecc516b6c

原因-1.基礎・教科書から勉強をする習慣が無い
原因0.基礎・教科書から勉強をしたことについての成功体験が無い
ということもあるのかな、と思いました。
私は30人ほどのインターン生の面倒を見たことがありますが、彼らはほとんど業務でのプログラミングが初めてであった一方で、概ね公式を英語の原文で読む習慣が身についていました。それは、意味を感じるとかいう以前に、そもそも勉強するということについて「基礎的かつ正確な記述を参照すること」という認識を持っているか否か、という要素が大きいように感じました。(彼らの多くは、受験勉強や大学の勉強などを通して勉強をする習慣がよく身に付いていました。)
また、元々そうした習慣が無かったとしても、そうした勉強についての成功体験があれば、つまり公式を読んで正しかったと思えるような経験があれば、自然と公式を重視すると思います。従って、公式を読んでもよくわからなかったり、雑な謎入門記事で”成功”してしまったりすることで、長い目で見ればおそらく最も期待値の高いであろう公式をまず読むという事をせずに、その人の中では正解のように見える方法(=公式を読まない方法)に行き着いてしまうのかな、という事を思いました。
そこで、(原因5などにも挙げられていますが)公式を読まないことでどれぐらい時間とプログラム品質の面で損をしているかという事を伝えることも、一つの有意義な方法なのかな、という事を思いました。読めない理由も大事ですが、読むメリット・読まないデメリットも大事ですね。

読めないことよりも、単純に読む習慣ができていない事の方が本質的な問題なのかもしれないと思った。
単純に勉強の仕方が身に付いていないということなんだよな…「自分の目の前の仕事」にピンポイントの内容が存在すると思って検索する、的な。
世の中には信頼できない情報の方が多い(あるいは、正確には背景を描けていないものや、中途半端に伝言ゲームで劣化した情報の方が多い)とか、そういう事を教育すべきなんだろうなという気もする。

たとえばVueで

Vueでは、実は最初にとても良いことが書いてある。
https://jp.vuejs.org/v2/guide/

はじめに
公式ガイドは、HTML、CSS そして JavaScript の中レベルのフロントエンドの知識を前提にしています。フロントエンドの開発が初めてであるならば、最初のステップとして、フレームワークに直接入門するのは良いアイデアではないかもしれません。基礎を学んで戻ってきましょう!

つまり、そういう事なんだと思う。
勉強の習慣がある人達は、一足飛びにいきなりやりたいことをすべてできる訳ではない、という事もすごくよく知っていた。だから逆に、実現できる前提で調べれば確かに実現するという方法があることを実感した時に、すごく生き生きしてたんだけど。

機械語との比較

(昔の)機械語は覚える事の量はJSと比べるとだいぶ少ないと思うんだけど、基礎知識が膨大すぎるからこそ、まずは基礎から始めるんじゃないのかなあという気がする。
いきなりディープラーニングとか言っても、真面目に勉強する人はまずは線形代数とかその前のところから数学やり直すでしょ、というのと一緒かなと。
華やかに見えれば見えるほど、最低限の事は基礎から積み上げないと難しいかなと。
いくら建築設計好きでも、いきなりビルは建てられないので、いろんな建物を書いて考えて練習してからのビル建て。

目的と手段を混同しないこと…知識の有無に限らず

一応、誤解のないように補足をすると、ディープラーニングの結果を単に応用したいだけなら、画像認識APIとか言語解析APIとかはあるから、それを利用すればOK。
ただ、その場合は「ディープラーニング」という切り口での選定ではなくて、「画像認識できるもの」という観点でGoogle Vision APIとかそういうのを選定すると思うので、目的と手段の関係性が正しければ、あまり混乱も生じないと思う。先にディープラーニングと決めなければ、誤りは生まれにくいというか。Vueもそういうことなのかなと。目的がはっきりしているなら、目的ベースで探して、多くの場合はVueでないところに触りやすいものが存在していると思う。

またまたVueで

Vueに関してでいうと、そもそも公式のチュートリアルはビルドとかしなくてもできるので、JSの黒魔術要素をかなり排したものが公式に存在する。(TSとかWebpackとかBabelとか、当然全く触れる必要がないけど、TODOみたいなものは作れるし、Firebaseとも組み合わせられる)

初心者が vue-cli で始めることは推奨しません
Scrimba の一連のチュートリアル を利用可能です。

インターン生は、ほとんどJSを触ったことない人ばかりだったけど、ミニマムなところからMDNやチュートリアルを読ませると、その型に従ったきれいなものは書けた。
そうやってできる幅を広げていくのがおそらく最短で、優秀だと数日、優秀でなくても一ヶ月あればチュートリアルはできると思う。

「型に従ったきれいなものは書けた」の部分の補足(仕事というものについて思うこと)

現場レベルって、例えば水道の工事とか電気工事とかで考えると、一つ一つの工事に必要な作業のうちのいずれかを完全に正確にできるのが現場レベルで、全てのことを80%できるのは実は現場レベルではない。
ネジを完璧に締められる人は、しょぼくても最後までやりきれる仕事があるけど、全部の事を80%までしかできないと、2段積んだ時の完成度は0.80.8=64%で、3段積むと0.80.8*0.8=51.2%

もちろん、部分的に感覚や雰囲気は確かに存在して、それらをすべて排除することは出来ないとは思うんだけど、きちんと根拠を持って正しいパーツを一つ一つ積み上げることが大事。
※ただし、調べずにできることが80%でも、調べながらでも100%できるならそれはそれでOKなので、若干ニュアンス的に難しいけど…

バッドパターンが存在することと、それがもたらすもの

プログラミングのバッドパターンが、以下のリンクのような実際に書くところだけじゃなくて、公式を読むような基礎的な勉強方法の部分にもあるという事なんだ。
https://qiita.com/hirokidaichi/items/27c757d92b6915e8ecf7

よく、少なくとも部分的には私よりも知識を持っているような人で、それがうまく仕事に生きない人がいるなあと思っていた。elmの知識とかラズパイの知識とかそういうのを求めてて、部分的には実際に知識もあって、私からするとそれだけ材料あれば何でもできるのではという感じがするのに、意外とできないタイプの人。
そのタイプの人は、そもそも目的と手段の取り違えが発生してる事が多いし、それゆえに対象をよく知らない状態で勝手に対象に期待するし、その期待に裏切られたらあっさり勉強をやめる
つまり単純に基礎的な勉強方法が身についてないんだなと思った。

これが、割合的に東大生が使いやすかった事にもつながっているんだな。もちろん個人差はあるんだけど。
基礎を一次情報に従って調べて実践するという基本的なフォームができてるかできてないかの差が大きい。おそらく。

単にプログラミングだけが苦手なパターンと、プログラミングだけじゃなくて様々な生活の本質的な部分で類似の失敗をしているパターンがあるけど、勉強方法や目的と手段の取り違えはプログラミングだけじゃなくて生活の広範囲に影響するので、ダメージが大きい。
逆に言えば、その部分を本質的に改善すれば、細かいガジェットの知識とかその他興味のあることの知識は私なんかよりも全然ありそうだし、だいぶバラ色の人生が待っているようにも見える。
これは、辛抱強さの問題ではない。というのは、好きな事はいくらでもやれるから。
辛抱強さではないけど、モチベーティングなんだな。最初のモチベーションがふわふわしてるだけなら、続けばいいんだけど、期待と実際の違いがわかった時にガクッとやらなくなる感じ。それがつらい。

私もそのパターンで捨てた物事は、主に小さい時に結構沢山あるんだけど、しばらく頑張ればできるという経験をいくつかしたから、”期待外れ”というのでモチベーションを無くすことは少なくなった。

なるほど。(高性能ポンコツに通じるような)「これじゃない、これじゃない…」を繰り返して結局身につかない感じのサイクルを繰り返している印象を受けているんだけど、その理由が分かってきた気がする。勉強の方法、勉強の仕方に通じている。
自分の期待する形で情報は落ちてないし世界も整ってない、その中でどう振る舞うか。とりあえず基礎を一通り黙ってみにつけるか、別の理想郷を探すか、その辺の差が公式を読むか読まないかにもつながっている、という感じ。