7,734 測定値

私が 100x 開発者になった経緯 - ジュニア時代

に picocreator9m2023/01/03

長すぎる; 読むには

10x / ロックスターの開発者は神話です。 100倍のシチュエーション開発者万歳！ 100 倍のシチュエーショナルデベロッパーになる可能性を高める方法を学びましょう。

featured image - 私が 100x 開発者になった経緯 - ジュニア時代

10x 開発者やロックスター開発者が他のすべての開発者よりもあらゆる点で優れているという考えは、神話です。

代わりに、非常に特定の状況では 100 倍の開発者、一部の状況では 10 倍の開発者、できるだけ多くの状況で 1 倍の開発者になるように努力する必要があります。自分が得意な分野と取り組む必要のある分野を認識することが重要です。

大規模なテクノロジー企業で働いていない限り、複数の役割を担っている可能性があります。日常的に、フロントエンド、バックエンド、および Java や TypeScript などの言語固有の開発を切り替えることができる必要があります。これは、この業界の性質が絶え間なく変化していることと、 400 以上の異なるプログラミング言語で「Hello World」を出力するなど、同じタスクを達成する方法が非常に多いためです。

すべてが得意になることは不可能ですが、何かが得意になることは可能です。

詳しく説明すると、私のキャリアに大きな影響を与えた、人生を変える瞬間だった 10 年以上前の話を共有したいと思います。

私が 100x 開発者になった経緯 - ジュニア時代

私は大規模な MNC で働いており、需要に追いつくのに苦労していたチームの一員でした。

彼らは、何千人もの従業員が毎日使用するカスタム Java Web アプリケーションを構築していましたが、SQL サーバーに出入りするレコードの数が増加したためです。物事は減速していました。彼らはすでに SQL サーバーを限界までアップグレードしており、新しいソリューションが必要でした。明らかな 1 つは、結果の一部をキャッシュするために memcache を使用することでした。

残念ながら、memcache は、過去のいくつかのセキュリティインシデントと HA の欠如のために禁止されていました。マネージャーは 1 年以上にわたって memcache の承認を得ようとしてきましたが、失敗しました。一方、開発者は、10% の改善ごとに、ユーザーの増加の 2 倍の改善が打ち消されたため、困難な戦いを繰り広げました。

ここに来て参加しました。

私は彼らの過去 1 年間の苦闘についてまったく知りませんでした。シニアデベロッパーがパフォーマンスに集中している間に、UI のマイナーな改善を支援するジュニアデベロッパーとして参加しました。

ただし、開発サーバーのパフォーマンスが遅いことに非常に悩まされていたためです。そして、Java ベースの新しいサーバークラスタリングおよびキャッシングライブラリである Hazelcast で遊んでいました。

memcache の代替として使用しました。そして、特別な制限や特別な承認要件のないアプリケーションで実行することができたので、以前のソリューションはすべて無効になりました。

そして、同じ週内にデモを備えた実用的なプロトタイプを用意しました.プラットフォームの 1 ページで、API 呼び出しが 10 秒以上から 1 秒未満になりました。それはゲームチェンジャーでした。

チーム全体が参加し、1 か月以内に「memcache ではないクラスタリングソリューション」を本番環境で使用できるようになりました。

私のチームマネージャーと彼の上司が全員を宴会に招待したとき、私のマネージャーは私に、頭の良い子供だった私を入社させたとき、私が一夜にして問題を解決できる 10 倍または 100 倍のプログラマーになるとは思ってもいなかったと言いました。

そして、その言葉は私を強く打った。

私は詐欺師だったので、幸運な詐欺師に他なりません。

ラッキーな詐欺師 – 0.1x 開発者だったのは誰?

技術的には、私は 1x 開発者でも 10x 開発者でもありませんでした。私はチームメイトほど知識がなく、仕事で学んでいました。

