「エンジニアの知的生産術」 を読み、今の自分にとって大切な考え方をピックアップ！
第1章. 新しいことを学ぶには
「学び」に対して、「やる気」は強い原動力。
ただし、「やる気」はリソースと考えて、今やる気が出ないものに対しては無理に学ぶことをあきらめて、よりやる気の出るものに気持ちを切り替える
→ この戦略の方が時間を有効的に使える
知りたいところから学ぶ
前提条件
- 目標が明確化されている (ex: Pythonのリストと多プルの違いについて知る)
- 目標が達成可能である
- 大まかに全体像を把握している (全て理解するのではなく情報がまとまっているサイト、本などを知ることであとから何度でも参照すればよい)
本を1ページ目から読んでいくのではなく必要なところから飛び飛びに読んでいく(遅延評価的勉強法)
- やる気の出るところから！
- 後で断片的に組み立てることにより自分なりの情報処理が入るため記憶がしやすい
YANGIの原則(気になるものだけを学ぶ)
- 時間は貴重であるため「必要になるかも」で学び、必要なかった場合は時間の無駄になる
- 必要なもの = やる気の出るものとは限らない。今の自分にとって気になるものだけ学ぶ
- 全体を通して読む必要はない! 面白そうなところをつまみ食いして先人の知恵を学べば十分
知りたいことが具体的に決められない場合
この状態は、何から学べば効率が良いかを判断する材料が揃っていない。
→ わからないことの効率を考えるより片っ端から情報を手に入れていく必要がある
※ただし、「必要なところだけ手を動かす」が出来ないかを考えることで効率を上げる
- 目標のゴールを近く設定する
- プログラミング写経は、既存の知識と異なる部分を学ぶ際にやればよい = 自分には写経する必要がないと感じる時期が来た場合は、新しい挑戦をしていないと思った方がよい。
抽象化の必要性
抽象化とは、具体的なものから特に体制つな部分だけ抜き出すこと。
抽象化によって、解決方法のパターンを得ることで、新しい問題を解けるようになる。
パターンを発見する
具体的な事例を集めて、共通した部分があればそれは非常に有用なポイント
→ パターンを抜き出して抽象化すればいろいろな要素に活用できる
ソースコードの歴史から学ぶ
ソースコードは基本的に「今」の「how」の情報しかない。
- 過去の情報から「なぜ変更する必要があったか」「なぜこの方法を選んだのか」を知ることにより、今のソースコードの必要性が理解できるようになる。
- コミット履歴を見ることは、whyの意図を知ることが出来るかも
本から学ぶ
本は、著者の具体的な経験から書かれている。
→ いろいろなジャンルの本からの情報・知識をもとにパターンを見出し、活用する必要がある。
理解を検証する
自分がわかっていないことに気付くことが出来なければ学びを進めていくことが出来ないため、理解を検証することが大切。
- 自分の言葉で説明できるか?
- 自分の経験に基づいた具体例を挙げることが出来るか?
- 自分の目的を達成するためにその知識を使えるか?
↑ 3つが出来っていれば「自分の知識」