本を1冊以上読まないと乗れない Ride
(ludic.mataroa.blog)- 職場では上位クラスのエンジニアと認められていても、実際の達人たちと比べると大きな差があることがあり、その差はたいてい きちんと学習した量 に表れる
- 高校卒業後に美術をあきらめた経験は、Drawing On The Right Side Of The Brain を1冊読み、数時間練習しただけで「適切な教材」が障壁を下げうることを示している
- エンジニアリングでも、特定のテーマについて 本を1冊以上 読んだ人と、ほとんど試したことがない人との差は大きく、多くの職種では後者が多数を占める
- 専門性は地域・国・オリンピックレベルのフェンシングのように何層にも分かれており、何冊も読みながら深く掘る人は 最上位の仕事の競争 に近づいていく
- 本を読むだけでは不十分で、良い教材を選び、悪い部分を捨てる メタスキル がなければ、Scrum・Agile・リーダーシップ資料に取り組んでも成果を出しにくい
「上位だが同時に足りない」という出発点
- 筆者は職業環境で一貫して 良いエンジニア と認められてきた
- 周囲の平均的なエンジニアより、最大で二桁倍は勉強していると表現する
- 州内最高レベルの企業の1つから senior level のオファーを受けたことがある
- 「Serious People」が再雇用しようとし、手抜きのコミットメッセージに腹を立てる
- しかし、自分にメールを送ってくる多くの人たちと比べると 明確に不足している と見ている
- 経験年数は3〜4年で、バックグラウンドは心理学
- 個人プロジェクト以外ではテストを書いたことがほとんどなく、自分が見てきた雇用主たちは動くテストも、テスト導入の意思もなかった
- 修士論文のコードはバージョン管理なしで書き、国内最高レベルの大学の1つがバージョン管理を教えていなかったと説明する
- この矛盾を美術・エンジニアリング・スポーツの事例で解きほぐし、「少しはきちんと学んだ人」と「ほとんど試していない人」の間の隔たりを強調する
美術で体験した「適切な1冊」の効果
- 高校時代、美術がいちばん嫌いで、自分は artsy ではないと判断してから約10年間、落書きレベルのキューブ以外はほとんど描かなかった
- 2022年に Drawabox のコースを試したが、とても退屈で、進歩もなかったと見ている
- その後、Hacker News の推薦を通じて Betty Edwards の Drawing On The Right Side Of The Brain に出会った
- タイトルは心理学から離れた筆者には不快だったが、推薦と before/after の事例 があった
- after の絵はあまりに非現実的に見え、減量詐欺のように感じられた
- 本の最初の課題は、自分の手をできるだけうまく描くことで、筆者は30〜45分かけて描いた
- 当時の基準では人生最高の絵だったが、それでもまだ足りないと評価している
- その後、上下逆さまの絵の線を目で追って描くような練習をし、何枚か描き足して結果に驚いた
- もう一度手を描いたときには、約 6時間の読書と練習 だけで以前よりずっと良くなっていた
- この経験は、生涯にわたって芸術の楽しさを逃すところだったが、合った本 を手に取ったことで壁を越えた事例になった
「1冊の本の壁」とエンジニアの分布
- エンジニアは大きく2つの集団に分かれる
- 特定のテーマについて 1冊以上 読んだエンジニアは、たいてい非常に有能に見える
- 文字通り本である必要はなく、十分な量の技術ブログや講義でも、効率の差はあっても似た役割を果たしうる
- 反対側には、キャリア全体を通してほとんど試さないエンジニアや、他の職種の人たちがいて、こちらが多数派だと見ている
- 達人エンジニアの Seth Newman は、平均的な専門職を「働く人生を夢遊病のように通り過ぎる人」に近いものとして描写する
- 動いてはいるが、階段から転げ落ちるのを避けるだけの認識は足りない、という比喩が添えられる
- 筆者自身は、ほとんどの職業関連テーマで 良い本を1冊 くらい読んだ人に近いと見ている
- Pro Git によって Git のデータモデルはしっかり理解しているが、その下のアルゴリズムは知らないと言う
- それでも無作為に選んだエンジニアを圧倒するには十分だと判断している
- Evennia のようなプロジェクトを見ると、はるかに深いレベルの人たちが存在することも認めている
- さまざまな分野の高成果者と話した結果、ほぼすべての分野で、まともに挑戦すらしていない人が多いという反応を得たという
専門性は果てしなく層に分かれる
- Seth との会話は、深い専門化 がどこまで行くのかという話につながる
- バスケットボールの例としては、NBA の下位クラスの選手の1人として知られた人物が、引退から10年後、体が壊れた状態でもアマチュアや下位プロ級の選手を圧倒する 動画 を挙げる
- 筆者のフェンシング経験も同じ構造を示している
- Melbourne では、筆者はそこそこ良い sabre fencer と見なされ、ほとんどのアマチュアに勝っていた
- しかし、州選手権に出る一部の選手たちには圧倒された
- 一緒に練習していた選手は後にオーストラリア Nationals で優勝したが、オリンピック予選を目指す選手には1点も取れなかったという
- Malaysia の Yu Peng Kean は、2012年オリンピックでその年の優勝者に 15対1 で敗れた
- こうした階層構造は、Magnus Carlsen が一生訓練してきたチェスプレイヤーたちを圧倒する例のように珍しくはないが、実際に相手にするとまったく違って感じられる
- 上位の選手は常に少しだけ遠く、速く、正確に見え、相手は子どもが大人に突っ込んでいくような感覚になると表現する
インセンティブと「技術業界に間違って入ってきた人たち」
- 筆者は、自分もピアノのような領域では 夢遊病状態 に近いと認める
- 才能不足も感じるが、実際には十分に練習していない
- ただしピアノを職業にはしておらず、誰も彼にピアノ演奏の対価を払わない
- 技術分野では、才能や関心のない人にまで参加のインセンティブを与える社会のあり方が間違っていると見る
- 多くの人はスポーツ・芸術・数学など他の領域では目が覚めているかもしれない
- 一部の分野に金があふれ、大規模組織の運営が難しく、企業資金を個人の地位に変えようとする動きがあるため、悪いプログラマや悪いリーダーにも高い賃金が支払われると見る
- PowerBI developer は、平均以上の賃金を受け取りながら、1日6時間以上だらだら過ごしやすい方法だと強く批判する
- Christopher Hitchens の最初の仕事の経験を引き合いに出し、ある仕事にとどまり続けられないほど下手だったからこそ別の道に出られた点を強調する
1冊の本が生む競争優位
- Dan Luu の記事 very little effort を引き合いに出し、高成果者になるのにごくわずかな努力しか要らない場合があると見る
- 高成果者とは、バックフリップのような明確な作業ができる人かもしれないし、他人より成果が高い人かもしれない
- 本1冊で、たいていは「技術的負債を作らずに React アプリへ新機能を追加する」くらいのレベルまで行ける
- 社会が報酬を与える仕事を賢く選べば、倫理的に生計を立てるには十分だと見る
- 何冊も読めば、最高年収の仕事を争うレベルに近づく
- 同じ仕事を1日でできるか、1週間かかるかが重要になる領域だ
- 競争相手が N 冊読んでいるなら、N+1 冊読まなければならない 軍拡競争 になる
- Deloitte と平均的な開発者は本をまったく読まないので、相手にしやすいと見ている
- 正社員として組織に縛られると、こうした人たちと働かなければならず、無力感を覚えることがある
- より mercenary に動けば、面接や会議で彼らを圧倒できると判断している
- 技術面接では、候補者に好きな技術書を尋ね、面接官が内容を検証できる本を挙げた人とだけ会話しても、大半の dud candidate をふるい落とせると提案する
- 面接官の知らない優れた本を読んだ候補者は false negative になりうる
- false positive はほとんどないだろうと推測する
努力しても成果が出ない人たちと、教材を選別する能力
- より複雑なケースとして、実際に一生懸命だが結果を出せないチーム運営者たちがいる
- エンジニアを苦しめ、慌てふためき、採用も分からず、自分の実力を過大評価しているが、本気では努力している
- ずっと Scrum を正しくやろうと試みるが、結果として湖へ歩いて入っていく夢遊病者のように見えるという
- 彼らに足りない能力は、どの本を読むべきかを知るメタスキル だ
- Drawabox と Betty Edwards の本の違いが代表的な例だ
- Drawabox は見た目にはもっともらしかったが、筆者の目標には Edwards の本のほうがずっと合っていた
- Drawabox は、Edwards が強調した核心的なコツをすでに知っている前提で、機械的な技術へ進んでいたと見ている
- 欠けたピースのせいで、全課程を終えてもほとんど進歩しなかったかもしれない
- 技術分野では通常、印象的なものを自分で作った人 の資料をより信頼する
- オープンソースの保守や、ごまかしにくい知識のシグナルがあれば高く評価する
- 「大企業」のような、より曖昧な実績は運やハッタリでも得られるので評価は低くなる
- コードはコンパイルできるかどうかをごまかしにくいと見る
- 教材評価に使う緩いルールも示している
- やたら目立つ名前は減点要素になる
- 良い本は表紙が退屈か、洗練されていることが多いと見る
- タイトルに「leadership」が入っていれば、たいていはたわごとである可能性が高いと判断する
- 著者が受賞歴を多く誇るほど、嘘くさく感じるという
- 口語体の文体は減点だが、テーマが繊細なら致命的欠陥ではないと見る
Agile、The Phoenix Project、LinkedIn 学習への批判
- 職場に Agile consultant が入り、経営陣は気に入っていたが、エンジニアには「Agile training を1〜5点で評価しろ」と求めた
- 筆者はこの質問自体が無意味だと見る
- そのセッションを好んだ人たちと、間違った本を読む人たちの間には、ほぼ100%の相関があると表現する
- 本の中でも価値のない部分を捨てられなければならない
- The Phoenix Project には良いアイデアがあるが、組織変革の物語の中で悪い行為者を1人だけにし、残りを非常に有能で誠実に描いている点が、大企業の現実とは違うと見る
- 良いアイデアは得つつ、残りは「leadership fanfic」に近いと気づかなければならない
- この選別能力がなければ、学習と自己改善は大きく妨げられる
- 役員が読んでいる資料を公開したとき、その人が仕事ができる可能性が低そうだとすぐ分かる場合があると見る
- リーダーが LinkedIn で学習していると言うと、筆者は強い拒否感を覚えるという
結論: 本を開くのは効果的だが、競争相手には勧める必要はない
- 最初は YouTube 時代に本を開くことの 異常なまでに大きな効果 を振り返る文章になる予定だった
- 実際の結論は皮肉にも、どんな状況でも人に本を読めと勧めるな、という方向に近い
- 他の人たちが読まないままでいてくれれば、本を読む人にとっては楽に稼げる金になる
- 次の文章は anti-Git propaganda と Scrum 資料リンクで埋めるつもりだ、という冗談で締めくくる
2件のコメント
技術を活用しようにも、まずそれが存在することを知らなければ試してみることすらできないのだから、浅くても知っておくことが大切です。
Hacker Newsの意見
文章はうまいが、初心者にはない熟練エンジニアの暗黙知を過小評価しているように見える
ときには単なる常識のように見えるが、実際にはそうではなく、その結果、共感の不足につながりやすい。子どもや高齢者と時間を過ごしたり、苦労している親族を同じ側に立って助けたりすると、そうした共感は蓄積される。母語話者がただ自然に話すことと、言語を学びながら苦労している人との違いを思い浮かべると近い
一貫したインデントや、コンパイラのエラーメッセージを実際に読んでデバッグに使うことのように、自分が当然だと思っていた部分で兄は苦労していた。兄がプログラマーとして就職できるレベルに達するまでには何年もかかったし、実は自分にも何年もかかっていたのに、自分の出発点を忘れていただけだった
コンサルティング会社で最も優秀なエンジニアは、重いADHDのため本はほとんど読まないが、実務経験が膨大で、ドキュメントや質の高いブログ記事を十分に読んでいるので、ある程度は同等性があるように見える。非常に優秀な人が「本はあまり役に立たなかった」と言いながら、その年に読んだ本を5冊すらすら挙げたことがあった。本そのものがその人にとって大きく役立ったわけではなくても、5冊を開いたという規律が彼をトップへ連れていったように思う
その感覚は、膨大な量の意図的な練習から生まれる
「キャリアを通じて一度もまともに試みないエンジニア」というくだりは、私の経験と100%一致する
私は天才開発者ではないし、任された小規模な問題に対してそこそこ良い解決策を作れる程度の能力はあり、正しいアプローチと間違ったアプローチに対する感覚もあると思っているが、FAANGの面接を受けられるかどうかすら自信はない。仕事中は常に警戒状態で、少しでも目を離すとグレムリンが入り込んでくる気がする
2人のシニアエンジニアがすでに承認したPRを30秒見ただけで致命的なセキュリティ欠陥を見つけたり、テストした5件のレコードでは問題ないが実データセットではページあたり300回のデータベースクエリを飛ばすロードパターンを見たり、すぐ捨てるタイムスタンプから日付オブジェクトを復元するためにCPU時間の75%を使うコードを見たりする、という具合だ。結局、プログラミングに対する生来の好奇心・関心・情熱の不足に見える
私にとって良いプログラミングは職人技に近い。ビジネス上の要求のためにその場しのぎのパッチをデプロイしなければならないと、言葉にしにくい不快感が生じるし、自分が作った成果物なら、製品そのものに強い愛着がなくても良いものにしたい。「どう動かせばいいかわからなかったので、とりあえずこうした」という言葉をよく聞くが、実際の意味はいつも「最初に試したことが小さな障害にぶつかると、それ以上試さなかった」に近い。コードベースが悪くなるほど、誇りを持てる貢献はますます難しくなる
自分が特別にひどい会社ばかり渡り歩いてきたのか、それとも業界全体が本当にこの程度なのか気になる
本人はわかっていないが、うちのチームのロックスターはまさにその人だ。例を見る限り、同僚たちは自分の仕事にあまり気を配っていないようだ
私は、問題が起きたとき、意見の対立を整理しなければならないとき、直せそうにないものを直さなければならないとき、何かを突き止めなければならないときに、皆が呼ぶ人間だ。自分にその資格があると感じたことはなく、Facebookのようなところでは1日ももたないと思う。チームにうまく合わせたり政治的構造に耐えたりする能力はないので、暗い隅のほうが好きだ
業界全体がこの程度なのかというと、実際にははるかにひどい。業界の人数はかつてないほど増え、実際に何かを知っている人を見つけるのはほとんど不可能だ。5〜10年かけて信頼できる人のリストを作り、絶対に手放さず関係を維持すべきだ
群衆の中に隠れにくいからで、もちろんどの規模の会社にも賢く献身的な人はいる。火を消し続けるだけにならず、原則を共有する人や尊重してくれる人を探しに行けば大丈夫だろう
たいした関心・注意・好奇心もなく、Issueにコードを投げ込んで良しとする人をあまりにも多く見てきた。以前のマネージャーは「火花」のある人を探していて、私を採用したのを見ると、そのころは私にもあったらしい
そういう火花のない開発者にも行き場所はあるし、逆にそういう人だけを集めようとして苦労した組織も見たことがある。しかし、お金や安定していそうな職業だと思って入ってきたブートキャンプ卒業生も多く、それ以外にはあまり関心がない場合も多い
2025年に十分な売上があって2026年に採用できるようになったら、コンサルティング会社にメールしてみるといい
「正しい本」を読むという部分が重要。高校時代に自己啓発書を何冊か読んでみたが、数冊読むだけで、著者が言うようにその大半はファンフィクションに近いのだと気づく
読んでいる間、「これは当たり前なのか？ すでに知っていたことなのか？」とずっと自問することになり、例や物語が多く、「skin in the game」のような単純な比喩やスローガンを人生全体の哲学へ拡張しようとするパターンがよく見える
第2グループのほうが情報をはるかによく覚えていた。人間は物語に引きつけられる存在であり、最古の叙事詩が物語であるのには理由がある。自己啓発書がその公式に従うのも、効果があるからだ。何かを読むこと、理解すること、適用すること、そしてその適用を熟達させることの間には、大きな違いがある
あるアイデア・ルーティン・プロセスを完全に受け入れ、状況が来たときにほとんど本能のように適用できる能力を作ることが、こうした本の核心だと思う。ブログ記事で十分な本もあるし、ページ数を増やすための最悪の長広舌もあるが、多くの物語や叙述は、読者がそのどれかに自分を見いだし、教訓を強く記憶するための仕掛けだ。適切なタイトルを付けたからといって本を責めることはできない
Cal Newportを読むのかとよく聞かれるが、良い指摘と陳腐な指摘を混ぜたうえで例や物語に頼るやり方があまり好きではなく、耐えがたい。例や物語が必要な場面はあるが、そのやり方には説得力を感じない。前の3項目を文章を書くときに思い出せなかったのは残念だし、「Skin In The Game」がまさにTalebの本だという点もおかしい。その本が悪いという意味ではなく、自分をこうしたパターンから免疫化してくれた著者の本が例として出てくるのが面白い
たいてい序盤に良いアイデアが1つか2つ出てきて、残りは繰り返しと水増しだ。この問題はあまりに一般的なので、ほとんどはYouTubeの要約動画を聞くだけでもよいと思う。もう1つのコツは、常に初版を手に入れることだ。概してより短く明確である
再び本を読み始めたら、注意持続時間と集中力が大きく伸び、ドゥームスクロールしたい欲求も減った
多くの人が自分の中でADHDのように見ている部分は、集中能力がまだ発達していない、あるいは意図的に放置されていることとも重なる。全員がそうだという意味ではない。自己判断または専門家からADHDと診断されたなら、集中を要する作業をしながら定期的に集中の筋肉を鍛えているか、ドゥームスクロールや短い動画のようなゴミから自分を引き離しているかを振り返る必要がある。苦痛の召使いのように難しいことを避け、問題を強化する行動にのめり込んでいないか。集中力は誰にとっても消耗する能力である
やや誇張されていて現実はもっと複雑だが、一般原則としては同意する。自分の仕事を本気で気にかけるだけでも、給料をもらいに来ているだけの人たちよりはるかに先に行ける
「才能や関心のない人たちを技術分野へ誘導し始めた社会は、何か大きく間違っている」という趣旨にはかなり同意するが、その考え方は興味深い結論につながる
第一に、技術職の採用プロセス全般は、業界内部で不平を言われているよりもさらに何段階か非効率かもしれない。新人の才能を探すときでさえ、企業は間違ったものを選別しているのかもしれない
第二に、プロスポーツや芸術のようにロングテールを持つ職業では、金銭的インセンティブが非常に悪い。著者が見ている問題に対処するには、この問題も同時に扱う必要があるが、それ自体が深いウサギ穴だ
第三に、状況がそれほど悪いなら、なぜ企業は従業員を現場で直接訓練しないのか
第四に、この機会費用がベーシックインカムより高いのかを、私たちはほとんど問わない。最近の民間部門と公共部門の意思決定が互いに直交しがちだからだ
彼らが課程を最後まで通過したとしても、実際にソフトウェア開発の職を得たと仮定したとき、キャリアでどうなるかは誰にもわからない
ほとんどの場所では、すべての従業員を事実上「完全に訓練済み」と見なしており、奇妙なことに、業務中の訓練を従業員への恩恵のように扱う。これは、技術労働者が会社ごとに短期間しか留まらない文化と結びついている可能性が高い
技術分野の賃金上昇は、プログラマーが十分にいないというシグナルだ。米国の経済成長の大半は、今やプログラミングと技術に基づいている
結局、「支配的なMatlabパイルドライバー」のような話に見える
本を1冊以上読む、ギターを弾く、変な趣味を1つ持つ、準プロの体操選手になるなど、自分の人生経験から何でも差し込み、たいした努力もなく自分がどれほど優れているか、あるいは他人がどれほど愚かなのかについての長いrantを正当化する物語の枠組みを作るようなものだ
読書は促進剤であり出発点に近く、実際にうまくかみ合うようにするのは練習だ。そして、十分に興味を持って調べ、いろいろと自分で試してみることが重要である
https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you...
この前提にはとても同意する。私の技術は3つに分けられる：第一原理から直接発明したもの、本を1冊読んだもの、そしてできないもの。
私ができないことのひとつが、良い本を見つけることだ。本はどこにでもあり、その大半はゴミだが、勧められた本はどれも素晴らしかった。良い本の見つけ方についての良い本はあるだろうか？
https://www.gnooks.com/faves.php
通常のGnod: gnod.com
https://www.literature-map.com/
本のリストを集めたサイトもある。
https://www.goodreads.com/review/list/21394355-william-adams...
https://www.goodreads.com/review/list/21394355-william-adams...
自然に推薦が入ってこないなら、読んで気に入った本の推薦・参考文献、好きだった著者の別の本、あるいは1冊読んで気に入ったシリーズの別の本から探せる。
Geminiのように大規模言語モデルとリアルタイムデータを組み合わせたツールを使うと、結果はさらに良くなる。
「他人が長い時間をかけて考え準備したものから学び、自分はそれをずっと短い時間で身につけようとする」という文とつながる。
https://news.ycombinator.com/item?id=40147526
HNを読むことも自己啓発に入るのだろうか？ このサイトで時間を過ごして得た技術やアイデアの「手がかり」がどれほど多いか、数えきれない。
ここでの話がなければ、会社を辞めて一人創業者になることもなかった気がする。それが良い選択だったかどうかは、まだ言うには早い。
他の方法では得られなかった知識を、浸透圧のようにたくさん得ている。実際に使ってみた技術はごく一部だが、プログラミングのエコシステム全般についてはかなり詳しくなった。「世の中に何があるか」と「何を検索すべきか」を知る助けになる。
ただし、その浸透圧的な知識の95%は、スクロール時間の10%だけでも得られるだろう。総じてHNは時間の使い方としては悪くないが、たいてい私はわざと時間を無駄にしている最中だ。