- Published on
もう散々話題になっていますが、「世界一流エンジニアの思考法」を読んだので感想とメモを書いた!
感想
- 書評記事はたくさんあるけど、実際に本を手に取って読む方が何倍もためになった(当たり前)
- 書いてある内容自体は目新しいかと言われるとそんなこともないが、牛尾さんの実際の経験と共に書かれているので説得力が凄い
- 書かれている内容を自分も実践したい、実践しなければと思わせてくれる
- 定期的に読み返したいと思った(すでに2回ほど読んでいる)
メモ
- いきなり手を動かさない。まずは、事実データを一つ見つける。いくつか仮説を立てるその仮説を証明するための行動をとる
- すぐに試行錯誤しない
- 理解とは、人に説明できること、いつでも取り出して使えること、応用が聞くこと
- コードのロジックを読むのではなく、コードの意図とその背後のアーキテクチャを理解するためにコードを読み込む
- 覚えてないから次回も調べることの繰り返し
- それで良いと思ったけど何もそこに成長はない
- あやふやな理解なのはしょうがないけど、基礎を少しずつ積み重ねないと成長はない
- まずはとりあえずコードを動かしてみるに逃げない
- わからないことをその都度理解しようとする姿勢が大事
- 感覚でこれが問題だろうと決めつけない
- コードを書く前にデザインドックを書く、たくさん書く必要はなく簡潔かつ必要十分がカバーされていれば良い
- 一つのことで2時間以上ブロックされたら質問するなり相談するなりして寝かせておいて他の仕事をやっておく方が断然生産性が高い
- 怠惰であれ
- 望んでいる結果を達成するために、最低限の努力をする
- 不必要なものや付加価値のない仕事をなくす
- 簡潔さを目指す
- 優先順位をつける
- 時間や費やした努力より、アウトプットと生産性に重点を置く
- 時間労働しないように推奨
- 会議は時間内で効率的かつ生産的に価値を提供する
- 一番大切なことにフォーカスする
- 必要以上に準備しすぎない
- 目標は定時で無理なく達成できるものであるべき
- 目標を絶対達成しなければいけないと想うと、失敗できなくなりチャレンジができなくなる
- 過大な要求をするべきじゃない
- 自分にとって難しすぎると感じるときは方法が間違っているサイン
- ときにはコードを端から端まで読むのではなく、詳細は読まずに開発者を信頼して処理の流れを追っていく方法もある
- 生産性とは何も調べずに即座に実装できるもの
- プロトタイプ思考、目に見えるものを作るエンジニア
- 単にできたではなく、少なくとも説明可能かというセルフチェックを入れた方が良い
- 人に説明可能な状態にもっていく訓練として良い手段はブログを書いてみること
- prが大きくなるのは大抵ミスコミュケーションのサイン、そういうときは同期的に会話する
- 技術の問い合わせがあった際に自分が知らないときほど学びの機会になる
- 誰もやったことないものに取り組んでいる人は、aiが取って代わることは原理的にありえない
特に刺さった内容
- 目標は定時で無理なく達成できるものであるべき
- 目標を絶対達成しなければいけないと想うと、失敗できなくなりチャレンジができなくなる
- 仕事における目標設定ってどうすればよいのかなと思っていたので参考になる観点だった
- 目標に対してのマインドも参考になった
- 生産性とは何も調べずに即座に実装できるもの
- 理解しようとせずにその都度ググればいいやと思っていたこともあった
- ただそれだと当然次も覚えてないから次回も調べることの繰り返し
- 何もそこに成長はない
- あやふやな理解なのはしょうがないけど、基礎を少しずつ積み重ねないと成長はない
- 例えばちょっと小難しいgitコマンドを毎回使うときにググっていたけど、理解しようとしたら案外簡単に覚えられた
- そのコマンドを毎回ググる時間が減ったのでこれだけでも結構自分が成長できたと思えた
- 暗記せずに理解できると自分の成長を感じられて良い
- すぐに試行錯誤しない
- 自分も結構推測で試行錯誤をするのを結構やってしまっていた
- 最初から手を動かさずに念入りに調べると結果的にこっちの方が早く終わるという経験を自分もできた
- 自分も結構推測で試行錯誤をするのを結構やってしまっていた