いわゆるサバイバー・バイアスです。あるVPが、以前の会社でうまくいったからという理由でエラスティックサーチを使うように命じました。結果的に、私たちにも合っていました。VPの言うことを聞いて技術的な決定を下し、エラスティックサーチを使いましょう。

実は私も似たようなことを言いに来ました。

ああ、ベイビー、これが私のシニア開発者だ。避ける人、減らす人、リサイクルする人。彼らはできるだけ開発を避けたがります。これが良い時もあれば、改善を積極的に試みるのが最善の方法である時もあります。良いシニアは、その時を見極めることができるのです。

OPが伝えようとしているメッセージを見落としているかもしれないよ。強調された特性は、すべてより良い安定性につながるからなんだ。

同意する。文脈が重要だよね。シニア開発者としては、複雑さやリスク、利点と欠点を理解する必要がある。ビジネスサイドも理解しないと。スタートアップか、すでにキャッシュカウの大企業かで、製品のコア機能を変更する際の影響は全然違うから…文脈、文脈、文脈だよ。

同じこと考えてたけど、再度その部分を読み返して気づいたことがある：>「はい、はい、もちろんこれは単純化されています。アイデアを明確に伝えるために、極端な例を挙げているのです。」全てのことに言えるけど、黄金の中庸が適用されるって、この記事が主張してると思う：>「'スピード'バージョンのシステムでうまくいったことといかなかったことが、'スケール'バージョンのデザインに影響を与えています。」

みんなが「これが昇進したらゼロから書き直す」と約束したことが何度かありましたが、結局実現しませんでした。古い名言：「一時的なハックほど永続的なものはない。」

だからこそ、十分に経験のあるエンジニアリングリーダーシップが必要なんだよね（ICリーダーシップと管理の両方）。もしエンジニアが非技術的なステークホルダーの言うことを何でも従うなら、責任の空白ができて、いつかは大惨事が起きる。最もCYAが下手な人が責められることになるよ。一方で、ほとんどのビジネス問題は、十分に視野を広げて「なぜ」をたくさん聞けば、ひどい一方通行の扉を通らずに合理的に解決できる。もちろん、どこでもエンジニアリングがそれを許可されるわけじゃないけど、許可されないところでは、経験豊富な人たちを維持できなくなる。彼らは自分の判断が評価される場所に行くだけだから。時には技術的負債がビジネスにとって正しいこともあるけど、十分に経験のあるエンジニアは、常に逃げ道を作ることができる。でも、システムの純粋さをビジネスの問題よりも優先することはできない。システムはビジネスによって支払われているから、それを見失ったら、影響力の基盤を失ったことになる。

だから、チームの誰も聞いたことがない言語で書かなきゃダメなんだよね。

何度かみんなが約束したのを思い出すよ。「これが昇進したら、ゼロから書き直す」って。でも、結局そんなことはなかった。なんでそんなことするの？ もし需要を満たしてて、必要な機能もあって、実際には再構築する必要がない「プロトタイプ」があるなら、なんでそんなに時間と労力をかけるの？ それは意味がないよ。プロトタイプや「概念実証」であることは、実際の問題を列挙できないなら本質的には関係ない。私は、技術的負債に悩まされてるチームと一緒に働いてるけど、彼らはそれが大きなリスクで、作業を遅らせるって文句を言ってる。でも、私たちのインシデントログを見ると、あまりインシデントはなく、プロダクションでリスキーなコードを実行してるせいで起きたものもない。リスクレジスターにも「このコードは古くてゴミで、過去のEOL依存がある」なんて項目はないし、どのチームも技術的負債がどのように、またはどれだけ彼らを遅らせているかを具体的に説明できたことはない。だから、誰もが「影響がない問題を直すのに時間を使ってほしくない」と驚くべきではない。逆に、あるチームはアプリを立ち上げる前に数ヶ月かけてリファクタリングしてた。彼らはそれを作った後、「もっと良くできる」と決めて、立ち上げ前にほとんどを再作成するのに多くの時間を費やした。彼らが自分たちの作品が気に入らないから、すべての価値が遅れたんだ。そして、当然リーダーシップチームはそれに怒って、今では信頼がほとんど残ってない。チームとステークホルダーの間で仕事の納品について良い会話が必要だけど、それがないと誰も幸せになれない。もしそれが起こらないなら、ステークホルダーが常に勝つことになる。

