レガシープロジェクトに関わらないとシニアエンジニアとは言えない！？
引用元：https://news.ycombinator.com/item?id=43047341
同意せざるを得ないな。ネットフォーラムでのデベロッパーの反応から、その経験のタイプが分かることが多い。たとえば、”適切なコードレビューをしていればこんな問題にはならない”なんて言うランダムな開発者もいる。でも、すべてのレガシープロジェクトが悪いわけじゃない。ちゃんと開発されているものなら、ローカル環境のセットアップが面倒なだけのことも多いし、運が良ければ誰かがその大変な作業をやってくれてることもある。ちなみに、経験豊富な“シニア”デベロッパーでも、仕事が下手な人はたくさんいる。彼らはひどいコードとアーキテクチャの決定で惨めな製品をデリバリーする経験だけが豊富で、誰もそれを指摘してくれない。そして今や“シニア”だから誰も何も言えなくなってる。企業で働く多くの開発者はこの痛みを理解している。3000行のストアドプロシージャを直さなければならなくなった仲間たちにエールを送るよ。
この三種類のプロジェクトを通じて、僕はデベロッパーとして成長した。1. グリーンフィールドプロジェクト
2. 他人のレガシープロジェクト
3. 自分のグリーンフィールドプロジェクトがレガシープロジェクトに成長する。
それぞれから学べることが多いが、最も目を開かされたのは、僕たちのグリーンフィールドプロジェクトが開発者が増えていく中でレガシー化していったことだ。中にはエゴが強く、リファクタリングを繰り返してすべてをぐちゃぐちゃにする人もいた。一方で、状況を理解し受け入れることで、実際に改善する人もいた。
僕の経験上、こういう傲慢な人は、自己不安からの防御の殻のように感じる。外見は同じでも、内部では不安な人にはアプローチできるが、本当に傲慢な人には近づけない。ほとんどの困難な人は実はいい人で、一緒に働くのが楽しい。お互いに調整し合う必要がある。
何かしらの絶望や正直さから来てるかもしれない。KindleのOSについて読んでいて、職場で巨大な難題に直面している人がどれだけいるのか考えさせられた。
その投稿から：＞”Kindleは、簡略化されたLinuxで、React NativeのフロントエンドとJavaのバックエンドアプリケーションを使用している。” そもそもこの構成のどこが問題なの？OSがあって、Javaやネイティブコードで書かれたサービスやユーザーアプリがある。Luaは橋渡しのために1つのコンポーネントで使われているだけだし、GUIはReact Nativeで、ネイティブGUIの設計と実装を簡素化するフレームワークに過ぎない。具体的に何が問題なの？
彼らの好ましいスタックを使っていないから。好ましいスタックとは、彼らが知っているものである。
そのミーム画像はとても面白い。おすすめの読書： https://kindlemodding.org/kindle-os/kindle_os.png
リンクを読みながらバスの中で思わず声を出して笑っちゃったよ。あのインフォグラフィックは本当に真実すぎる。
どうやって？何かアドバイスは？
人との共通点を見つけることが、関係を改善するための素晴らしいきっかけになることがわかった。彼らのことをもっと知るほど、協力が進む。自分からアクションを起こすのが大事で、相手に求めても意味がない。また、彼らの価値観を受け入れる必要がある。もし彼らが持っている価値観が自分に合わない場合は、 compartmentalizeしてその領域には関わらないようにしてきた。難しい人たちとうまくやっていくために、人生全般で努力してきたけど、成功の方が多かったよ。
色んな人と一緒に働くのって、実は大事なスキルなんだよね。協力することができる人がいる一方で、すごいけど一緒に働きにくい人もいるから、価値観を受け入れなきゃいけない。どうにもできない価値観に遭遇したら、俺はそれを切り分けて対応してる。
失敗をオープンにするのが大事だよ。それと、質問するのを普通にするために、手本を示すことが重要。互いに認め合い、価値観を明示することもね。健康的なダイナミクスを普段から示すのがポイントだと思う。
ポイントは色々あるけど、他人にクレジットをシェアすることが大事。素直に「わからない」と言うのも良いし、ジュニアに意見を言わせる環境を作るのも重要。批判は建設的に、チームワークで進めることが大切だね。
教えることが学びにつながるって、すごく良いことだと思う。自分が書くことは、ちゃんと調査して理解を深める助けになるからね。
教えることには大きな意義がある。知識を教えることで深く理解できるようになるし、再訪することで新しい発見もある。学ぶ姿勢を持ち続けることが大事だね。
自分がオープンでいることも大事だよ。
強くなるためにペナルティを受け入れてるだけじゃダメだと思う。信頼関係がなければ、ただのドアマットになってしまうことも。
脆弱性を見せることは、境界を持たないことじゃないよね。
まさにその通りだね。強い背中を持って、優しい心を持とう！
その言葉、いいね！覚えておくよ。
フリーランスで様々なプロジェクトやコードベースに触れることで成長したなぁ。限られた時間や予算で理解する余裕もないけど、価値を提供しなきゃいけないのが面白かった。前の趣味の開発とは全然違った。 ＞”3. your green field project growing into legacy project.” 最近、シニアとして成長してきた気がする。リファクタリングとクイックハックのトレードオフを考えるのが上手くなった。自分が取り組んだ機能にはこだわりがあって、新しいメンバーに壊されたくないから細かくレビューしたり、リファクタリングを求めすぎちゃう。 そうそう！３番が謙虚さを促すポイントだね。 自分の判断で苦しむ経験があるからこそ、教訓が残るんだよね。 マジでそうだよね。後にレガシープロジェクトで働くと、それを改善するチャンスがあって、ただ見守るだけだった頃とは全然違った。 自分のグリーンフィールドプロジェクトがどうレガシー化してるか見て楽しんでる。新しいチームが色々と面白いことやってて嬉しい。 ＞”3. your green field project growing into legacy project.” 経験豊富な開発者の反応や態度でその人の経験値がわかる。特にHDやネットフォーラムで、外的な制約のあるプロジェクトを経験したことがない人がいるよね。 厳しい制約の中でも良いパフォーマンスする仲間を見るのはすごいことだ。頑張って頑張って、その中で「まあまあ」なコードや文書を書く姿は感動する。 毒のある会社からはさっさと離れた方がいいってのが典型的なHNの解決策だよな。でも今はそんなのも通用しないかも。 見た目だけがシニアな人が多すぎる気がする。タイトルを使って『私のやり方が正しい』って態度を取るのは本当にショックだ。シニア開発って他の役職とは違う意味があると思うんだ。 ＞私は『シニア』と『経験豊富な』デベロッパーは違うって知ってるんだ。それに、シニアとも言えない人が多い。経験が悪いプロダクトを生むこともあるからね。会社での在籍年数だけじゃないって話なんだよ。 タイトルなんて今やほとんど意味がないだろ。経験豊富な開発者の視点は、若い人には理解されにくい。ソフトウェア開発はコードだけじゃなく、文化や人との関わりが重要なんだ。 経験の浅い開発者は、アイデアや哲学に執着しすぎて、現実的な視点を持ってる先輩の意見を受け入れないことが多いよね。 でも実際はこんなことは起こらないよ。 こんなのは起こるべきじゃないけど、実際経験したことがあるな。 ＞経験豊富な『シニア』開発者が実際には役立たない場合も多い。悪いコードやアーキテクチャに基づいたプロダクトばかり出してる実情があるからね。ある意味エンジニアリングの悲劇だな。 WindowsカーネルやLinuxカーネルも古いけど、全然『レガシー』じゃない。手を加え続けられるソフトウェアは良いものだと思うな。でも結局、主観的な話だよな。 新しいポジションのエンジニアだけど、誰も触りたがらない古いレガシー製品にいつも手を上げてる。会社がどうプロジェクトに取り組んでるか学べるし、過去に解決しなきゃいけなかった問題もわかる。ビジネスロジックがあるし、ドキュメントも時々残ってるから助かる。これで修正方法が少しわかるようになれば、その会社でのキャリアが守られるんだ。 他の人のコードを読むのは勉強になるし、自分の自信にもつながるね。 逆に、3ヶ月以上前の自分のコードを読み返すのは、謙虚になって恐ろしくなるよ。 こういうことはよくあるけど、仕事のコードに関して。プレッシャーがあって納品しなきゃいけなくて、コードが何度も書き直され、エッジケースが見つかって修正して、そのまま本番で。いつもそうだけど、個人のコードには誇りを持ってるよ。初年度のプログラミングでも、いい解決策を書くために作ったって感じがある。すごく気持ちの状態に影響される。 これは人生の多くの側面に当てはまるね。他の人のやり方を見るのは、自分の自信にもつながる。 ＞うまく自信を育ててくれるね。 インポスター症候群は同僚の神格化によって悪化する。賢い同僚を超人視しちゃうけど、時には彼らも人間的なミスをするってことを思い出すことが大事だよね。 若手開発者たちが自信を持てるように、自分の失敗や最近学んだ基本的なことを見せるのが一番いい。そうすると、私が高みから物を言ってる感じがなくて、彼らが自分の失敗を認めやすくなる。みんながずっと学んでるんだってことが伝わるし、実際どう思っているか聞きづらいことも話せるようになる。サブdevの特権として、ミスへの寛容が得られるのだから、私だけでなくみんなにも学んでもらうようにしてる。 もちろんだけど、レガシーソフトウェアで学んだことの一つは、コードがどうしてそのように書かれたのか分からないってこと。私だけじゃなくて、他の賢い人たちも同じコードベースで働いていたんだ。それぞれ理由があってやってたことが多いから、私がより良いアイデアを持っているわけじゃないんだよね。 場合によっては理由があるけど、あまり良い理由じゃなかったりする。具体的には、時間がない状況で、ただ動くようにしただけで、エッジケースを無視したり、プロトタイプがそのまま本番行ったり、リファクタリングしたけど他の部分が追い付いてなかったり、機能が変わったのに古い仕様に影響されたり、コードがコピー＆ペーストされたり、いろんな人が手を加えてごちゃごちゃしたり、特定の人のスタイルが色濃く残ったりしてるんだ。Chesterton’s Fenceは今も有効だから、何か手を加える前にたくさんの高レベルなテストを書くべきと思うよ。 特にコードの理解が深まると、貢献も良くなるし、自信もつくだろうね。 自分の古いコードを読むのもそういう感じだよね。 会社で他の興味深いことをやるのを遠ざける結果になってることも多いよね。 エンジニアリングは面白い問題を解くことじゃなくて、仕事を進めることと管理を満足させることなんだよ。 厳しい真実だけど、雇用のほとんどの場合に当てはまる気がする。面白い問題や良いエンジニアリングに集中できることは滅多にないよね。 退屈さは心の持ちようで、タスクそのものじゃない。面白い部分を見出せない人が多いのが問題だよ。 退屈は刺激不足だよね。何度もやってると、どんな先端的なタスクでも退屈に感じることがある。 退屈になってるなら、燃え尽き症候群やうつ病を経験してる可能性が高いよ。それは主観的な問題で、客観的なものではない。 長期間使用される製品の専門家になるのが地位を確保するいい方法。レガシー製品を直すのは管理を喜ばせるけど、製品が来年終了したら技術的専門知識は得られない。 目標によるけど、会社によってはそれがコストセンター扱いされることもあるよ。 レガシーソフトウェアを扱ってる開発者を最小限にしたいってか？ 面白いかどうかは定義によるよね。俺は既存のコードを改善する方が楽しくて報われる感じがする。誰かが何かを作る時の思考過程を理解するのはすごい興味深いし、俺の更新はリアルな人々の生活改善につながってる。それが俺にとって興味深いんだ。グリーンフィールドだと未来の批判を受ける大きなアーキテクチャミスをするストレスしかないし、そんなの興味ない。 そのミスを防ぐためのパターンやアーキテクチャを見つけたいんだ。もう見つけたかもしれないけどね。 新しいユーザーのニーズや技術を何年も先に予測できるって？その非技術的な要求を完全に排除する方法も見つけたの？すごい金の鉱脈を持ってるね。 それを防ぐんじゃなくて、可能な限り最小化したいんだ。金の鉱脈を持ってるけど証明できないのが問題なんだよね。この業界ではデザインの流行が水平に進んで、今の流行が前のものより良かったかなんて誰もわからないし。デザインやパターンをどうやって最大限に適応させて要求の変化に対応できるかが鍵だと思う。 OPじゃないけど、君の話が信じられない理由がわかるよ。完璧なソリューションを持ってると言うだけで、何も証拠を提示しないで済むと思ってるなら、それは煙に巻いてるだけだと思う。 完璧なソリューションはないって言ったし、信じないだろうなとも。でも、今ある解決策の中で僕が見つけたベストな方法なんだ。最善の方法を見つけたと思うし。 君が言ってることは理解できるよ。開発の種類やチームのやり方も影響するし。他の人は一つの真実を求めてるけど、君は自分に合った解決策を見つけただけってことだと思う。特定のプロジェクトには異なる解決策が必要だし。 一般的な解決策だって言ってるだけ。ソフトウェアプロジェクトは似ている部分に関して一般化できるけど、異なる部分には適用できない。俺はその大部分で一般化できる解決策を見つけたんだ。 誤解があったみたいで申し訳ない。興味深いけど、証明できないし、誰も信じてくれないって言うのは売り込みが厳しいよ。抽象的な表現ばかりだし、詳細をあまり出さないなら、ただ一般化しているだけに見えるかも。もし本当に見つけたなら頑張ってほしい。 あまり謝る必要はないよ。俺がトロールしてるわけじゃないから。それに抽象的な話をしてるのは、議論したくないからだ。ここでのデザインスタイルは証明できないし、無限に議論になるだけなんだ。俺のパターンを説明するものはあるけど、証明になるもんじゃない。AIに説明させるのがいいよ。この会話では、俺がchatGPTに一般的な質問をして、できるだけ操作しないようにしてるんだ。 お前は自分を面倒なことで固定しすぎなんじゃないか？俺はコードがちゃんと動いていてUTF8を扱える限りは、他に興味のあることもできる。ビジネスも詳しく知ってるし、戦略的にも重要だ。レガシーコードを理解してるのは価値があることだし、重要な決定に関われる。長い間放置された問題を直す責任を負わされることが多くなるよ。 趣味はあるよ。最も面白い仕事は１０パーセントぐらいしか楽しくないし、残りはほとんど面白くない。その逆もある。『面白い』仕事を優先すると、会社に利用されるだけだ。低い給料や少ない福利厚生と引き換えに少しの新しさを売り込まれる罠に陥らないで。 ADHDが無いことを証明する方法を教えてくれ。 俺はADHDがあるけど、既存のコードをデバッグしたり改善する方が、ゼロから始めるより楽だと思う。デバッグは探偵みたいで、ちょっとした報酬が得られる工程があるから。自分の過去のコードを触るとフラストレーションがたまるけどね。ゼロからだと、過去の経験がなくて新しい分野だと楽しいけど、結果が良くないことが多い。 シニアエンジニアの仕事は、チームを妨げる問題を解決すること。特に見せることが大事で、雇われた初期の段階で成果を出すことが求められる。 小さい問題だけど、リーダーが新しい機能を優先するようになったら、貴重な基盤が無くなる。組織に害を及ぼすことなく、この避けられない事実にどう対処するかを聞きたい。 大きなレガシープロジェクトでは、全くの夢だ。俺が働いてた古いC ERPは、何度も大規模なRubyの再構築が埋もれてしまった。機能が多すぎて、新参者は長く続かず、結局古いプロジェクトにフィックスが加わっただけだ。今は新しいサービスでモダナイゼーションをやってるけど、どうせコアの基盤が拡大するだけだろうね。 リーダーが古いものを止めて新しいプロジェクトに移行する時、貴重な時間が無くなるっていうのは変な結論だ。新しいプロジェクトに取り組むことを優先しているから、古いプロジェクトの方が優遇されることは無いから。 新しいリーダーが『全てが駄目だ』って言うこともあるけど、それは旧開発者に対する攻撃と受け取られることがある。時には本当にそうだけど、新しい仲間を引き入れるための理由にもなったりする。長期的な所有権とキャリアの駆け引きはうまくいかないよ。 俺の上司が言ってたことがあるんだよね＞”経験ってのは、何も持ってない時に得るものさ”って。レガシーコードに取り組むよりも、グリーンフィールドプロジェクトをやって、それがレガシー化する過程を見届けるほうが、過去の決断の良い面も悪い面も分かっていい経験になるんだよな。もっとコメントを表示（1）
事前にバッチリ設計したのに、ゴチャゴチャになっちゃって新しいチームが立ち上がるたびに手間が増える。技術的負債を解消する時間を管理がくれないから地獄だ。
これはいつも面白い！“誰がこんなゴミを書いたんだろうって思ったら、あっ、俺だ。”
- Random_Rockstar_Dev_254もっとコメントを表示（2）
上手い指摘だな。もっとコメントを表示（3）
