「部分的に壊れたコンパス」のエンジニアの例を挙げてもらえる？

それが僕の基準でもある。複雑なものをシンプルなステップにまとめられる人にはいつも感心する。K&R Cの例のコードみたいにね。でも、お願いだから、もっと良いコメントを残してほしい。

プロジェクトに適したパフォーマンス要件とのバランスを取ることも大事だし、同じように健全なコミュニティがあって、続けていけそうな依存関係を選ぶことも大切だよね。ベンダーを選ぶときも同じで、「次の契約更新のときにぼったくられるか？」とか「もしぼったくられたらどんな選択肢があるか？」って質問が必要。

みんな「そんなの誰でも書ける！」って言うけど、問題の領域によるよね？ファスト逆二乗根[0]のコードを良いセンスだと思う？ [0] https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...

必須のシンプルさを簡単に。何かがシンプルだからって、誰でも理解できるわけじゃないからね。

そして悲しいことに、こういうコードの作者は、KISS原則に従って他の人の時間と労力を節約していることに対して、認識されないことが多い（たいていそうだよね）。理由は分からないけど、他の人には透明じゃないみたい。だから、テクノロジー業界には、無駄な複雑さを持つシステムを扱ったり維持したりするための仕事やチームが存在しているんだ。

でも、問題は人にその価値を理解してもらうことなんだよね。コードが退屈に見えるし、実際退屈だし。多くのジュニアだけど優秀でやる気のある開発者（自分も含めて）は、賢いコードを書きたいと思ってるけど、実際にはその必要がない環境にいることが多い。CRUDのバックエンドとフロントエンドにはこの問題があって、複雑さは（あるべきではない）コード自体ではなく、ドメインやアーキテクチャなどの高次の部分にあるんだよね。それに、退屈さからアーキテクチャを過剰に複雑にする人たちもいて、スケーリングのような見かけ上の問題やカゴ文化に基づいて、マイクロサービスやラムダを持ち込む代わりに、単純で実績のある解決策で目の前の問題を解決することをしないんだ。だから、「シンプルなCRUDアプリケーションのためのJava開発者を探しています」っていう求人では、優秀な開発者は見つからないよ。

その通り。エンジニアが特別なことをする能力があるのは時々便利だけど、最初は手強そうに見える問題に対して、シンプルで普通の解決策を一貫して見つける方がもっと良いよね。

それは良いセンスじゃなくて、良いエンジニアリングだね。

読めないコードには2つの広く見られるクラスがある。誰にも読めないコード。これは読めないコードだ。それから、作者（AIでも人間でも）にしか読めないコード。これも読めないものだ。「可読性は概念ではない」と言うのは本当に変だ。

反対だな。誰かがコードを読む能力は指数関数的に成長するわけじゃない。数年の経験を積むと、みんな同じプラトーに達する。経験年数が多いからと言って、もっと複雑なコードを理解できるわけじゃない。「3〜4年の経験があるエンジニアの大多数にとって可読性がある」と目指すなら、それが目標に達しているってことだよ。

その方程式の話だけど、彼が書いたときはかなり難解だと考えられてたんだよね。今のものはずっと美しくて「読みやすい」とされてるけど、それはヘイヴィサイドや他の人たちの仕事のおかげなんだ。

+1、著者自身の話に戻るけど、慣れが大きな役割を果たすよね。新しいエンジニアがマッピングやフィルタリングに精通していれば、手動ループがほとんどないコードベースに乗り込むのが楽になると思う。

完全に同意。読みやすさは実際に「読む」+「能力」という言葉そのものにあるよね。コードと読者の両方の能力が関わってる。

私をナイーブだと思ってもいいけど、ジュニアでも会社で働き始めたら、基本的な構文やイディオムには慣れてるべきだと思うんだ。それでも、言語の特徴を使いすぎると、誰にとってもコードが読みづらくなることがあるよね。例えば、古典的なif/elseを好む人もいれば、悪名高い三項演算子やその多くの子孫を使うのを好む人もいる。でも、結局は自分の好みに戻るんだよね…

読みやすいコードは、読者に対する共感を持っていて、解釈の認知負荷を最小限にしようとするコードなんだ。それが抽象化レイヤーやデザインパターンの目的の一つでもある。確かに、これは主観的で、読者の専門知識やコードベースへの既存の慣れに依存するけど、コードの読みやすさが存在しないって主張するのはおかしいよね。ジョイスの『ユリシーズ』がスースの『キャット・イン・ザ・ハット』と同じくらい読みやすいって言うの？

コードの可読性は指標じゃないよ。トレードオフなんだ。結局のところ、プログラマーが迷ったときに、読みやすいコードを選ぶか、ちょっと難解で巧妙なハックを選ぶかってことだね。

「ローカルコード」の可読性について悩む価値はほとんどないよ。コードベースの大部分で同じパターンを使うことが、全体の可読性を高めるんだ。たとえそのパターンが複雑でも、あまり逸脱せずに繰り返し使われる限り、コードベースは可読性を保つことができる。要するに、ローカルで孤立したコードは、コードベース全体に感染しなければ、どんなに読みづらくても問題ないんだ（共有可能なミュータブルステートや悪いAPIを使うことで感染する場合を除いて）。

