開発者の呪い：直せる者が背負う無限の責任感
(notashelf.dev)- 些細な自動化を繰り返していると、ある瞬間からあらゆるツールやシステムが直すべき対象に見えてくる認知の臨界点に達する
- 技術力が積み上がるほど、問題を単に認識するだけでなく、責任のように感じてしまう感情の重みを抱えるようになる
- 直したいという欲求は、単なる生産性向上を超えて感情を調整する手段にもなり、ときには自分が作ったシステムに自ら閉じ込められる結果を生む
- システムは時間が経てば必ず壊れ、完全な解決という幻想は存在しない
- 結局本当に必要な技術は、すべてを直す能力ではなく、何かを直さずにいても耐えられる心の余裕である
始まりは些細な自動化
- ファイル名を変えるPythonスクリプトや
gitコマンドの短縮など、小さな生産性向上の作業から始まる - システムの不便さを自分で直してしまうと、世の中のあらゆるものが改善対象のように見え始める
- ある瞬間から「できる」を超えて「やるべきだ」という道徳的な強迫観念へと変わる
技術力の重み
- プログラミングを始める前なら不便なソフトウェアもやり過ごせたのに、今では問題点がはっきり見える
- 開発者が作った粗いコードやハードコーディングされた設定が非難のように感じられる
- あらゆるシステムやソフトウェアが直すべきTODOリストのように見える認識の転換が起きる
終わらないリファクタの日々
- 毎回「これは自分ならもっとよく作れる」と考え、自分専用ツールの開発にのめり込む
- 整理されていないコードディレクトリ、無数の試行と放棄、終わりのない構造の再設計は、自己拘束的な労働にもなりうる
- Kafkaの「鳥かごを作って鳥を待つこと」という比喩のように、目的のないツール作りに沈み込むことがある
ソフトウェアは朽ちる
- 完璧に見えたスクリプトも、いつか外部の変化によって役に立たなくなる
- Webサイトのレイアウト変更、パッケージのバージョン変更、依存関係のエラーなど
- 問題が起きたとき、単なる不便さではなく罪悪感を覚えるようになる
- 結局は継続的なメンテナンスが必要だという現実に向き合うことになる
自動化という幻想
- 「一度だけ設定すれば、もう触らなくていい」という偽りの希望をたびたび抱く
- プログラミングを問題解決の勝利だと考えがちだが、実際には終わらない戦争にすぎない
- 完成という概念はなく、いつも水浸しになる塹壕を掘り続けているだけだ
感情を整える手段になったコーディング
- ツールを作る行為は、ときに人生の混乱を制御しようとする心理的な反応である
- システムが複雑であるほど、むしろ自分自身は整っているように感じる
- 複雑な人生から逃れるために新しいアプリやリファクタリングを試し、自己慰撫を得ることがある
前触れなく訪れるバーンアウト
- バーンアウトは単なる過労よりも、過剰な責任感から生まれる
- 「自分が直せるものを、なぜ直さないんだ？」という自己非難がストレスを増幅させる
- 終わりのない技術的責任感は、自己破壊的な重荷として作用する
手放す技術を学ぶ
- すべての問題を解決する必要はない
- ときには直さなくてもよいと知ることのほうが、より大きなコントロールである
- 欠陥を認め、そのまま使うことも意識的な選択になりうる
本当の技術は感情の明晰さ
- 直せる技術よりも、直さなくても平気でいられる心の技術のほうが重要だ
- いつ止まるべきか、どのプロジェクトが自己慰撫のためのものなのかを見分ける力
- 何もかも直そうとする強迫から離れ、不完全さの中でも心地よさを見つける姿勢が必要である
> 結局、プログラミングで最も難しい技術は、
> 「壊れたものをそのままにしておく方法」 を学ぶことだ
21件のコメント
あらゆるものには目的があります。目的を達成したなら、もう直し続ける必要はありません。ですが、目的を達成できていないなら、直すべきです。
プロジェクトの目的を明確に把握することが出発点になりそうですね。
世の中には、銀行や決済会社のめちゃくちゃなAPIをまとめて整理してあげるだけで、数千億ウォン規模の価値を持つ企業もあると気づくと気が楽になります（笑）
クx..
VB 6.0 と COM + OLE + ActiveX で作られたシステムが今でも問題なく動いているのを見て、ぞっとして書き直したくなる衝動に駆られるなら、あなたは苦しむことになる人です
結局、プログラミングで最も難しい技術は、
「壊れたものをそのままにしておく方法」を学ぶことだと思う。
共感します。自分は仕事を広げてしまうタイプなので、いつも苦労しています……
ただのプログラマーがその場しのぎで組み上げた自動化なんて、壊れるのは当然ですよね
良い内容
バーンアウトのトーテム
: 苦労して業務を自動化したのに、その恩恵は隣の同僚が受け、自分自身は別の業務の自動化作業に投入されるとき;
15分で終わる仕事を2日かけて自動化した、給料泥棒の一人です
過剰な責任感は、プログラマーの職業病のようなものなので、システムで解決してあげるべきです。
Quality Assurance チームが assurance してくれるべきでしょう。
QAは開発者の過剰な責任感を抑えてくれるということでしょうか？ よく理解できなくて。
開発者に対して過失の有無を問いつつ「お前のコーディングが悪かったんだ」が積み重なると
開発者は責任感に押しつぶされて新しい試みを避けるようになり、
結局は進歩のない安全なコードしか書かなくなります。
QAがAssureしなければならないというのは、そういう意味です。
発展的なコーディングをするには、ある程度のリスクは負うものですし、
それを検証して責任を持つのがQAであるべきなのです。
そんなふうにも読めるんですね？ 私はこの記事は、あえて言うならヤクシェービングを批判する文章だと思っていましたね
roxie さんのおっしゃる通り、本文についての話はヤクシェービングの話で間違いないのですが、
私個人の経験に照らしてみると、本文の内容とは少し方向の違う話になってしまいました。
NIH（not invented here）現象でも説明できるのではないでしょうか。保守運用はすなわち固定費であり、そのコストには人の労力も含まれることを忘れてはいけないと思います。
これを長く続けるには、過度な責任感で報酬心理の呪縛にはまってしまう前に
ときには責任と感情の重さを下ろす練習も必要なのだと思います。
私もなかなかうまく調整できない部分でもあるのですが、笑…いい内容ですね
これは良いポイントだと思います。責任感とは文字通り責任を感じることなので、それ自体は見返りを求めないものですよね。ですが時間が経つと、心身は疲弊していく一方で責任感は簡単には消えず、そのギャップを埋めるために（本来そう結びつけるべきではないのに）見返りを求め始めてしまうのだと思います。本人も気づかないうちに。
まあ、「壊れたものをそのままにしておく方法」よりは、まだマシな妥協点は「壊れるまでは触るな」でしょうね :)
Hacker Newsのコメント
演劇をしていたときに学んだ言葉がある。芸術のプロセスとは、難しいことを習慣にし、習慣になったことを容易にし、容易になったことを美しくすることだという
UIの問題について個人的な意見を述べている
個人プロジェクトの難しさをこぼしている
ソフトウェアエンジニアへの敬意を表している
完璧主義への批判を述べている
個人的な洞察を共有している
家族や子どもが完璧主義を和らげる助けになると述べている
ソフトウェアを自分で書くほうが、より楽しく、よりシンプルな解決策につながる
新しいものに執着する文化こそが問題の根源だと主張している
心理学者は人を、最大化を目指す人と、十分に良いものを探す人に分類している
「壊れたものをそのままにしておく方法」よりも、「重要でないものを手放す方法」のほうが、より適切な表現のように思います
必ず直さなければならないものは、直すべきですね
共感します。自分が庭をよりきれいに手入れしているのか、それとも重要な作業をしているのかをよく理解したうえで、手放すべきだと思います。