エンジニアの知的生産術
https://gyazo.com/35bfe0281b062c86a15fd80d34703b95
2024/2にも読んだ
yana-gi.icon過去に読んだことは覚えていたけど、まとめていたのは忘れていた
yana-gi.icon過去に読んだときはまだ業務したことがなかったので、前回よりも納得して読めた感覚がある
第1章 新しいことを学ぶには
学びは情報収集・モデル化・検証の繰り返し
https://gyazo.com/88680ec2701eaf1778ac5e78bbc71abc
https://gyazo.com/55a0b5163fb96fa8c4f3c1aa5062c043
情報収集は箱を集めるイメージ。
情報収集だけをたくさんやっても、箱が平たくならんで行くだけで積み上がらない
モデル化・抽象化は箱を積み上げていくイメージ
土台なしに空中に箱を置こうとしても下に落ちてしまう
= 抽象的な概念だけを学ぼうとしても、ただ情報をまる覚えしてしまうだけ
https://gyazo.com/56f3ef0b72edc5bc39bdfc7fd69d8fd4
yana-gi.icon情報収集だけ・抽象的な概念を学ぶだけ、はどちらも広がっていかないんだな
実践・検証
教科書のない問に答えを出そうとしている人は誰でもそう
https://gyazo.com/7fe4a134b6190234380e89bc9dddc884
yana-gi.iconすごいと思う人も試行錯誤をしている。試行錯誤している時間って不毛に感じやすいけど、そのときはこれを思い出したい……
サイクルを回す原動力:やる気
情報収集から沸いた疑問が学びの原動力になる
受動的な学びと能動的な学び
受動的な学びしかできないままだと、周りの人は「この人は言われたとおりに動くことしかできない人だ」と考え、決まりきったやり方を繰り返すタイプの仕事を与えるようになります。自分で学ぶことができない人の考え方を変えるのは難しいからです。
yana-gi.iconウッ……
やる気を維持するには
ゴールは明確に
抽象とはなにか
モデル
現実のしくみを説明するための簡素化された表現
現実世界で起きている現象は複雑なので、重要ではない部分をそぎ落としてシンプルにする
モデルの価値は、現実を直接操作することに比べてモデルの操作がどれだけ楽になるか(≠ 現実との一致度)
MVCのモデル
モデル
ビュー:ユーザーにモデルを見せる手段
コントローラー:ユーザーがモデルを操作する手段
→プログラムから表示と操作に関わる部分を取り除いた「プログラムの本質的な部分」
デザインパターン
プログラムの設計に繰り返し現れる幸三
建築でいえば、「ドア」もパターン
なぜ抽象化が必要か
解き方のパターンは抽象化・一般化・汎用化された知識
パターンを発見する=抽象化によって獲得しなければ新しい問題を解ける様にはならない
ex) 高校数学の問題も、解き方を丸暗記しても類似問題は解ける様にならない
yana-gi.icon大学受験の数学で塾講師に「複数パターンを網羅した問題を繰り返し解くこと」を強調された。実際それで数学の成績が上がったことがある。これは問題の解き方を覚えるというより、パターンを覚えさせていたのかも。
https://gyazo.com/ec716c8bd86b6c8534d1cdfce590a505
どうやって抽象化するか
比較して学ぶ
「同じ」と「違う」の間に注目する
共通部分だけでなく、違いに着目すると理解が深まる
例え話は抽象化なことを伝える時によく使われるけど、「どこが同じで、どこが違うのか」を明確にすることが大事
ex)「公開鍵と南京錠」
yana-gi.icon自分で理解する時、似たもの同士を「同じ」で比較することは多いが、「同じ中で違うこと」には無頓着だったことに気づいた。
https://gyazo.com/d4358fde605fda4d72cd4e4e788620c6
パターン本から学ぶ
パターン本は具体的な経験から読者のパターンを見出すことを手助けすることはできるが、具体的な経験を持たないままパターンだけ習得することは難しい
パターンが自分のものになっているか
自分の言葉で説明できるか?
自分の経験に基づいた具体例をあげることができるか?
自分の目的を達成するためにその知識が使えるか?
つくって検証する
正しく理解できているかどうかは、理解を元に何かを作ってみて、期待通りに動くかで検証できる
プログラミング学習は他の学習に比べて学びのサイクルを高速に回すことができる
「1日前の自分にどう説明するか?」
yana-gi.icon自分は「作りたいものを作る」を目的に勉強するのが一番モチベーション高く感じるので、作りたいもの駆動で学んでいこう
やる気が出ない人の65%はタスクを一つに絞れていない
絞るためにまず全体像を把握する
Getting Things Done : まず全て集める
全部集める→そのあとで処理をする
収集フェーズと処理フェーズが明確に分かれていることが大事
第3章 記憶を鍛えるには
記憶は繰り返し使うことで強くなっていく。
筋肉と同じ
ファイルの保存ではない
記憶するためにはインプット・アウトプットの両方が大事
脳は似た情報が繰り返し入ってきた場合にどんどん鈍くなり、情報を無視する様になる
テストをしてから学ぶと記憶が強化される
1度読む→思い出せるだけ思い出す→もう一度読む→また思い出せるだけ思い出す
は教科書を4回読むよりも成績がよかった
yana-gi.iconこれ実践してみたい
覚える前にまず理解をすることが大事
第4章 効率的に読むには
本に書かれた情報をきっかけに、自分の個人的な経験を交えて自分の個人的なモデルを組み立てる
読書は「情報を見つける」のではなく、本から得た材料と自分の経験を組み合わせて構造化していく「理解を組み立てる」
読書の価値は「本の著者の力」✖️「あなたの経験値」✖️「あなたのビジネス力」 by 寺田昌嗣
yana-gi.iconだから同じ本を時間を空けて読むと、経験値が上がって読書の価値があがるのかも
読むというタスクの設計
理解は不確実タスク
× レポートを書くためにそのテーマについて理解する
○「テーマについて書かれている本3冊に眼を通す」
時間を区切ってふせんに抜き書きを作る
第5章 考えをまとめるには
書き出し法で情報量を確認
100枚を目標にする
50枚すらでてこなかったら、情報収集が足りない
yana-gi.icon
---
2020/12 に読んだログ
覚えておきたいこと
ゴールは明確に
知りたいところから学ぶ
やる気が出ない人の65%はタスクを一つに絞れていない 読書は本から得た材料と自分の経験を組み合わせて構造化していく「理解を組み立てる」
感想
体感的にプログラミングを学んでいるときに行っていることが言語化されていて納得できた
どう学ぶか、これからのヒントになった
読書は「理解を組み立てる」
思い返してみれば読んでいて「面白い」「分かる」と感じる時て自分の体験したことが多い時だ
この本を読んでいてまさに書かれている材料と自分の体験を組み立てることができた。
いつもなんとなくタスクをざっくり組み立ててたけど、ポモドーロを使いながらタスク立ててみよう
1日8ポモドーロで
以下メモ(1時間)
はじめに
知識を用いて価値を生み出すこと
本に書いてある知識をコピーするだけではなく、修正し、組み合わせ、新しい手法を作ること
プログラミングはどうやって学ぶか
プログラミングを読んだり写経などの具体的な情報収集
複数の具体的情報から共通するパターンを見出すこと
どこが重要でどこが枝葉かを判断すること
コードでエラーがでても、「この場合ではうまくいかない」という情報を発見する
新しいことを学ぶには
ゴールは明確に
チュートリアルはゴールを近くする
例)短いプログラムや簡単なプログラムを実際に作ってみたり
知りたいところから
自分が「知りたい」と思うところからやる。
手を動かし始めるとたくさん知りたいことをどんどん解消していくことでやる気を維持しながら学べる
「そんなの必要ないよ」YAGNI原則
「必要になるまで機能を追加してはいけない」
今考えないといけないのは「今どうあるべきか」なのに「将来的にはこうかもしれない」を考えるのは気が散る
yana-gi.icon 将来これが必要になるかもしれないと思って中途半端に動きがち
時間は貴重
実際に必要にならなかったら、実装に使った時間が無駄になる
Matzのソースコードの読み方
「全体を読もうとしない」
「目的を持って読む」
知りたいところから学ぶための前提条件
目的の明確化
達成可能な目的
おおまかに全体像を把握する
大雑把に把握する
資料の目次から把握する
ソースコードを段階的に読む
徐々に詳細化するように読む
ドキュメントの大まかな構造
片っ端から
大雑把に情報収集できない状態は、理解を組み立てるための材料が足りていない
yana-gi.iconRails勉強した手のころとかそう
そういう場合は片っ端からやるしかない
書写しながら「前にも出てきたな」「他のパターンとちょっと違うな」と考えるのが大事
入力しながら類似点・相違点を発見していく
→ 自分の中でモデル化がすすむ
時間を区切る
25分でできるところまで写経するぞ、などの目標を設定する
解いた問題からパターンを発見する = 抽象化 しなければ新しい問題を解ける様にはならない
どうやって抽象化するか
比較して学ぶ
「同じ」「違う」の間に着目する
その境目はグラデーションになっている
例え話
技術的な話を例え話にする場合、「どこが同じで、どこが違うのか」を明確にする
パターン本から学ぶ
パターン本は具体的な経験から自身がパターンを見出すことはできるが
具体的なパターンを持たないままパターンだけ習得することはできない
知識が身についてるかを知る
自分の言葉で説明できるか?
自分の経験の基づいた具体例をあげることができるか?
自分の目的を達成するためにその知識を使えるか?
やる気が出ない人の65%はタスクを一つに絞れていない 絞るために全体像を把握する
まず気になることを全て集める
一度に「集める」と「考える」の複数のタスクをしない
全部集めて、その後で具体的な行動を考える
「今日やること」の整理に集中する
1つのタスクのやる気を出す
タスクが大きすぎる
時間で区切る
ずっと集中するより、休憩した方がもっといい方法が思いつくことがある
yana-gi.icon これは何度も経験してる。けど集中してると休憩したくなくなりがち。意識的に休憩を取ろう
ポモドーロの個数でタスクの見積もり能力を鍛える
見積もり能力
見積もりと実際にかかった時間を比較し、ズレの理由を考える
1日にせいぜい8ポモドーロが現実的なライン
記憶を鍛えるには
記憶力は繰り返し使うことによって強くなる
効率的に読むには
読むとは何か
読書は「情報を見つけるというイメージが持たれがち」=インプット 読書は本から得た材料と自分の経験を組み合わせて構造化していく「理解を組み立てる」イメージ
「組み立てる」読み方
ポイント
分からないことはなんでも記録する
何度も出現する単語を記録する
概念の間の関係や理由と結論の関係などを矢印でつなぐ
単語の理解が不十分
論理の道筋の理解が不十分
問題意識の理解が不十分
図解する必要がある
理解できなかったときに苦しい
「理解できないかもしれない」と前提しておく
→理解できたら嬉しいござん
時間を区切ってふせんに抜き書きをつくる
読もうと思ったきっかけ
アウトプットが大事とよく聞くけど、なかなか実践できていない
技術書を読んでいて理解/習得できているのか常に分からない
勉強方法について何か一冊読んでみたい
本屋で独学大全を立ち読みしたら面白かった、けどもっとエンジニア向けの本の方がいい
独学大全よりこちらの本を進めている方がいた
Scrapboxが気になっていた、けど使い方や良さが分からない
真似して実践できそう