読書メモ:世界一流のエンジニアの思考法
一流エンジニアと三流エンジニア脳のスペックにちがいはない。
ちがいがあるとすれば思考法である。
生産性を高くする
一流エンジニアは理解に時間をかける。
速度を重視して原理がわからずに動くものを作っていては成長しない
コードを書く前にDesign Docを書く
word 2~10程度
Scope
DesignDocの範囲
Background
なぜこのプロポーザルを行うかの背景
Problem Statement
解決したい問題を解く
Proposal
どういうデザインにするか、またその選択肢を選んだ理由をロジカルに書く
頭が整理される
後で退屈なDocumentを書かずに済む
マインドセット
Be Lazy(怠惰であれ)
望んでいる結果を達成するために、最低限の努力をする
不必要なものや過剰な準備を削る
簡潔
優先順位
❌: 5つのリストでどの順番でやるか順序をつける
一つにフォーカスする、他はやらない
いわゆる2-8の法則(20%の仕事で80%の価値を生み出す)
努力より、アウトプットと生産性
長時間労働しない
失敗しやすい(≒チャレンジしやすい)環境の作り方
評価制度,KPIを決める
評価はKPIの達成に応じてのみ評価する
途中の失敗は何も問題ないとする
QCDSのなにを削るか
A. S(Scope)
無理して達成すると問題を覆い隠すことになるのでやってはいけない。
多少機能を削っても価値が大きく変わることは少ない
スケジュール通りやることに意味を見出しすぎてはいけない
進捗よりも実際にどうだったか、「改善ポイント」や「ベストプラクティスは?」が大事
マルチタスクをやめる
シングルタスクの方が効率が良いのだがそのための仕組みづくりが目から鱗だった。
1日4時間は他の全てをブロック(チャットの返信も)してコードを書く時間を死守する。
同時並行で他の作業をするはやめた方が良い。(ex. ミーティング中)
結局大した進捗を出せない。それをするなら一つのことに集中するかそもそも出ない
情報は一つに絞って余計な情報を付け加えない
わかってるわ!と思ってたけど想像以上だった。
今までエラーの原因がわからないからメンバーに聞こうという時、「今までこう考えて、これやって〜まだ解決してなくて、こんなエラーが出てて、でもここに原因がある気がして〜」みたいな詳細情報を含めて相談していたのだが、アメリカでは「こんなエラーが出てるけどなんかわかる?」みたいな感じらしい。これはシングルタスクの話に近いのだが、聞きたいこと(≒集中すべきこと)を一つに絞ることで本質がわかりやすい。追加で必要な情報はコミュニケーションを通して拾い上げていくのだ。
必要な情報のみ伝えるコミュニケーションの方が脳に優しく理解しやすい
持ち帰らない
持ち帰り癖がつくと仕事の生産性を落とすので一旦答える。もし他に良いアイデアを思いついたら後からシェアする
気軽に聞ける環境とは
「気軽に聞ける環境」は「気軽に断れる環境」とセットである
シンパシーではなくエンパシー。相手には相手の考えがあるから尊重する必要がある
*エンパシー: 相手の意見に共感できなくてても同意しないことを理解する力
In My Opinion のノリを大事にする!!!!!!!!!!
運動しろ
テストステロン!テストステロン!
小腹が空いたらナッッッッッッッツ!!