読書会第19回[2006-02-11-2]。2冊目は「Joel on Software」[2005-12-16-4]。

■Joel Spolsky / ジョエル・オン・ソフトウェア


いろいろなエッセイ。おすすめな章をピックアップ。

■第12章　５つの世界■

ソフトウェア開発を５つの世界に分類。
それぞれの世界間で考え方に溝があるわけです。
(ref. 似たようなことをやってるけど実は違うことをやってる人たち
<http://d.hatena.ne.jp/naoya/20060209/1139484009>)

1. パッケージ：オープンソースもWebも含めてる。
2. インターナル
3. 組み込み
4. ゲーム
5. 使い捨て：ref. その場しのぎプログラミング[2003-12-09-3]

■第14章　アーキテクチャ宇宙飛行士たちに脅かされるな■

アーキテクチャについて考え続けすぎて非生産的な人々の話。

彼らは、損益にはまるで貢献しない非生産的で高学歴な人たちをたくさん
抱えておく余裕のある、非常に大きな会社で働いているのが普通だ。

元の英文→[2005-11-19-5]

■第15章　射撃しつつ前進■

生産性の鍵は「ただ始めること」。ペアプログラミングはだらだらを防ぐ
意味でうまくいくのでは、とのこと。あと、Microsoftなど大企業から次々
に出てくる技術を追うのに時間を使いすぎるな、と。

■第20章　採用面接ゲリラガイド■

これ、超重要。いかにまずい候補者を落とすか。MicrosoftやGoogleの
採用も基本的にこの章のやり方。

採用しない方が良い２つの極端なパターンがおもしろ：
(1)頭はいいが物事を成し遂げない人々：

しばしばPhD（博士号）を持っており、大企業で働いているが、彼らの言
うことなんてまったく実用的ではないため誰も聞いてない。彼らは予定ど
おりリリースすることよりも、何かアカデミックな問題についてあれこれ
と考える。[...] たとえば、「スプレッドシートは実際のところプログラ
ミング言語の特殊なケースにすぎない」というようなことを言い[...]

(2)物事を成し遂げるものの頭は良くない人々：

考えもなしにバカげたことをやり、誰かがその後始末をするハメになる。
彼らは貢献できないばかりか優れた人々の時間さえ奪ってしまうので、
会社にとってはお荷物となる。彼らはサブルーチンを書かずにコードの
大きな塊をコピーしてまわる。それは頭のいいやり方じゃないにしても、
とりあえずは仕事が成し遂げられるからだ。

まあ、ともかく技術者の面接は技術者（複数人）が面接すべきですね。

■第26章　漏れのある抽象化の法則■

下層の技術も知らないと、いざというときにまったく対処できないよ、
という話。ここら辺で技術者としての差が出てくるかと。
LLしか知らない人は、Cとかマシン語とかやっとくべきかと。

■第27章　プログラミングにおけるロード・パーマストン問題について■

かつてロード・パーマストンは言った。
「シュレースウィヒ-ホルシュタイン問題はとても込み入っていて、
ヨーロッパでそれを理解できた人間は3人しかいない。
1人は亡くなられたプリンス・アルバートだ。
もう1人はドイツ人の教授で、発狂してしまった。
私が3人目なのだが、もうすっかり忘れてしまった」。

あなたが日常使うことの90%は1週間で学習できるが、残りの10%を知るた
めには、2、3年かかるかもしれないということだ。

そういえば、あるプログラミング言語の本をちょっと読んで何か作れた、
ってくらいで「その言語ならまかせて！」とか言い出す人、いるよね。

いつもは知的だと思える人が、ブログの中で「Microsoftはまともな
オペレーティングシステムが作れない」みたいな愚かなことを書いている
のは、率直に言ってバカにしか見えない。何百万行のコードと何百もの大
きな機能領域を持ち、何千ものプログラマが10年、20年とかけて作り上げ、
1人の人間にはその大きな部分を理解し始めることすらできないようなも
のを要約しようとしているのを想像してみるといい。

この本が参考になるかと：「闘うプログラマー」[2005-11-20-1]

■第35章　「ここで発明されたものじゃない」症候群を擁護する■

車輪の再発明を擁護！

それがビジネスで核となる機能なら──何が何でも自分でやることだ。

ref. アンチ根性と車輪の再発明[2005-08-22-3]