プログラマ社長による、プログラミング能力以外のプログラマに必要な能力について書かれた本。 プログラムはただ作るのではなく、なぜそれを作る必要があるかを知ることが重要だとのこと。まあ、そりゃそうだよなと思う。ただ、仕様書がなくて言葉だけで何か作ってといわれるとそういうことは考えるけど、詳細な仕様書が考えずに作っちゃうことはあったので、ちょっとは考えるようにしたいとは思う。 顧客の担当者が、元請けの担当者よりITスキルが高いと要注意とあったけど、これってどう判断したらいいんだろう…。そりゃ、まずいことになるだろうなとは思うけど、こちらから元請けの担当者に技術的なアドバイスを伝えるようにでもしたほうがいいのだろうか。 トラブルを最小限に抑えるために「マルチスレッドで作らない」という方法をとったという話は面白かった。確かに、マルチスレッドが原因の不具合があったら、解析も大変そうだしなぁ。シングルスレッドのほうが実装楽だろうし、UDP通信なら確かにありなのかもしれない。 プログラムの話とは直接関係ないけど、タイについての話がちょっと面白かった。 タイでは多くの人がLINEを利用してるらしい。本書が発売された2014年時点では国民の3分の1以上がLINEユーザーらしく、最新のデータを調べてみると2019年時点では64%が利用していたらしい。日本以外でもそんなにLINEが使われている国があったのか。 なお、著者によるとタイのドラマはワンパターンとのこと。だいたいが「お金持ちでハンサムな男性を、女性二人が奪い合う」話だそうだけど、個人的に今は、タイのドラマというとBLドラマなイメージがある。ちょっとは多様化しているのだろうか。 本書の最後のほうに書いてあったけど、プログラマの得意分野はプログラミング言語ではなく、何を解決・実現するのが得意かというのが重要というのは、なるほどと思った。自分も、プログラミング言語ではなく、何を解決できるかと考えるようにしたいと思う。

これぞプロフェッショナルプログラマーという感じだ。見積もりするときには、動くプロトを作っておけという主張など、しびれる。実際できるかと言われれば、自分は無理とも思うが、そうありたいとも強く思う。 以下注目点 ・美しい構造も仕様変更で崩れる。美しい構造は、オブジェクト化しすぎ、共通化しすぎの可能性あり。 ・とにかく早く見せる。 ・時間がたつほど、相手の要求水準はあがる。 ・自分が何を作るべきか知らないと成果は出せない。 ・意見が飛び交っている間は説得できない。 ・腹が立つのは相手に求めすぎているから。