コードレビューで「なぜそのミスをしないだけで済まないのか」や「なぜただこうしないのか」といったことをよく聞く
最近は「たぶんあなたの IQ が私より高いからでしょう。私は IQ が低いので、もっと愚かで単純なことをしなければなりません」と返している。すると相手が、自分がどれほど内省もなく人を見下す小さな変人のように振る舞っていたかに気づき、顔を赤らめることがある
私の好きなポッドキャストの1つであるYouTubeのwell there's your problemは、ポッドキャストに文句を言うコメントをほぼ必ず固定表示する。たいていは「このポッドキャストが気に入らないから別のポッドキャストになるべきだ」という程度の不満で、固定されるコメントは毎回、そのエピソードで可能な限り最も愚かな解釈に近い
そういうコメントを減らす効果があるのかは分からないが、そういう形で言論に参加する人に比喩的なばか帽子をかぶせる意味はある
一部のエンジニアに悪い態度があるという点には同意する。誰でも悪いコードを書くことがあり、すべてのコードは悪く、負債であるという論理にも一理ある
この記事は「No more pink mustache」とあわせて読むと興味深い。その記事でLyftは「信じがたい規模で壊れている」と描写されているが、品質の原因はしばしば椅子に座っている人ではなく組織なのだ :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
1件のコメント
Hacker News のコメント
1人なら必要な作業を優先順位に入れられるが、チームでは次善の判断が永遠に残ったり、「システムダウン」の瞬間まで放置されたりする。その後のポストモーテムで、何カ月も前からその爆弾を直そうと依頼していたチケットを指すと、「非難」や「攻撃的」と受け取られ、結局のところ解決策は次善のコードを絶対に書かないことのようになってしまい、コーディング時のフラストレーションと不安が増した
2017年に、2003/2004年に書いたコードを直してほしいと連絡を受けたこともあるが、そのコードはまだ本番で動いていた。壊れたコードや妥協した部分を見直し、その責任者がまさに自分だったと気づくのはかなり謙虚にさせられる経験で、その後、保守可能なコードとドキュメント化に対する見方が大きく変わった
S&P 500 の大企業、1億〜10億ドル規模の企業、スタートアップまで含めて、こうした経験は普通だった。このような場合には、合理的な妥協をし、ビジネス上の必要も押さえられる熟練したソフトウェアエンジニアとマネージャーがいて、エンジニアが顧客と直接やり取りすることも多かった
要はバランスであり、そのバランスはたいてい、バランスよく判断できる人によって作られる。「完璧」だけを追い求めると終わりのないリファクタリングと未リリースに向かい、技術的負債やゴミのような品質を無視すると、時間がたつにつれて事業が崩れることもある。どこに位置取るかは、プロダクト、業界、顧客、ビジネスによって変わる
過去の自分は若くて純真だったが生産的で、多くの山を越えた。コードを把握するのに2日かかったが、結局かなり賢かったし、今の自分が全部忘れているのは記憶力が悪いせいかもしれない
未来の自分はすべての過ちを正すだろう。もっと年を取り、賢くなっていて、XXX と TBD を賢いコードに置き換え、良いアイデアは実装し、まあまあのアイデアは再実装する無限の時間があると信じている。もっと良いコメントがあれば、この3人は1つになれるかもしれない
単なる学習機会であるだけでなく、オープンな文化を示し、インポスター症候群にも対抗する効果がある。完璧主義的な態度はその逆で、「もっと努力してミスをするな」がすべてなので、学べることはなく、個人の努力だけをさらに求めることになる
あるとき、ジュニアが報告書に誤ったソフトウェアバージョンを入れた小さなミスを私が引き受けた。顧客に「ミスがあり、修正済みの報告書はこちらです」と言えば済むことなのに、上司は「これを隠して、われわれが完璧だという体面を保てるか？」だけを考えていた。同じ人物が、他人のミスは値引き、補償、無償提供を要求する機会にしていた
それでも問題ない。変える理由ができたら整理すればよく、それまでは悪い慣行と、より良いアプローチを示す例として残っている
最近は「たぶんあなたの IQ が私より高いからでしょう。私は IQ が低いので、もっと愚かで単純なことをしなければなりません」と返している。すると相手が、自分がどれほど内省もなく人を見下す小さな変人のように振る舞っていたかに気づき、顔を赤らめることがある
質問自体が悪いわけではないが、「私のアイデアはとても簡単だ」と「あなたはこの明白で簡単な考えに気づかなかった」という前提が、いら立たしく、あるいは侮辱的に感じられる。逆に自分が他人に尋ねるときは「なぜただ」を避けるようにしていて、「X をしなかったのには何か理由がある、と理解してよいでしょうか？」のように聞くか、単に親切に理由だけを尋ねるほうがよい場合がある
文脈不足から出る質問なら、自分のしたことを説明する前に、最も obvious な方法がなぜ駄目だったのか、あるいは厄介な要件や問題となる入力を先に明らかにしておくことで防げる。すでにコミットされたコードなら、コミットやマージリクエストのコメントで、後からの蒸し返しを減らすのが目標になる。ときには反論せず、その方法を試したがなぜ駄目だったのかを直接説明し、本当にほかのアイデアがあるか尋ねるのも有用だ
本当に自分が考えていなかった提案で、問題を解けそうなら、良いアイデアだと言って実装を手伝ってもらう。そういうとき、相手の前提や言い方に反発したくなる誘惑はあるが、ただ受け入れて少し恥ずかしがるほうを選ぶようにしている
「複雑さとティラノサウルスのどちらかと1対1で戦えと言われたら、grug はティラノサウルスを選ぶ。少なくとも grug にはティラノサウルスは見えるからだ」
2つ目の質問は、たいてい妥当なフィードバックになり得る。人々のスキルと知識は常に重なっているわけではない。Aにとってめちゃくちゃ複雑なものがBにとってはそうではないこともあり、その逆もあり得るし、必ずしもどちらかがより賢いからというわけでもない。AはSQLを知らないかもしれないし、Bはpandasを知らないかもしれない
すでに技術スタックにSQLとpandasの両方があると仮定すると、あるコードをSQLからpandasへ移したり、その逆に移したりするのが理にかなう場合がある。オブジェクト指向スタイルを簡単だと感じる人もいれば、関数型スタイルを簡単だと感じる人もいる。何がより妥当かは常に明白とは限らないので、その質問がよい質問である可能性はある。提案が悪ければなぜ悪いのかを説明し、よければ今やる価値があるかを考えればよい。中間だったり時間がなかったりするなら、それを認めて先へ進めばよい
そうすると、相手は次善のことをしたという理由でこちらに恥をかかせたり罪悪感を抱かせたりしにくくなる。こうした発言の目的は、しばしば羞恥によるマウンティングだと思う。そのゲームに参加しないという選択であり、たいていそれが勝ち筋だ
たとえば保存する項目が10個なら単純なファイルが実用的な選択かもしれないが、10,000個になればデータベースが必要になるかもしれない。ところが最初から10個のためにデータベースを使っていたら、過剰設計だと文句を言われていただろう
クラスが2つならif/elseで十分だが、20個になればFactoryパターンが必要になるかもしれず、最初からそうしていたらアーキテクチャ宇宙飛行のように見えただろう。こうした成長を予測しようとして外すと、複雑なコードを作ることになる。開発が続くプロジェクトは、構造的に自分自身より大きくなっていく
悪意あるコメントを判断なしにリンクするのは悪い考えではない。コメントがdead扱いされると常にできるわけではないが、いずれにせよ同じやり方でやり返しはしない。自分にもできるが、ガソリンは効果的な消火剤ではないと学んだ
自分が間違っていたなら、その間違いがあった同じ場所で、すぐに認めるようにしている。公の攻撃の後に非公開で謝罪するのは特に嫌いだ
とはいえ線引きはある。私は自分がかなり良い仕事をしていると感じているし、40年ほど長くやってきて、その間に多くを学んだ。低品質な仕事を受け入れない厳しい環境でも働いたことがあるので、ちゃんとした仕事を習慣的にするようになった
一般に、公の場で他人を裁くことは避けている。役に立たないし、自分が常に正しいわけでもないからだ。ただし、一緒に働く場合やその人のものを使う場合は別かもしれない。私がゴミを受け入れないという理由で荒っぽく攻撃されたこともあるが、Linus Torvaldsのようには振る舞わない。可能なら敬意ある形で、その仕事は自分には受け入れられないと伝える
それでも常に改善し、新しく学ぶことはでき、ときにはまったく予想もしなかったところから学ぶこともある。こうした学びに開かれているのは、基本的に良い方針だ。私は間違い、学ぶことで正しくなる。「良い判断は経験から生まれ、経験は悪い判断から生まれる」
そういうコメントを減らす効果があるのかは分からないが、そういう形で言論に参加する人に比喩的なばか帽子をかぶせる意味はある
この記事は「No more pink mustache」とあわせて読むと興味深い。その記事でLyftは「信じがたい規模で壊れている」と描写されているが、品質の原因はしばしば椅子に座っている人ではなく組織なのだ :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
選択肢は3つある。諦めてその領域を明け渡し、そのまま人生を続けること。不公平さのせいで眠れない夜が少なければ少ないほどよい。正面から対抗すること。彼らは戦う準備ができているが、立場自体が本質的に不合理なので、彼らの思考空間に引き込まれなければ引き込まれないほど「勝つ」。上から降りてくること、つまり彼らが間違っているという社会的証拠を彼らの空間へ持ち込むことだ。元の記事の場合なら、お互いの仕事を尊重し、揚げ足を取らずに生産的に働くプログラマーたちがそれに当たる
助言する人が対人関係の苦手な間抜けかもしれないし、単に完全な間抜けかもしれない。世の中の一部が自分に同意しなくても大丈夫。人々が反対意見を言ったり同意しなかったりするからといって、自分を脅かしているわけではない
こういう人たちは、自分の好むフィードバックのやり方が最善で、誰もが同じように感じるべきであり、そうでなければ相手が変わるべきだと考える。もちろん間違っている。だがこれを指摘すると、なぜ最初の文で「ほとんど」と言ったのかを自ら示すことになる