生産性という蜃気楼

 (frantic.im)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • Facebookの伝説的エンジニア Bob は、精緻な開発環境がなくてもFacebook Groupsをリリースし、ハッカソンで次々と成果を出していた
  • 基本設定の Sublime Text と printf ログだけを使っており、シンタックスハイライトは不正確で、ライブリロードもデバッガもない環境だった
  • 一方、周囲の開発者たちはVimのシンタックスハイライトやスニペット、tmux、mosh、hphpd のショートカット、Gitエイリアスなど、複雑なツール構成こそが生産性の核心だと考えていた
  • Bobのハッカソン優勝には、エディタ設定よりも プロダクト感覚と直感、つまり何を作るべきかを判断する能力のほうが大きく作用していた
  • 新しい作業方法が変化を生むことはあるが、最終的な成果は 正しい問題を解くこと から生まれる

複雑なツールと実際の成果の違い

  • Bob はFacebook Groupsをリリースした多作なエンジニアであり、ハッカソンで次々と成果物を出していた伝説的な人物だった
  • 当時、生産性に没頭していた同僚は、FacebookのPHP方言である Hack のために自作したVimのシンタックスハイライトとスニペットを使っていた
    • mosh 上で tmux を実行し、カスタムの hphpd ショートカットやGitエイリアスまで設定していた
  • Bobの作業スタイルは、それとは対照的に非常にシンプルだった
    • 追加設定のない Sublime Text を使っており、コードの色分けの半分ほどが誤って表示されていた
    • ライブリロードやデバッガの代わりに、コードに printf を入れてログが出るのを待っていた
  • その日のハッカソンでBobは優勝し、その成果物はFacebook Groupsで売買投稿をサポートする機能だったと記憶されている
    • この機能は後に Facebook Marketplace へと発展した