この問題は確実にAIコーディングエージェントが登場する前からあったけど、彼らによって悪化しているかもしれない。記事は「一つは捨てるつもりで計画しろ」という古いアドバイスで締めくくられてる。もちろん、私も『神話の人月』を読んだけど、どうやって意思決定者を納得させる？

最初のPoCが予想外に本番に入った後、私はPoCを作るのをやめて、MVPを作り始めた。最初に見せるものがすぐに本番に入る準備ができているわけではないけど、最初から本番に入ることを前提にPoCを作って、作業中に本番に持っていく計画を立てるようにしてる。

そうそう、優先順位と透明性があれば、人々が問題を解決するために使うべき変数を変えられるんだよね（もしそうできないなら、仕事が下手ってこと）。嵐が来るまでに2時間あったら、「水が溜まりすぎて、排水できなくなるかな？」って考えるはずで、建築について考える余裕なんてないよ。俺が見てる問題は、管理側がどれだけお金があるかとか、実際のタイムラインについて話さないで、ゲームみたいにやってること。貢献してる人たちが重要な瞬間の前に去っちゃうのを恐れてるから、みんなその状況の中でバカな決定をし続けて、結局新しい仕事を探す羽目になるんだよね。

一番いい戦略は、顧客の視点から自分の主張を構築することだね。

「これによって、クライアントWが文句を言っているこの問題に対して、Yのユースケースをサポートする機能をX日で展開できるようになる。」 こんな感じの主張は、 「将来的な拡張性のためにZをやるべきだ。」 「Zは最終的に新しいプラットフォーム機能を可能にするかもしれない。」 「Zはユニットテストがしやすい。」 ビジネスの文脈では、今までの経験からすると成功する可能性がかなり低いと思う。

私の経験では、回避者や削減者、リサイクラーは、私のアイデアを避けて、自分のアイデアをやりたがるんだよね。

これらの多くの要素は、複雑さによって直接影響を受ける。

ジュニアが何かの任意の側面を見たときの第一印象としての「複雑さ」は、常に悪いもの、過剰で悪いものだ。システムの開発を次の10人年にわたって簡単かつ迅速に進めるための「複雑さ」は、素朴なアプローチが真っ直ぐ進むときに、実際には脇道にそれることを意味する。亀とウサギの話だね…最初の2週間で急いで成果を上げようとする衝動（簡単に取れる成果、目に見える勝利、MVP！）が、未熟な設計や開発中のメンテナンスの必要性によって、ますます勢いを失うのが不思議でしょうがない。数週間「速く」進んでいたのに、結局スケジュールが6ヶ月遅れたってことだ。

一番大事な要素の一つを見逃してるよ：使いやすさ。

トレードオフ！これが重要だと思う。プログラマーじゃない人は、トレードオフがないと思ってるけど、プログラマーはデザインのあらゆる側面がトレードオフだって気づくべきだよね。

まさに俺の経験そのもの。君の言い方は俺よりも外交的だね、ハハ。若い人たちは、情報や知識が他の人から得られるってことを知らないか、知りたくないみたい。若さの傲慢さが100倍って感じだよね。ポケットやデスクにスパコンがあって、「すべて」を知ってるAIがいるのに。今、教師ってどんな感じなんだろう。君のAIはオフィスの人間関係をどう説明するの？CTOの意見は？最近の障害や学びについて話す（その詳細はブログにはあまり載ってないけど）？彼らは知識と事実だけが必要だと思ってて、歴史や政治、コミュニケーションなんていらないと思ってる。AIやGoogle検索は彼らを挑戦したり、押し出したり、反対したりしないから、それが心地よくて、学びよりも魅力的なんだと思う。

