【読書メモ】TeamGeek

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

職場の先輩から、貸してもらった。

Googleの本と、Ruby on Rails作った人の本、どちらがいいか尋ねられ、 Googleの本を選択した。

読み始めたら、かなり面白い内容が書かれており、 半分くらいまで夢中で読み進めた。

大事なことがたくさん書かれていたので、メモとして残す。

先輩に本を返したら、自分でも一冊買っておこうかと思っている。

• ソフトウェアエンジニアリングの世界における批判

プロのソフトウェアエンジニアリングの世界では、批判は個人的なものではなく 優れたプロダクトを作るためのプロセスの一部にすぎない。 したがって、成果の対する建設的な批判と、性格に対する 攻撃的な批判との違いを君が（周囲の人たちも含めて）理解しておく必要がある。

• 批判を受け入れる

批判を耳にする側としては、それを受け入れる方法を学ばなければいけない 自分のスキルに謙虚になるだけでなく、他の人があなたに 恩恵をもたらしてくれると心から信頼し、自分がバカだと思わないことである。

• コードの価値

自分の価値を自分の書いたコードと結びつけてはいけない
君は君の書いたコードではない

• Googleの社是

失敗は選択肢の１つ 過去に失敗したことがなかったら、 それは革新的でないかリスクをとっていない証拠である

• トーマスエジソンの言葉が引き合いに出される

  10,000回うまくいかなくても、私は失敗していない 落胆などしない うまくいかなかったことのすべてが、前へ進む一歩につながるからだ

• HRT

  • 謙虚（Humility)
    • 世界の中心は自分ではない。自分は全知全能ではないし、 絶対に正しいわけではない
  • 尊敬 (Respect)
    • 一緒に働く人のことを心から思いやろう。 相手を一人の人間として扱い、その能力や功績を高く評価しよう
  • 信頼 (Trust)
    • 自分以外の人は有能であり、正しいことをすると信じよう。 そうすれば仕事を任せることができる

• 失敗を文書化(ポストモーテムを記述)する

  • ポストモーテムに含まれるもの
    • 概要
    • イベントのタイムライン（調査開始から解決に至るまで）
    • イベントの根本原因
    • 影響と損害の評価
    • すぐに問題を解決するための行動一式
    • 再発を防止するための行動一式
    • 学習した教訓

【Memo】：
日頃のコーディング時の調査や仕事で使える

• 新しいことに挑戦

その場で最も知識のある人になるのは楽しいし、 誰かを指導するというのはやりがいがある
問題となるのは、チームの中で局所最適化してしまうと 学ぶのをやめてしまうのだ 学習をやめると退屈になる

• コメント

コードに書かれてあることを説明しなおすのがコメント コードのなぜを説明するものであり、コードが何をしているのかを説明するものではない