「服は独立していると意味がない」という意見には賛成できないな。衣服は、組み合わせる前から文化的、歴史的、象徴的な重みを持ってるし、ファッションは単にアウトフィットを組み合わせることだけじゃないからね。ファッションにはトレードオフもたくさんあるし、制作だけじゃなくて、日常の着こなしやミックス＆マッチにも関わってくるんだよ。

大多数のエンジニアや技術者はファッションセンスがあまり良くないから、一般的な良いセンスを理解するのが難しいんだよね。技術的なものの大半は普通の人にはクールじゃないし、オタクっぽいんだ。プログラミング言語もクールじゃない。だから、プログラミングでは「クールじゃない」からスタートして、スケールを下がっていく必要があるんだ。クールじゃない：Rust、C++、ほとんどの言語 痛々しくクールじゃない：関数型や変わったもの。Bash、Linuxなど。

ソフトウェアエンジニアが決めている主観的な組み合わせは、単なる技術的なトレードオフの問題じゃなくて、本当に好みの問題だと主張できるものは何だろう。技術的なトレードオフだと思っていることの中には、絶対に確認できないものや、トレードオフが非常に小さいから実際には重要じゃないと思うものもある。

りんごとオレンジを比べてるみたいだね。ファッションの良いセンスは、ソフトウェアエンジニアリングよりもずっと主観的だよ。明らかに、一方は主観的な分野で、もう一方は常に形式的な科学に結びつくから。面白いのは、ソフトウェアエンジニアリングが社会科学から始まることで、ほとんどの選択が無意識に、あるいは少なくとも他の人と話し合わずに行われるってことだね。

あなたが探求したい考え方は、美しさやエレガンスの認識にもっと関係してると思う。それは歴史上の哲学者たちのテーマで、単一の記事でカバーできるとは思えない。クリストファー・アレクサンダーは建築に関してこれを深く研究していて、彼のアイデアはソフトウェアアーキテクチャの多くの思想家に影響を与えた。アレクサンダーは客観的な美が存在することを主張している。OOPSLAカンファレンスでのアレクサンダーの基調講演は読む価値があるし、ロイ・フィールドリングの論文もそうだ。この記事に出てくる「価値」は、フィールドリングの論文では「アーキテクチャの特性」として整理されている。

この原則（ごめんね；）はすべての分野に当てはまるよね。もっと思い出せたらいいな。優しいリマインダー、ありがとう！

だからこそ、いろんなプログラミング言語を試すのが好きなんだ。次に理解しようとする言語は、知っている言語とはできるだけ違うものにしようとしてる。そうすることで、常に「ひらめき」があって、既存の考え方に挑戦できるから。それを他の言語にも適用できるしね。最初は「おかしい」とか「変だ」と感じることを受け入れないといけないよ。それがなぜそうなるのか、どうなるのかを理解するまでは。

すごくいいコメントだね。君の考え方は、僕が直接雇用する人たちや、プロジェクトに関わる人たちに対するアプローチと似てる。物事を達成する方法は色々あるって認識することが大事だよね。最終的な結果や目標が達成できれば、僕の具体的なやり方やプロセスに合わせる必要はないんだ。

「良いセンス」って、良いAPIや他の「良い」コードを経験することで養われると思う。良いコード（やAPI）を見たら分かるし、時間が経てば自分でも書けるようになるはず。ただ、新しい分野にいると、良いコーディングセンスを持つのは難しいよね。（でも、君が指摘するように、経験が必ずしもセンスを保証するわけじゃない。センスを求めて、認識して、反映させることが必要なんだ。）

確かに、経験豊富なエンジニアでもこういう未熟さに陥ることがあると思う。経験が必ずしも成熟につながるわけじゃないんだ。特に成功を収めたエンジニアは、自分のやり方が正しいと信じ込んでしまうことが多いから、経験を積むにつれて自分のやり方に固執することが一般的なんだよね。

私もCSの課題を手伝ったときに全く同じ経験をしたよ。その時は、彼らの既存のアプローチに合わせる知恵がなくて、もっと過激な書き直しに傾いてた。彼らがバカだと思ったわけじゃなくて、単に彼らのアプローチが好きじゃなかったんだ。理解しようとする時間も取らなかったしね。

ジュニアに対して、最適じゃないやり方をしているとは絶対に言わないよ。いつも、どうしてそのやり方を選んだのかを聞くようにしてる。会話の最後には、どちらかが何かを学んでる。時には私が別のアプローチを学ぶこともあるし、時には彼らがそのアプローチが長期的にはうまくいかない理由を学ぶこともある。どちらにしても、対立的な会話にはならないんだ。

成熟度は経験の時間と必ずしも相関しないし、感情的・社会的成熟も生物学的年齢とは必ずしも一致しない。私がこの論文のアイデアが頭に入ってきたのは、キャリアの12年目だった。

経験を積むことで、優れたプログラマーはソフトウェアエンジニアリングの主観的な部分と客観的な部分を認識し、区別することを学ぶと思う。そして、前者にはもっと緩やかでオープンなアプローチを、後者にはより厳格なアプローチを持つようになるんじゃないかな。

偏見やバイアス、固い考え方の解決策は、個人の世界観を超えた教育や経験だと思う。誰か他の人の視点を通して世界を理解しようとすることが、自分自身やプロとして成長する方法なんだよね。エンジニアとして、幅広い知識を持つ者として、別の角度や解決策が存在することを知るだけで、問題に対する見方が変わって、最初の直感よりも良い解決策が思いつくことがあるんだ。