普通のエンジニアが素晴らしいチームを作る鍵？
引用元：https://news.ycombinator.com/item?id=43356995
この記事が好きなのは、ソフトウェアエンジニアリングに特別な何かがあるっていうトロープが、業界の人や雇用主にとって有毒だと思うからだよ。今は、金融と似たような感じで、自分の価値を過大評価しているように感じるんだ。自分の仕事をしっかりやって家に帰ることは立派なことで、極端な時間外労働は悪い政策だよ。そして、誰かが調子悪いときに他の有能なエンジニアが代わりにできるはずだから、特別なことなんてないって。
今はもうその境界は越えてるんじゃないの？金融と同じ行動だと思う。テックはもはや地下のオタクたちではなく、富と権力の源になったから、寄ってきたのは権力を求める賢い人たちなんだ。同じ力のゲームが繰り広げられていて、結果も同じだね。
特定の人たちがテックに引き寄せられたわけじゃなくて、むしろ既存の人たちが金持ちになったって感じだと思う。テックの悪いとこはあるけど、金融の人たちのそれと違うんじゃないかな。若いテックの人たちに見られる行動は結局同じで、一部は成長するけど、そうでない人もいるんだよね。
フィールドは大きく成長して、経験年数ごとの世代間バイアスが見えるよ。最近の10～15年でのコホートは、ソフトウェアエンジニアリングの理解が全然違うし、アプローチも最適解よりも早く出すって感じ。新しい世代のバックグラウンドも金融や医療出身が多く、昔の世代はもっと普通の中産階級からだったのが明らかだね。
業界が大きくなると、どんなフィールドでも同じ現象が起きるよね。裕福な家族が過剰に代表されるのは、パートタイムが必要ないから最高の資格を取るのが有利なんだ。実際に、3:1や4:1以上に数で負けてるんだから。
昔からのエンジニアとして言うけど、コードで面白いことができてお金ももらえるなら、それやるよね。ビジネスの制約がある方が、空の中で書くよりも興味深いし、お金も大事だ。
＞ビジネスの制約がある方が、空の中で書くよりも興味深いって言うけど、空の中では絶対に書かないよね。何かしらの目標が常にあるもんだ。
最近の世代は自分の世代についてそう思うんだろうけど、10〜15歳上の人たちも自分たちの世代を同じように語ってると思うよ。どの世代も自分の時代が一番良かったって言いたがるし、常に新しい世代がそれを壊しているってね。
＞10〜15歳上の人たちも自分たちの世代を同じように語ってると思うよ。で、間違いなくその通りだよ！昔はメモリの管理について叱責されたけど、今の時代は違うから。定量的な違いは質的な違いを生むから、今は昔とは違うソフトウェアエンジニアリングの時代なんじゃないかな。
お互い正しいね。でもメモリを無視するのは危険だよ。実際、あるプロジェクトでは256GBのインスタンスを使ってて、例えばCRUDアプリだけど、やっぱりメモリに関する質問がよく出てくるんだ。あまり考えないで作るのはマズいことだよ。
この投稿は色々な意味で妙だよね。特にこの部分について言いたいことがあるね。＞”個人の背景をたどると、より裕福な上中流家庭の出身者が若い層で多いのに対して、古い層はもっと控えめな中流や労働者階級の経歴が多かった。”ってこと。生まれた環境が問題なのか？そんなの変だよ。低い経済的背景の人が優れている訳じゃないし。Bill Gatesも裕福な家に育ち、Harvardに行ってるじゃん。まさに銀のスプーンの話だよ。
だからBill Gatesの話が注目されたわけだよ。驚きだね、Harvardの子供は何をしているのかって。
出ていることが全てって思っている人にとっては驚くだろうね。私もGatesよりほんの少し若いけど、PCが世界を変えてるんだから、他に何をするべきかって感じだったよ。
絶対に違う人たちを引き寄せたね。流入がはるかに多くて、昔とは違うよ。例えば、EEは昔は名誉だったけど、CSはバックアップ的な存在だった。それは法律とか金融と比べるほどでもない。
でも、私の意見では、この変化は90年代後半には起こっていたと思う。急にプログラマーがカッコよくなったのをはっきり記憶してるし、その’新しいタイプ’の人たちが早くも00年代初頭に変化をもたらしていた。お金が賢い人たちを引き寄せたことも確かで、彼らは古いハッカーの精神を持っていない。監視技術を売ってくれたのは彼らだし。
ミッドウェストの職人は、比較的に言えば、Bay Areaのエンジニアよりもずっと裕福な場合が多く、その現実を、彼らは理解している。電気技師は電気技師だし、エンジニアは取替え可能だって。多くのエンジニアは労働組合に入っていて、自分たちの権利を守る必要があるって理解している。コースト側は、実際に逆のナラティブに反して、農地から学ぶことが多いと思う。
テックが富や権力の源になり始めたのは、”2010年代初頭”だって？それは違うと思う。ソフトウェアエンジニアは力がないし、金融に比べれば限られた富しかないよ。
世界の10人の富豪のうち、8人はソフトウェアエンジニア出身なんだ。Musk、Zuck、Bezos、Ellison、Gates、Page、Brin、Ballmer。BuffetとArnaultが唯一の例外だね。
ソフトウェアは違うんだ。他の工学分野は最終的には（せいぜい）3次元の物体を作ることに限られている。空間に隠せるゴミの量には限界があるってことだよ。比較するとコードはハイパーボリック空間に存在していて、そこには何でも隠せる。これを例えれば、ソースコードの周囲に無限にあるフォルダーは、その位置を意味のある場所に移動するのがほぼ不可能になるってことだ。
他の工学分野はせいぜい3次元に制限されているって言って、それを良くない手法で過小評価するのはやめてほしい。何世紀も存在する工学分野を軽んじるべきじゃないよ。コンクリートはただの砂と砕石とセメントと水なんだ。すごく複雑なんだよ。木材だって、束になった繊維で巨大な建物を作ることができるし。ソフトウェア工学は徐々に成長しているが、そんな人たちを侮らないでほしい。
どこからそんなことを言ってるのかわからない。全ての工学分野はプロジェクトをめちゃくちゃにする余地が少ない。ソフトウェアは1980年代後半からデザインスペースが広がり続けてるんだ。他の分野と比べて、ソフトウェア工学には自由度があるんだ。たとえば、鉄道がより高次元の空間に埋め込まれたら複雑になると思う？ ソフトウェアは特別じゃない。どの分野にも無限の深さがある。2Dの鉄道はシンプルに見えるけど、それは意図的な場合もある。複雑なソフトウェアを書くこともあり、複雑さは他の分野に比べてはるかに高いこともある。 物理工学は実データや歴史に基づいている。一部の電気エンジニアはソフトウェア工学に転向しているが、逆はあまり見ない。実際の工学は正確さが求められるから難しい。ソフトウェア業界の90％は大したことない仕事をしてる。 noosphrのコメントをどう読んでる？“ソフトウェアは他の工学と比べて高次元のデザインスペースを持ってるから、より混乱しやすい”と理解したよ。リアルな工学は難しいにもかかわらず、ライフラインに関わる場面では本当に注意が必要だ。 このコメントは侮蔑的に捉えられたんじゃないと思う、リラックスして。 スレッドを良い方向に解釈するように編集した。プログラミングが公に悪い印象を持たれないようにしたいから、戦っているよ。リーダーとしての責任を感じるんだ。 ソフトウェアが他の工学とは異なるのは、それが学問ではないからだと思う。反復サイクルが速いのが魅力なんだ。物理ハードウェアよりも高い抽象レベルにいるので、試行錯誤が多い。 学問はあるよ、成長が早いだけで。多くの技法は残るし、クラシックになる。ただ、何が流行で何がクラシックかを見極めるのは時間がかかる。 ソフトウェアで流行だと思うものとクラシックなものの例を教えてもらえる？ 1970年代には、変数を参照する際に名前を省略できるプログラミング言語が一般的だった。たとえば、単に“patients = 400”みたいな感じだった。今では明らかな“足元をすくう罠”だが、一時的に良さそうに思えたんだ。 実際に略語をサポートしてたのか、名前の最初の3文字だけを保存するようなことをしてただけなのか、気になるところだね。まるでコンパイラが8kのRAMに収めようとしてるみたいだ。 TDDについては意見が違うよ。周りの仲間がTDDやってるのを知るたびに驚く。要するに、TDDは死んだ、TDD万歳。LLMがCRUDプロジェクトの大部分を生み出す未来でも、TDDは企業プログラマにとって数十年、いや永久に有効でいると思ってる。 手法は制約がないって言えるね。それは、制約が交渉不可能なエンジニアリングとは違う。機能的プログラミングをやる人は、制約とその鍛錬を楽しんでいると思う。 金融工学であれば、オフバランスシートの負債やシステミックリスクなど、何でも隠すことができるよ。 このコメントは変だけど、HNっぽいね。2008年以前のオフバランスシートの問題は大分解消されていて、今はシステム的に重要な金融機関をカバーするグローバルな規制者がいる。金融工学は以前よりリスクも低くなって、透明性も高くなったよ。 かつては10Xだと言われてた。徹夜で働いて、気に入らないコードは書き直してたけど、長時間働いた後は、疲れて作ったおかしな問題を修正するハメになる。急いで完了させても、結局プロジェクトは中止になったり、期限を守れなかったりして、何のメリットもなかった。注意力は超能力だよ。 ＞徹夜で働いていた。これは10Xプログラマではない。10Xプログラマは1/10の時間で同じ機能を提供する人だ。私が思う10Xプログラマの一人はPeter Norvigで、彼が一機の飛行機で書いたこのスペルチェッカーはまさに芸術だ。 ＞この記事が気に入ったのは、ソフトウェアエンジニアリングには特別な何かがあるという考えは危険だと思うから。新しいデザイン空間で働くソフトウェアエンジニアの比率は約1：5だろう。土木工学のような成熟した分野ではその比率が1：500に近い。同じようなことをしているエンジニアがたくさんいる。 ソフトウェアエンジニアリングが他の工学と大きく異なるのは、働いている人のかなりの割合が基本的な技術を欠いていることだと思う。多くのソフトウェアエンジニアはプログラムが書けず、言語の基本的な事実すら思い出せない。次回、チームの普通のメンバーに頼んでみて、その様子を観察してみてほしい。こういった人たちがコードを書くのは、かなりの割合で助けをもらいながらだからね。 この記事にはほとんど同意できない。ソフトウェアは個人が作るもので、特にペアプログラミング時以外はチームじゃない。複雑な技術プロジェクトは超優秀な一人の人間が担当することが多い。平均的な12人チームの中に、本当に全員を支えている2人がいるのは明らかだ。Aクラスの人材はAクラスを採用し、BクラスはCクラスを呼ぶ。チームを立ち上げる過程は怠惰と妥協と戦う反復的なもので、この記事はただ”妥協しろ、それほど悪くない”って言ってるに過ぎない。 40年間ソフトウェア開発をやってきて、こんな誤解だらけの投稿は珍しい。自分は何度も”10倍”の開発者だった。確かにパフォーマンスの良い人も悪い人もいる。でも、素晴らしいソフトウェアは素晴らしいチームが作るもので、個人ではない。アメリカンフットボールのチームを思い浮かべてみて。QBを10倍のプログラマーと見ることもできるが、他のチームメンバーがQBを活かしていることを無視するのは無理だ。ソフトウェアはチームスポーツなんだから、そのことが分からないなら理解すべき。 ＞“素晴らしいチームが素晴らしいソフトウェアを作る” この例は、君が言いたかったことの真逆を証明している。 どういう意味でそう言ったの？ https://openssl-library.org/post/2018-12-20-20years/ 君のソースにはこう書いてある: そんなアナロジーは悪い。なぜなら、一人のフットボール選手が試合を自分一人で勝ち取ることは絶対にできない。でも、一人の開発者が全体の製品を自分一人で作ることは可能だし、必ずしもチームスポーツではない。こうも言えるし、”鍛冶屋はチームスポーツだ！”なんてナンセンスだ。 もちろん、一人の優れた開発者が全てを自分で完成できることもある。でも、実際には彼らはいつも時間やリソースに限られた状況でタスクを割り当てられている。彼らには限られた時間に書けるコードの量や考慮できるデザインの数がある。優れたエンジニアが書いたソロプロジェクトは素晴らしい作品になることが多い。でも、大抵の場合、プロジェクトにはチームが必要で、現実的な時間とリソースの要件を満たすためにはなおさら。だからスポーツアナロジーが出てくる。 誰も地球上の全ての作業が個人によってできるとは真剣に主張していない。もちろん、王の軍隊を優れた武器で備え付けるために設計し、リードする職人は、自分で全ての剣を作っているわけじゃない。でもチームスポーツという表現は非常に誤解を招くし、彼が10倍の存在でないとは当然言えない。 NBAのようにスーパースターがチームを引っ張ることもあるけど、結局はCavsやBoston、OCKみたいにスーパースターと優れたチームが勝つ可能性が高いよね。 君の現実モデルに反例があるのかが大事だと思う。もし簡単に見つかるなら、その自信過剰な態度は君に何を示すのか考えた方がいいよ。例えば、Fabrice Bellardのように。そうした優れた人は、君が思っているほど特異な例じゃないし、現実には普通のメンバーの支えがあってこそ成功する。 Fabrice Bellardは君が思うほどの反例じゃないよ。彼は優秀だけど、始めたプロジェクトにずっといるわけじゃないし、バグを整理したり、CIを設定したり、リリースのタグ付けやサイト運営といった地味な仕事を誰かがやらなきゃいけない。チームがソフトウェアを出すものであって、個人じゃないんだ。 反論した相手が議論している用語が曖昧すぎるのが不満なんだ。ソフトウェアには時間が関わるから、一人の開発者が複雑な問題に取り組んで、他の人もその問題解決が楽になると参加してくれる。彼らは特別な存在で、普通の開発者がやる重要な仕事を軽視するのは違うと思うんだ。 優れたチームは優れた個人で構成されている。最もパフォーマンスが良いメンバーの割合がチーム全体の文化やパフォーマンスを大きく左右するんだ。 ほとんどの複雑な技術プロジェクトは一人の天才が所有してるってのはおかしい例だと思う。彼は今や単なる delegator であり、何千人もの貢献者がいるんだから。 君の言うことには一理あるけど、スポーツチームのように、特に才能ある人たちは個々の認識を求めすぎる面があるんだ。だからプレイヤーが多すぎると問題になることもある。プロの“普通の”メンバーが必要なのはそのためだよ。 優れたエンジニアたちは“普通の”エンジニアと仕事をするのに疲れることが多い。優れたエンジニアばかりのチームと“普通のエンジニア”のチームでは文化がまったく異なるから、彼らはすごいエンジニアを引き寄せるんだ。 大きなスケールに達する前から、優れたエンジニアはやりたくない地味な作業がたくさんある。そして、本当に優れたエンジニアは難しい問題を解決して、普通のエンジニアが扱えるようにすることが求められるんだ。だから、10xエンジニアは確かに存在するけど、オールスターチームはあまり機能しない。 人々が地味な仕事にモチベーションを持たない理由は、文化の問題であってスキルではない。優れた人だけで構成されたチームは、オーナーシップ文化が深まるから、みんなが地味な仕事にも取り組むようになる。優れたチームこそが最良の働き方なんだ。 みんなが“優れた”エンジニアを必要としてるわけじゃない。普通のビジネスアプリに対しては、賢い解決策はいらなくて、ただサンでクリーンでメンテナブルなコードを書いてくれる人が必要なんだ。 定義の問題かもだけど、俺が言いたいのは、”優れたエンジニア”ってのは、LeetCodeのハード問題を15分で解く人じゃなくて、ビジネスに5～10倍の影響を与える人が1/5いるってこと。チームを管理してるなら、そういう人で全員構成するのが目標であるべきだと思う。記事はそれに反対だけど、俺は全力で反対だよ。 数年前にGoogleが出した論文があって、結論は、高い信頼関係を持つチームが最も生産的だって。10倍エンジニアのいるチームじゃなくて、こういうのがソフトウェアエンジニアリングには有害だよ。 優れたエンジニアってのは、最も”素晴らしい”コードを書いてる人じゃなくて、問題を理解して、最もシンプルな解決策を選び、次に触る人のために楽にしてあげる人なんだよ。 俺の経験では、あなたが言ってるような人は、”5～10倍のビジネス影響”を持ってるように見られることは少ない。特に”次に触る人を楽にする”ってのは会社の時間の非生産的な使い方だと思う。その基準で測る人は避けるようにしてる。 ＞”安心できるが偽りの主張。優れたエンジニアは普通のエンジニアと働くのに飽きてしまう、尊敬できる他の人たちと働きたい”これは若手を育てる素晴らしい環境だね。全然毒性のある環境には聞こえない。 大規模なプロジェクトに関わったことある？何百人、何千人も関わって、数年にわたるプロジェクトなんだ。その場合、10倍エンジニアの仕事は薄まっていく。平均的な人がますます重要になってくるんだ。 10倍ってのは生産する行数のことじゃない。プログラミング言語やツール、データベースの設計/スキーマについてなんだ。間違った言語やツールを選ぶと、必要な作業量が簡単に10倍に膨れ上がる。 多くの場合、頑張ってる人たちは自分で自分を苦しめてるようなもんで、チームにも自分にも良くない。俺の会社には日常の問題を処理するための運用チームがいて、書類作成してティケッティングのセットアップをして渡すんだ。そうすれば他のことに集中できるんだ。 君はエンジニアリングスキルを過剰に最適化してる。ほとんどのプロジェクトにはAプレイヤーばかりのチームは必要なくて、そんなにこだわると限界が出てくるよ。 大きなプロジェクトでも小さなプロジェクトでも、重要な役割を担う人がいて、他の人たちがサポートしていた。結局、その人がプロジェクトを成功に導くんだよね。 それって、重要なプロジェクトで一人のエンジニアが全てをやってるってこと？そんなことないと思うけど。プロジェクトの規模や複雑さに関係してる気がする。一人で全てをやるなんてあり得ない。 そうじゃない。もう一度読んで。毎回同じ人が重要な役割をするわけじゃない。人は役割を交代しながらやるんだよ。 この意見には賛成だね。1人が最も多くの仕事をするけど、少数の人がそれに続き、残りは普通の人になる。この生産性分布を理解することがマネージャーには重要だよ。普通の人たちを生産的にすることが大事だけど、高いパフォーマンスを出すエンジニアを妨げないことも忘れちゃダメ。 その通り。生産性の差は急激だから、それを指摘するのはタブー化してるかもね。 ありがとう。ほとんどのソフトウェアは数人の優れたエンジニアが多数の無能な人と戦いながら作られているんだ。10倍のパフォーマンスなんて現実には届かないよ。長期の開発者が間違った前提で複雑なシステムを作ったせいで、手を加えられなくなった。 Aプレーヤーって実際のスキルじゃなくて、その人がプロジェクトを一番よく知ってるからっていう理由が多い気がする。 その投稿、すごく失礼だけど確かにそう。3週間進行中のコードをレビューしてみたら、たった200行のシンプルなPythonコードだったことが多々ある。 人によっては、プロダクションに不安定なものを出さずにちゃんと考えて作業してるかもしれない。1,000行のコードレビューやバグ対応も含めて、会社の収益はコード行数ではないよ。 生産性や品質をコード行数で測れると思ってるの？それは完全に間違ってる。 IEEEっていつからこんなクリックベイトなことばかりになったんだ？これはまるでジュニアエンジニアが感覚だけで書いたエディトリアルみたいで、ちょっと恥ずかしい。生産性を測る方法や、重要なアウトプット、さらには’普通’のソフトウェアエンジニアなんて存在するのかっていう誤解まで、全部おかしいよ。もっとコメントを表示（1）
もっとコメントを表示（2）
OpenSSL、つまり全世界の金融システムや埋め込みデバイスに使われている標準暗号ライブラリは、長い間、2人のフルタイムエンジニアによって作られ、維持されてきた。2014年のHeartbleed事件があってから、そのプロジェクトが二人の無名の人物と少数のボランティアによるものであることが判明した。チームワークも重要だけど、時には多すぎる料理人が反って悪化させることもある。個々の頭脳の大切さは、素晴らしいアイデアやプロジェクトを生む源だから。
OpenSSLはチームで作られたから、歴史を読んでみて。
＞“最初の15年間、OpenSSLのメンバーはほとんどパートタイムで働いていた少数の個人で構成され、会員数はその間に変動した。”
自分はOpenSSLが一匹狼の成果だと言ってないし、チームがコーディングに不要だとも言ってない。チームワークを呼ぶことが単なる現象で、個人の貢献の重要性を見えにくくするところが本質なんだ。コードは心の鏡だから、優れたコードとそうでないコードを区別できることは、優れた開発者とそうでない開発者を区別できることを意味する。もっとコメントを表示（3）
