技術書の読み方も、難しい

技術書の読み方っていう技術書が必要
・基本は拾い読み、全然読もうとしない
・コードサンプルを動かしたり、メモしたり、感想をまとめるとかアウトプットが理解が定着する
・複数人で読むと、違う見方が得られてより理解が深まる
・同じジャンルを並行で複数読むと、違う見方ができる

— magnoliak🍧 (@magnolia_k_) August 15, 2019

市販の技術書、薄めの本でも少なくとも200ページくらいは有って、「これを全部読むのか？」という気になる。分厚いと、1000ページ超え、上下巻で2000ページ超え…みたいなものも有って、これを頭から読み続けるのは容易なことではないです。

独学で技術を学ぶ時に、まずこの厚さの心理的な壁って有りますよね？

最近は技術書典などの技術同人誌の盛り上がりで、所謂「薄い本」もたくさんけど、一般の人がいきなり入手するにはハードルはまだ高いです。

というわけで、先日冒頭に有るようなツイートをしたら、それなりに反響が有ったので、きっと皆さんの思っている感覚と一致したのだと思う。

とにかく一番最初の…誤字があるけど…「基本は拾い読み、全部読もうとしない」を心構えに読み始めるといいと思う。

とはいえ、一回くらいは言語系の入門書で、全部のサンプルコードを実際に動かす、自分なりに変えてみる…みたいなのはやった方がいいと思う。そうすることで「技術書の読み方のコツ」みたいなところが分かる、というか、特に言語系は、その実行系の中の閉じた世界なので試しやすいし、結果も分かりやすい。

例えば、デザインパターンや、アンチパターン集を読んで、それがすぐに身につくか？というとそんなことは無い。それらは過去の膨大な経験に裏打ちされた知見の塊なので、それを理解するためのバックボーンが少しでも無いと、「ふーん」となってしまうか、逆に変に取り入れすぎて「教条主義的」になってしまう危険がある。

次に「テスト駆動開発」や、「Scala関数型デザイン&プログラミング」のような、実際のコードを元に、パラダイムシフトを経験させる系の本も有効でしょう。

とはいえ、“技術書読んだら勝手に技術力が上がる訳じゃ無い”ので、気楽に行きましょう。

言語入門系、開発思想系、ライブラリ・ツール系、インフラ系、色々とありますが、オープンソースやクラウドの普及で実際に動かせる環境へのアクセスが非常に容易になった現代、まずは実際に動かしてみることが一番の近道なのです。