どのように作るかより、何を作るか

  • 複雑なツールに集中すると、作業方法である どのように に埋没し、作業対象である 何を を見失いかねない
  • Bobの高い生産性を生んだ核心は、エディタ設定ではなく プロダクト感覚と直感 だった
  • Xには毎日のように、すべてを変えそうな新しい作業方法が登場しており、その一部は実際に変化を生む可能性もある
  • しかし最も重要なのは、ツールや作業方法そのものではなく 正しい問題を解くこと である

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Hacker News の意見

  • 道具を大切にする職人と道具に執着する人を二分するのは誤り。良い道具はおもちゃではなく目的のための手段であり、自分も作業フローに合わせたシェルスクリプト、Emacs 関数、ウィンドウ配置ツールなどを作るのに何日も費やしてきた
    その結果、構文ハイライト、コードの探索・分析、画面配置、Git 操作が数回のキー入力だけでできるようになり、集中を妨げる要素が消えた。椅子、シェルプロンプト、エディタのような作業環境に投資しつつ、快適になった後はそれを忘れて実際の問題に集中すればよい
    ただし終わりのない道具調整は、しんどくて面白くない課題を避けようとしているサインかもしれず、これは道具自体のせいという単純な話ではない

    • 新しい職場で新しい技術スタックと Windows ノートPCを渡されたらどうするのか。キャリア初期には与えられた環境の基本ツールだけで効率よく働く方法を学んだし、実際に道具を自分で選べる場面はまれだった。クロスプラットフォームツールも JetBrains 製品群を除けば一貫性に欠けることが多い
    • サムライとニンジャの違いのように見える。サムライは刀を魂の延長と見なしたが、ニンジャは必要なら刀で物をこじ開けることもした。現代の経済ではサムライ的な道具観は合わない
    • 道具を楽しく使えることは重要。生産性が 10 倍にならなくても、作業に集中して過程を楽しむことが核心だ
      特に LLM 時代の道具は複数のエージェントやターミナルを行き来し続けることになる。この頻繁なコンテキストスイッチは楽しさとフロー状態を奪うので、誰かが解決策を見つけてほしい
    • 初心者は認められ、真剣に扱ってもらいたくて必要な段階を飛ばしてしまうことが多いように見える。そう見えることと実際にそうなることは別であり、実力を積み上げる間にも生計は立てなければならない
    • 技術を習得した後は、良い道具それ自体が大きな喜びになる。逆に熟練者は、ときに不適切な道具でも驚くほど良い結果を出せる

  • 実際に作ることより環境設定の最適化に多くの時間を使う技術者をたくさん見てきたし、自分もそうだった。コーディング時間の 90% がタイピングだから入力速度を上げるべきだという考えは誤りで、時間の 90% は思考に、その大半は読むことに使うべきだ

    • ソフトウェアは問題に対する解法を具体化したものなので、まず解くべき問題を定義しなければならない。コードは現在の問題理解と、解法の明確さ・適切さを未来の自分を含む皆に示すスナップショットだ
      適切な時点でのコーディングは、すでに理解した解法を具体化するタイピング作業に近い
    • 以前は設定に執着していたが、AI を使うようになってからは、以前なら作れなかったようなすごいものを作っている。一方で基盤コードへの理解と既存の実力は徐々に弱まり、新しい手法に感嘆しつつも深く学べていない気がする
      AI は始める際のハードルを下げてくれたという点で、別の形の環境改善でもある。以前 QA から開発者に移ろうとしてヨーロッパを旅しながら InterviewCake を勉強していたときも、問題を解くよりエディタ設定をいじることに時間を無駄にしていた
      これはADHD の症状かもしれない。最近薬物治療を受けてから生産性が大きく変わり、実際の仕事をするより設定を完璧にすることに人生の半分を浪費していたのではと、涙が出るほどだった
    • 実際の生産性と体感上の生産性の間には乖離がある。Vim や Emacs で巧みにコードを打てばハッカーになった気分にはなるが、生産的だという意味ではない。大量のトークンで AI エージェントを何十個も指揮しても、成果物が動くとか問題を解決する保証はない
    • 平凡な CRUD アプリケーション開発者の大半にとって、時間の 90% を思考と読解に使うべきだという比率が本当に正確かはわからない
    • 思考とタイピングはしばしば同時に起こる。多くの人はコードを書いて直しながら問題をより簡単に推論できるし、LLM が生成したコードを全部読んだとしてもコード理解が大きく低下しうる理由でもある

  • 実際に使われたり、お金を払ってもらえたりする製品を作れない VC 投資先企業は存在する。彼らは企業価値を正当化するために、どれだけ忙しく生産的かを見せようとし、AI ブームも何を作るかより生産性や方法論にばかり集中している点で同じ文脈かもしれない
    https://components.news/the-gamer-and-the-nihilist/ は、こうしたニヒリスティックなスタートアップと、人々がお金を払って使う製品を作るゲーム開発会社を比較している。生産性アプリが Product Hunt の成果物のほぼ 40% を占める経済では、実際に何かを作るより、作っているように見せることに労力が投じられることもある

    • ゲーム開発者も道具作りに莫大な労力を注ぐが、主な対象がテキストエディタではないだけだ
    • ゲームそのものより完璧なゲーム環境を作ることに無数の時間を費やす人や、音楽そのものより完璧な機材を一生探し回るオーディオ愛好家は、この比喩ではどこに入るのだろうか
    • バブルというより、昔から繰り返されてきたシグナル操作に近い。ずっと存在してきたし、これからも続くだろう

  • 遅れを取らない程度にだけ生産性ツールを作るか使い、それ以上は罠だと見ている。以前は四半期に一度見直していたが、AI 以後は週に 1〜2 日を道具改善というメタ作業に使っており、関連ツールが標準化されれば減ると予想している
    道具の専門家というイメージが強くなると、実際に価値ある仕事を逃すだけでなく、秘密の生産性ノウハウを持つ人だと評価されるようになる。期待ほど差がなければ、ほかの判断まで信用されなくなるかもしれない

  • コンピュータの前にいる時間が短いほど、より多くの仕事を片づけられたし、モニターを 3 台から 1 台に減らしたら生産性が大きく上がった。野菜を切ったり芝を刈ったりしているときに大半の問題を解決しており、光る技術の前に座っているからといって、より速くより良い判断ができるわけではない
    顧客企業の開発チームより良い成果を出せる理由も、正社員ではなく、十分に立ち止まってゆっくり考えられるからだ。Teams のステータス表示を緑のまま保とうとする圧力のような生産性の演技が、多くの組織で愚かな意思決定を生んでいる

    • 15 年間、カリフォルニア州 La Jolla の海を見下ろす崖の上にオフィスがある 2 社で働いた。崖や公園を歩きながら仕事のことを考え、ホワイトボードが要らない真剣な議論なら同僚に一緒に歩こうと声をかけていた。Rich Hickey のhammock talkは聞き直す価値がある
    • ユーザー名を見ると、文中に出てきた Bob なのか気になる

  • 生産性が存在する理由を考えた末に、苦痛を減らそうとする試みだという仮説に至った。プログラマーの生産性を含むさまざまな性能最適化は、問題領域の曖昧さ、組織政治、不明確さ、失敗リスクといった苦痛を避けるための、エンジニアの逃避先になりがちだ
    しかし現実の問題を解決するには、ユーザーのワークフローを退屈なくらい細かく検討し、共同戦略を明確に提案して他人の協力を得るなど、現実と向き合わなければならない。苦痛そのものを美化する必要はないが、良い成果物にはアスリートのような訓練が内在しており、競技場で必要な苦痛を管理する能力を育てるべきだ

  • 核心は評価されやすいかどうかにある。きらびやかな道具は誰が見ても感嘆できるが、空のエディタや骨組みコードの中に優れた新製品や機能を見る人は少ない。だから目に見えやすい道具に関心が集まり、難しく不明瞭な「何を作るか」は顧みられない
    道具には Marie Kondo 式の基準を適用している。使っていて楽しくもなく、暮らしを楽にもしてくれないなら捨てるし、そうでなければ残す

  • 2004 年、ほとんどが初級開発者で構成された小さなチームが、優れた大規模な Java 研修を受けることになった。研修前は IntelliJ と Eclipse の設定に執着して激しく議論していたが、講師は意外にも基本のJDK ツールと Notepadだけを使うよう勧めた
    内部で何が起きているかを学ばせるのが目的で、生産性にもおそらく大差はないと言っていた

  • 環境最適化に執着するのは、注いだ努力と報酬のつながりが目に見えて具体的で、物理的だからだ。一方で抽象的な学習はそうではない。椅子を最適化する作業より学習課題のほうがはるかに多いのだから、抽象的な学習ももっと具体的に感じられる方法があるとよい

  • 生産性ではなく、おもちゃで遊ぶ楽しさの話だ