これが今の仕事での私のフラストレーション。無駄が多くて、誰もそれを避けようとしない。経験の浅い開発者が「AIマジック」を使ってURLバリデーターを置き換えようと提案した。私は、キャッシュされたファジーマッチの解決策（AIで事前に入力されたもの）を提案したけど、誰も気にしなかった。今、AIモデルが突然却下されて、システムが壊れちゃった。全システムを再検証しなきゃならない。私より昇進した若い開発者が、修正方法の文書を作ろうとした。「ねえ、ダン、手伝ってくれない？」って言ってきた。彼は、文書を書いて会議を開くことで昇進したんだ。合理的に物事を進めるのではなく。今、彼は私の仕事を使ってリーダーシップを示そうとしてる。誰も気にしない。私がより良い解決策を提案すればするほど、経験の浅い開発者にとっては脅威になる。大体のことはうまくいってるから、マネージャーは気にしない。もっと良い方法があったかもしれないけど、無駄と戦うのは疲れるし、ただ良いコードを書きたいだけなんだ。

他の州で仕事を始めたのは、面接官の一人が非常に優れたシステム管理者で、彼から学びたかったからなんだ（最初の仕事、スタートアップで、システム管理に自分を追い込んでしまったので、学ぶために頼れる人があまりいなかった）。もちろん、私が着いた直後に彼は辞表を出した。後任を見つけたからね。だから、私にはあまりうまくいかなかった。

あなたが出会った後輩たちは、自立することに執着してるのかな？それとも自分のアイデアにプライドを持ちすぎてる？先輩たちの経験の中には、肉体的なレジリエンスもあると思う。業界に入った時と比べて、別に賢くなったわけじゃない。ただ、 trenches（戦場）にいることに慣れただけ。自分の心理をどう扱うか、簡単そうに見えることが実はそうじゃないこと、そしてひどいこともそうじゃないことを学んだ。これを後輩に詳しく説明できるけど、彼らが実際にその地雷原に立つまでは、あまり意味がないんだよね。

あなたが専門家かもしれないけど、一般的なルールとして言えるのは、みんな「専門家」が自分の「専門知識」をシェアしたがるのにうんざりしてるってこと。実際、「専門家」が「専門知識」をシェアしたいという需要は、供給に比べて桁違いに少ない。どこかに「専門家」の話を聞いてお金をもらうビジネスがあると思う。彼らは自分のことを良く思えるし、ウィンウィンだよね。だから、もし人々があなたを「専門家」と見なさず、あなたに答えを求めないなら、あなたは単に「専門家」として認識されていないか、観察可能で否定できない証拠（資格じゃなくて、ソフトウェアのことね）が必要な高いハードルがあるんだ。競争も激しいし、「専門家」だと思っている人が多すぎるから、明確な「専門家」の証拠を示さないと認識されないよ。

HNがあるから、ここにはいつも誰かいるよ、友達 :)

だから、30年の業界経験があるのに、共有する相手がいないってわけじゃない。マジで。こんなにたくさんの知識や専門性を持っているのに、ほとんどの人が興味を持たないか、他の人に伝えようとすると嫌われるのが辛い。最近は、組織の知識には価値がないみたいだから。

それはとても上手く言ったね。

じゃあ、エンジニアリングの問題だ。ジュニアを10倍育てる方法を考えてみて。

だから、私は詩でしかコミュニケーションしないんだ。複雑さは君が思ってるほどじゃないから、ちゃんと聞いてみて。

https://en.wikipedia.org/wiki/Tacit_knowledge

良いところは、LLMがこの問題を解決するために、すべてを言葉にできると仮定して、世界を納得させることだね。

会社は既存のサービスを既存のユーザーに対して提供して、対価を得ている。会社は現在の市場で現在および潜在的なユーザーに新しいサービスの可能性を提供して、その新しいサービスがどれだけ価値があるかのフィードバックを得ている。