私の仲間は私よりもフロントエンドをうまくやることができ、チームは SQL を最適化する方法を知っていました (そして私に教えてくれました、ありがとう!)。私の最大の功績は、「npm install Miracle」に相当するものを実行でき、その構成方法に関するマニュアルを読むことができたことです。

後から考えると、運が良ければ回避できた多くの問題がありました。

政治 (最初に memcache をブロックした)
ユースケース (書き込み競合の安全性はありませんでした。つまり、2 つの編集が同じミリ秒で発生した場合、キャッシュはひどく更新されます。ありがたいことに、これはめったに起こりません)
安定性 (hazelcast の v1 は狂ったようにクラッシュします。ありがたいことに、API サーバーは HA モードでデプロイされるように設計されているため、これはインフラチームにとって最悪の場合迷惑でした)
セキュリティ (クラスター内の API サーバー上のすべてのデータに対してポートを開くことは、私の側では悪い考えであり、別のシニアがありがたいことにそれを保護する方法に関するドキュメントを読むまで、非常にジュニアミスでした)
言語スタック (サーバーが Python、.NET、C#、または Ruby である場合、ローカルクラスターキャッシュを含める方法すらわかりません)

ワントリックポニーが何頭かいてラッキーだったので、状況によっては 100 倍になりました。これが可能になったのは、チームの残りの部分が基礎的な作業を行ったからです。

また、マネージャーや上司が私が修正したい問題を選択することを許可してくれたのも幸運でした。幸運と影響の比率を最大化し、「奇跡」を繰り返すことができます。

経験を重ねるうちに、逆のことにも気付きました。フロントエンドの開発が遅いのです。これは、10x エンジニアとして急速に軌道に乗る前に、私が本来やるべきことだったものであり、何年にもわたって多くのことを反省しました。それは私が立ち往生していたであろう道だったかもしれないので。

また、後から考えると、ヘーゼルキャストやその他のさまざまなテクノロジーを「マスター」したことも印象的でした。同じ組織内であっても、チームの他のメンバーにクレジットされるべきであった独自の状況と保護手段がなければ、他のチームにとってどれほど失敗したか.

どちらかといえば、私は後輩としてラッキーでした。

これが、上級開発者が 10 倍のジュニア開発者になる傾向がある理由です。

エンジニアリングの一般化を超えて検討すると、誰もが 100 倍から 0.1 倍の範囲のスキルを持っていることが明らかになります。

何年にもわたって、多くのチームやプロジェクトを渡り歩くうちに、最終的に「上級」開発者になりました。この間、一般的にシニアの方がスキルが高く、自分の得意なことと苦手なことを知っていることに気づきました。マネージャーに事前に通知し、それに応じてタスクに優先順位を付けることができます。これは、彼らがすべてを行う方法を知っているという意味ではありませんが、何をすべきでないかを知っているということです。

一方、ジュニアは、自分の得意なことと苦手なことを知る経験が不足しているため、これに苦労しています。「やってみる」以外に、これを見つける簡単な方法はありません。

これを理解すると、確実にうまくできるとわかっていることの数を最大化することがすべてであることが明らかになります。また、タスクを割り当てられたときに運の要素を最大化し、苦手なことで立ち往生しないようにすることも重要です.

ある意味で、ジュニアの進歩は、運とスキルセットの調整に大きく依存します。高齢者は、自分の進歩をどのように操縦するかについて、より多くの（ただし完全ではない）コントロールを持っていました.

この場合: 運はバイナリではありません。自分に合うシチュエーションを増やすことができます。

100倍と10倍で状況運を最大化する方法

誰にとっても、特にジュニアや始めたばかりの人にとって、最善の方法は、テクノロジーの新しいことに挑戦し、探求し続けることです。そうすることで、自分の得意なことと苦手なことがわかります。

自分の得意なことをよりよく理解している人にとって、次のステップは、ベストを尽くすことができる状況の数を増やすことです.これには、彼らがすでに知っている技術に隣接する技術の実践と研究が含まれます。何かが得意になったら、必ずそれを所有して、マネージャーや上司に、これがあなたに与えられるべきものであることを知らせてください。これにより、これらの 10 倍または 100 倍の状況に頻繁に遭遇する可能性が高くなります。

たとえそれが非常に小さくて狭いものであっても、あなたが得意なことを少なくとも1つ見つけてください.そこから積み上げます。 (いくつかの注目すべき例には、正規表現と webpack の構成が含まれます。)

高齢者の場合、まだ行っていない場合は、開発の技術的側面を超えたところに目を向け始めてください。これは、あなたが管理職に就かなければならないという意味ではありません。しかし、独自の技術知識があれば、ユーザーまたはビジネスのユースケースを理解する上で、より積極的な役割を果たすことができます。これにより、マネージャーと一緒に最適化して、あなたとあなたのチームの成功率を 10 倍または 100 倍にすることができます。

就職活動をしている方は、10倍でもいいとわかっているなら、調べて就職活動を深めましょう。あなたが得意とする分野で困難に直面している、十分な資金のあるスタートアップや多国籍企業を探してみてください。これを実現するのは難しく、ある程度のネットワーキングが必要になる場合もありますが、適切な場所と時間に身を置くことができれば、あなたと関係する会社の両方に最大の影響を与えることができます。

これらはすべて、運の要因を改善するために、時間をかけてゆっくりと行うことができます.そして、その 10 倍のエクスペリエンスをより一貫して提供します。

幸運を生み出す方法に関するswyxの記事を読むために特別な叫び声を上げてください： swyx.io/create-luck

今日の CTO およびチームリーダーとして、これは依然として有効です - 10 倍は神話です - 誰もが 100 倍と 0.1 倍の両方です

Uilicious.comなどの UI テストツールの CTO はフロントエンドテクノロジに適していると考える人もいるかもしれません。しかし、これは真実とはかけ離れています。 Vue.js や React などの最新のフロントエンドフレームワークを使用してフロントエンドコンポーネントを作成する場合、平均的な新入社員や後輩は通常、CTO である私よりも速いです。

これにより、チームリーダー/マネージャーとしての私の見方が変わりました。 10倍のエンジニアの神話がいかに有毒で悪いかを教えてくれました。これは、ラベルを単純化しすぎて、非常に特殊な状況を一般化したものです。これは修正が必要な有毒な誤解です。

ほぼすべてのスタートアップの 10 倍のエンジニアの神話は、より深く調べると、適切な場所と時間に独自の知識を持つ個人がいることが判明します。そして、彼らが 0.1 倍だったタスクを回避することができました。

私の場合は、フロントエンド開発よりもインフラストラクチャに重点を置いていました。代わりに、フロントエンド開発が 1000 倍優れている他のチームメンバーがいます。

これは管理者として重要な認識です。なぜなら、あるタスクで 100 倍になるすべての個人に対して、タイムシンクに行き詰まると 0.1 倍になるタスクがあるからです。それは、各個人の 100 倍と 0.1 倍を理解し、認識することです。

これは非常に簡単に聞こえますが、実際には非常に困難です。

チームリーダーや開発者は、以前に試してみないとわからないことがたくさんあります。または、それらの特定の状況に関連するスキルセットを磨き、習得するための時間と機会が与えられます。また、多くのこと、特に新しいテクノロジーは、誰も得意ではなく、すべてリスクとチャンスをつかむことがすべてです。

全員のニーズに合わせてタスクを編成するのは、チームリーダーの仕事です。それが不可能な場合は、誰かが今の状況で 100 倍になることができなくても、他のチームの他の場所にいる可能性があることを理解することも重要です。

そして、個々の開発者が得意なことと苦手なことを把握し、それに応じてチームに伝える必要があります。

10倍のエンジニアの神話で死ぬまで、特定の状況で100倍のエンジニアを長生きさせる

PS: 新年の抱負をまだ決めていない場合。おそらく、運の表面積を増やすことができます。

〜🖖長生きと繁栄

Eugene Cheah: uilicious.comの CTO