個人芸を磨くためにじっくり読むという方にはよいと思いますが、
辞書的に欲しい情報にささっとアクセスしたいという使い方には不向きかも。
（一度しっかり読んで、インデックスができてたらいいのかもしれませんが）

各セクションの終わりに関連セクションのページ数が出ている（これは親切だと思う）ので
それを追って読んでみました（ハイパーリンクを意識している？）が、
断片的で散漫な感じがして、しっかりイメージにとどめることができず、
私は途中で読むのをやめました。

ある程度経験のある方なら、どこかで聞いたことがあったり、経験的に理解しているような
内容も多いように思います（そういうところで興味が続かなかったのかも？）。

毎日バリバリコード書いている若い方、まだまだスポンジのように吸収力のある方、
自分のやり方ってどうなの？と少し客観的な尺度の欲しい方には、ヒント満載の教科書になるかと思います。

数年ぶりに読み返してみました。
これまでに色々な本を読んできたので、今この本を読んでみて「新しい発見」というのはほとんどありませんでした。どれもどこかで読んだことのある内容ばかりです。

しかし、それはこの本に価値がない、ということではありません。
自分の中ではほとんど「常識」レベルの内容ばかりですが、これが常識になっていない技術者は世の中にたくさんいると思います。
なので、この本を読んだことのない人は自分の常識力を確認するために一度読んでみましょう。
DRY原則など、この本がオリジナルとなっている内容も含まれています。

ちなみにこの本に書かれている内容はCode CraftやCode Completeと共通する部分も多くあります。技術者の心得やコーディングテクニックをもっと掘り下げて勉強してみたい方はこちらもチェックしてみてください。

「達人プログラマー」というタイトルは、おそらく出版社が売れ線を狙って付けたのだと思います。
本書の内容は、上級者が自然と身に付けているアプローチ、テクニックを整理したもので、
原題「The Pragmatic Programmer」の Pragmatic は、実践的と解釈した方が、本書の実体に即しています。
であるので、「達人」、「名匠」という語に対して過剰反応しない方がよいです。＞自分

ところで、この本で感心したのは、訳注の親切さです。
外国の書物では、よく名言や格言が引用されますが、本書の訳注では、それらの発言者ひとりひとりについて経歴を簡単に紹介してくれています。
ほかにもスヌーピーの叫び声など、本文だけでは理解できそうもないところを丁寧に補足してくれています。訳者さんに感謝です。

あと、The Pragmatic Programmer: From Journeyman to Master (ペーパーバック) の書評も参考になりましたので、興味のある方は目を通してみて下さい。

この本はプログラミングやアルゴリズムのテクニックというよりは、開発作業をより円滑に、かつ生産的に行うノウハウについて説明しています。

開発を効率良く行うにはプログラミングテクニックだけでなく、作業の進め方や考え方を知る必要があります。それができないと、工数や開発予算を無駄に使うはめになります(私は工数や予算を無駄にしている開発プロジェクトをたくさん見てきました)。
私は今までに色々な開発プロジェクトを見てきましたが、実際の開発の現場には、正しい知識やノウハウを持った人はほとんどいませんでした。間違った知識や考え方を持った人が非常に多いのが現状です。これでは効率の良い開発をできるはずがありません。例えるなら、車の知識が全くない状態で車を運転するようなものです。
これを読むと作業を進めるにあたっての正しい考え方が身に付きます。また、プログラミングという作業を哲学的な観点からも説明しています。

抽象的な説明が多く、具体例が比較的少ないですが(もちろん具体例が記載されているものもあります)、その場合は、他の本を参照すると良いです。
この本の中でも紹介されているプログラミング作法という本と組み合わせて読むことで、より理解を深めることができます。
この本に限らず、一冊の本だけでなく複数の本を組み合わせて読むとより多くの知識を得ることができます。

曳光弾を使った開発についての説明がありました。名前はかっこよくてインパクトがあるのですが、本文を読んでも普通のプロトタイプを使った開発と具体的にどう違うのかが良くわかりませんでした。これも、他の本を参照すれば理解できるかもしれません。

上記の件はあるにせよ、「下手な言い訳より対策を立てること」「割れた窓を放置するな」など、開発者として抑えておかなければならないポイントが満載です(開発者にとって言い訳は絶対NGです)。特に、ブロークン・ウィンドウ理論(割れ窓理論)の話はとても説得力があります。

現在開発プロジェクトのマネージャーをやっている人や将来それを目指している人、また、タイトル通り「達人プログラマー」になりたい人は、必ず読むべき本です。

伝える事柄さえ正しければ、伝える方法は何でも良いというのが間違いであることは、うすうす気がついていました。車の両輪というほど大事なものであることは、本書を読んで初めてきがつきました。そうだったんだ。
ヒント１１： DRY　Don't　Repeat Yourself。

１０　曳光弾
はずかしながら、読めませんでした。
ネットで探したら、「えいこうだん」とのことで、英語はTracer ammunition。
飛びながら光の軌跡を残す弾丸のことのようです。

どきっとしたのは「ヒント２７：仮定せずに証明すること」。
しまった。やられたと思いました。星５つ。