筆者は言っている。優れた音楽家は優れた開発者になることが多い。本当にそうなのかは分からないけど、音楽を志す者はもれなく偉大になろうとし、それはソフトウェアの領域でもいえるという言葉には納得するものがある。というか、それはソフトウェアの領域に限らないだろう。それでもソフトウェアは、変化が圧倒的に多くて、むしろ推奨されて、スキルや役割の重ね合わせもレパートリーが多くて、でも1つのことに固執もできて、そんな大航海時代ならぬ大開発時代(?)において、偉大を目指さなければ、どこに行きつけるというのだろうか？どこかに行きつけることすらできるのだろうか？
印象に残った箇所まとめ
※本書の面白さはそのトピックのエッセイ全体を読んだとき時に感じられると思う。難しいことは書いておらず、地道に努力を重ねていこうとする時の、考えるとよいポイントが散りばめてある。個人的にすごいと思うのは、どの取り組みも深さがあり、総じて目指している・当たり前に思っているレベルが高い。
P14 自分自身にとって「一番下手くそになる」状況を見つける。すごい人たちの間に紛れ込んで（例えばOSS）コードをマネするとか。
P16 Java経験者を探す時にあえてSmalltalkをやったことある人を探すことで、その人が好奇心を持っているか判断の手助けになる。
P17 新しい言語を学ぶ。できれば全然違うものを。本書例では、JavaならSmalltalkやRuby、オブジェクト指向ならHaskellやSchemeとか。
P24 自分自身の汎用性を高める。リーダー？マネージャー？アーキテクト？どう役割を重ね合わせる？
P27 スペシャリストになる。Java仮想マシンをクラッシュさせるプログラムをピュアJavaで書くとしたらどんな手段をつかいますか？何かのスペシャリストであることは、他に何も知らない意味とは決して違う。
P32 愛せよ、さもなくば捨てよ。とにかくやれ。やれないはずはない
言い切るのかっこいい。
P42 なぜ？どうして？常に疑問を持とう
P50 一に練習、二に練習。なぜ本番で練習できる？つまりなぜ仕事の最中にしどろもどろなコードを書くような状態になる？また、APIやライブラリを知ろう。
P72 報告できる成果を毎日あげろ
P99 あわてるな。筆者はパニック日記をつけて、振り返りとしてあわててしまった場合とどうすればよかったかを分析している。
P113 仕事をうまくやればマネージャーは見てくれるようにするのではなく、自分でアピールをしよう。
P115 顧客を怖がらせていないか？
※自分でもできてないことが多すぎて書いててしんどくなってきた。
