第1章　頭脳労働者としてのプログラマ

1.1　頭脳労働の極端な例

• 1.1.1　プログラマという特殊な職業
• 1.1.2　単純作業と頭脳労働の違い
• 1.1.3　ゴールに近づくほど，ハードルが上がる？
• 1.1.4　プログラミングの困難さは，近づいてもゴールが見えないこと

1.2　プログラマとして何を目指すか

• 1.2.1　エンジニア・職人・芸術家
• 1.2.2　考え方の流れが「動く」「残る」

1.3　どうやって上達していくか？

• 1.3.1　まずは本で独学する
• 1.3.2　辞書を覚えても，小説は書けない
• 1.3.3　「採掘場」のように，深く広く理解する
• 1.3.4　ゆっくりとした大きな動きを見る

1.4　プログラマが持つべき3つの説明力

• 1.4.1　3つの説明相手
• 1.4.2　自分向け（その1）：説明することで考えを整理する
• 1.4.3　自分向け（その2）：その瞬間の脳内コンテクストを固定する
• 1.4.4　コンピュータ向け：説明としてのプログラミング
• 1.4.5　他人向け：いわゆる「説明」
• 1.4.6　3つの説明を意識して使い分ける
• 第1章のまとめ
• Column 公開プログラミングの効果

第2章　土台としての情報科学

2.1　土台の必要性

• 2.1.1　知って何が変わるのか？
• 2.1.2　根本は「計算と記憶」なのだと知る

2.2　ノイマンとチューリングのおかげです

• 2.2.1　知らずにプログラミングすることの弊害
• 2.2.2　ノイマン型のいったいどこが特徴なのか？
• 2.2.3　区別がないから，「虫」と「穴」が生まれる
• 2.2.4　ビンの首がボトルネック
• 2.2.5　頭の中のコンピュータ：チューリング・マシン
• 2.2.6　仕様書通りか？ バグはないか？ 盗作か？

2.3　プログラムの動作速度はどうやって決まるか

• 2.3.1　偉大なる不公平 ～メモリ参照の局所性～
• 2.3.2　メモリの階層構造
• 2.3.3　プログラム側でも，メモリ階層を意識しよう
• 2.3.4　計算量：教科書的な話
• 2.3.5　計算量：より現実的な話

2.4　イマドキのハードウェア

• 2.4.1　CPUのお仕事，またはうどん屋のパイプライン
• 2.4.2　条件分岐すると遅くなる理由
• 2.4.3　1人でダメなら手分けせよ
• 2.4.4　アムダールの呪い
• 第2章のまとめ
• Column バスとは何か？

第3章　説明としてのプログラミング

3.1　OSという層　～複雑さから逃げる手段～

• 3.1.1　人数が増えて開発スピードが落ちるわけ
• 3.1.2　人間の脳の限界
• 3.1.3　コンテクストをやりくりする
• 3.1.4　台本のスイッチング

3.2　言語処理系を理解せよ

• 3.2.1　予習する人・しない人　～コンパイラとインタプリタ～
• 3.2.2　関数呼び出しとスタックの概念
• 3.2.3　スコープ越しに変数を狙え
• 3.2.4　型の違いに敏感になる
• 3.2.5　コンパイラの警告という「壁」
• 3.2.6　エラーメッセージは真に受けず，裏を読め
• 3.2.7　言語は人間とコンピュータの間でバランスを取る
• 3.2.8　要するに「オブジェクト指向＝次回に手抜きをする方法」

3.3　情報は，使うところに置いておけ

• 3.3.1　「時間」こそ最重要リソース
• 3.3.2　過去の自分も未来の自分も，他人である
• 3.3.3　処理はひとつ，書き方はいろいろ
• 3.3.4　「今の自分」は，なぜその書き方を選んだのか？
• 3.3.5　コメントにはコードで説明できないことを
• 3.3.6　情報は散らかさない　～変更可能性への対処～
• 3.3.7　変数名はわかりやすく，長く
• 3.3.8　計算式を，自分の頭で計算するべからず

3.4　脳との食い違いを埋める

• 3.4.1　printfと「シートベルト」
• 3.4.2　assertの活用は，未来への説明

3.5　C言語のいろいろ

• 3.5.1　C言語 ＝ 構造化アセンブラ
• 3.5.2　ポインタ：C言語の遭難の名所
• 3.5.3　ポインタと配列はどう違う？
• Column 配列とポインタの文法の混乱（C言語）
• 3.5.4　Javaは中道を行く
• 第3章のまとめ
• Column C++はなぜ++Cでないか

第4章　自分への説明で仕事を効率化する

4.1　人間とコンピュータ

• 4.1.1　機械的労働と頭脳労働
• 4.1.2　コンピュータの性能向上の要素
• 4.1.3　人間はコンピュータから何を学べるか？
• 4.1.4　頭脳労働ではデコードが重い

4.2　時空間を越えて情報を共有する

• 4.2.1　自分は現在にしかいない
• 4.2.2　効率アップの基本は，コンテクストの共有
• 4.2.3　情報を手元におくツールは何でもよい
• 4.2.4　リアルタイムにログを取りながら進む
• 4.2.5　後ろにさがらないことも重要
• 4.2.6　説明性を高める例：ペアプログラミング
• Column アイディアの出し方

4.3　何を残して何を切り捨てるか

• 4.3.1　段取りソコソコ，仕分けもテキトーに
• 4.3.2　コンテクストスイッチの重さを知る
• 4.3.4　可能性に応じて労力をつぎ込む
• 第4章のまとめ

第5章　他人に説明する技術

5.1　アナロジーで要点をつかむ

• 5.1.1　よい説明と悪い説明
• 5.1.2　人間が理解できるのは，易しいことだけ
• 5.1.3　アナロジーの2段階：「類」と「推」

5.2　よい説明に近づくためのポイント

• 5.2.1　失敗についての説明：失敗の理由は腐るほどある
• 5.2.2　外来語の紛らわしさを知る
• 5.2.3　「言葉」という道具は1次元配列
• 第5章のまとめ
• Column エンディアンの由来

第6章　プログラマとしての今後

6.1　壁がなくなる時代

• 6.1.1　プログラマは昇進する必要があるか？
• 6.1.2　中国やインドの安い人件費にどう対抗するか
• Column 1日にできる作業量は，作業時間に関係ない

6.2　どう働き続けるか？

• 6.2.1　目の前の仕事に何を見い出すか？
• 6.2.2　プログラマとしての人生のゴール
• Column プログラミングと作曲
• 6.2.3　プログラマだけが「動く」コードを書いている

6.3　すべての労働はプログラミングに通ず