技術に精通すると、なぜ小さな問題がすべて大きな問題に変わるのか

「The Curse of Knowing How, or; Fixing Everything（方法を知ることの呪い、あるいは、すべてを直すこと）」の中心的な主張は単純だ。技術に精通すると気づくものが変わり、気づいたことが人を疲弊させかねない。この投稿は、プログラミングを習熟へと至る輝かしい道としてではなく、あらゆる粗さを解決されるのを待つ問題のように感じさせる習慣として捉えている。

記事は、ほとんどの開発者にとってなじみのある小さな例から始まる。スクリプトがファイル名を変更する。シェルのエイリアスがコマンドを短縮する。小さな補助ツールがJSONを整形する。いずれもそれ自体は特筆すべきことではない。著者が言いたいのは、人がひとたびその一線を越えると、頭がシステムを違った形で見るようになるということだ。オペレーティングシステム、エディター、ウェブサイト、ビルドチェーン、シェルプロンプト――そのすべてが手を加える対象になる。

そこからエッセーは、苛立ちから責任へと話を進める。ソフトウェアは、決して解決済みのままではいられないものとして描かれている。ライブラリーは非推奨になり、APIは変わり、サイトがHTMLを変更すればスクリプトは壊れ、ミラーURLが切り替わればコンテナは動かなくなる。感情的な反応は、単なる苛立ちにとどまらない。それは罪悪感へと変わる。作ったり直したりした人が、それが朽ちていくと自分に責任があると感じるようになるからだ。

エッセーの表題にある「方法を知ることの呪い」という言葉は、その変化を捉えている。物事の修復方法を知ってしまうと、あらゆる欠陥が、行動しなかったことによる失敗に見えかねない。著者はこれを、終わりのないTODOリストと表現する。あらゆるシステムは改善でき、あらゆる不便は非難の根拠として位置づけられ、あらゆる回避策は新たなプロジェクトの種になり得る。エッセーによれば、技術的な能力が負担を軽減するのではなく、燃え尽き症候群を助長し得るのは、こうしたパターンによるものだ。

この投稿は、コーディングと感情的な対処との間にも関連性を見いだしている。何かを作ると、すぐに反応が返ってくる。スクリプトは動くか、動かないかのどちらかだ。他の多くの問題がより複雑で、解決しにくい世界では、それが慰めになることもある。しかし、摩擦を生むあらゆる要因が、自分の主体性に対する挑戦のように感じられ始めれば、同じ論理が不健全なものになり得る。もう一つツールを作りたい、もう一度リファクタリングしたいという欲求は、自分を落ち着かせる手段になり得ると、エッセーは論じている。

この記事がテクノロジーに関するエッセーとして優れているのは、これを個人の欠陥として位置づけることを避けている点だ。代わりに、その循環を能力そのものの帰結として扱っている。システムがどのように機能不全に陥るかを学んだ人は、失敗に対してより敏感になる。直せるものが増えるほど、直せると想像するものも増え、やめることがますます難しくなる。

そこから著者は、実践的な結論に至る。壊れているものすべてが、あなたの引き受けるべきものではない。悪いユーザー体験のすべてが、あなたの責任ではない。不完全なツールをすべて置き換える必要もない。この記事は技術的な批評というより、技能はものの見方を変え、その見方が人生のあらゆる部分を未完了の仕事に変えてしまうと、重荷になり得ることを思い起こさせるものだ。