最近、Twitterで「10倍エンジニア」についてのスレッドが回っているのをご覧になった方もいらっしゃるのではないでしょうか。 まだの方は、ぜひ一度読んでみてください。
Shekhar Kirani @Accel@skirani
10x engineers
Founder if you ever come across this rare breed of engineers, grab them. もし、最初の数人のエンジニアの中に10xエンジニアがいれば、スタートアップが成功する確率は格段に上がります。
さて、ここで難しい質問ですが、
どうやって10xエンジニアを見分けるのですか？13:02 – 2019/07/11
まとめると、開発者という超狭量でステレオタイプな考え方に合わない限り、あなたは「10xエンジニア」ではないのだ、ということです。
多くの人は、誰か/ほとんどの人よりも何かで 10 倍優れていることはかなり難しいので、「10 倍のエンジニア」は存在しないと言うでしょう。 たとえその人が文字通り「10倍」を意味しないとしても、それはすべてにおいて著しく優れた人がいると言おうとしているのです。 ロックスター開発者」と同様、これらは偉大な開発者が何であるかのお粗末な説明と定義です。
すべての開発者が同じであると言うのは不誠実でしょう。 Twitter でさまざまな開発者を数分見ただけで、私よりはるかに多くのことを知っている多くの開発者をすでに見ることができます。
「10xエンジニア」というひどいステレオタイプを打ち負かすのはもう十分として、本当に優れた開発者（別名、本当の「10xエンジニア」）を作るものについての話をしましょう。
1.頭がいいが、自分の限界を知っている
非常に小さなコードベースでない限り、生産に入ったすべてのコード行を把握しているわけではありません。 確かに彼らは多くの問題を自分で解決することができますが、彼らは行き詰まったとき、そして助けを求めるときを知っています。
あなたのスキルレベルに関係なく、助けを求めることについて何も間違っていません！
2.
単独でプログラミングするときもあれば、チームでプログラミングするときもある。 これらの開発者は、あるタスクを持って隅に逃げ込み、他のみんなとサイロで作業するようなことはしない。 ペアプログラミング、コードレビュー、アイデアの交換、デバッグの支援などです。
優れた開発者が特定のタスクで一人で作業することに抵抗がないとは言いませんが、大規模な開発は強い協力なしでは事実上不可能なのです。 おめでとうございます、彼らは偉大な開発者かもしれません。 私たちは、ドキュメントや、Stack Overflow を見て助けを求めるかもしれませんが、時には、私たちのコードベースを知っている人からの助けが実際に必要なことがあります。 もしあなたが同僚を助けることができる何かを知っている開発者なら、彼らを助けてあげてください！
4. 親切で理解力がある
偉大な開発者であることは、賢いバカであること、自分の知性を誇示すること、自分がその人たちよりも優れているから会議を無視すること、ではありません。 偉大な開発者であることは、技術的なこと以外でも優れていることなのです。 もしあなたが同僚を怒鳴りつけたり、彼らのコードを批判することで「助けている」のなら、やめればいいだけです。
これは異論があるように聞こえるかもしれませんが、優れた開発者は常にあなたに答えを与えるわけではありません。 2や3と矛盾しているように聞こえるかもしれませんが、これはあなたを支配するためのものではありません。 優れた開発者とは、あなたが自分で解決できる程度の答えを与えてくれる人なのです。 これらの小さな挑戦は、あなたをより良い開発者にし、あなたがもっと学ぶ必要があるかもしれないものを理解することを可能にします。 6075>
これらの開発者が新しいツールや言語をチェックしていないとは言いませんが (その点では好きなことができます)、新しいツールがすべての問題を魔法のように解決するわけではないことを理解しています。
James Hickey 🇨🇦👨💻@jamesmh_dev私たちはより多くのツールや言語について学ぶことに夢中になっています!
アーキテクチャが悪い、間違った問題を解決している、説明してもクライアントが理解してくれない……そんなとき、ピカピカのツールは役に立ちません。
そしてこれらは、ビジネスの成功の基本なのです!18:54 – 2019年6月27日7.Twitterで「いいね！」を押してもらう。 彼らは、あなたがいつプログラムするか、どんなエディタテーマを使うかは重要ではないことを知っています
プログラマーのステレオタイプはさておき、なぜあなたがプログラムをする時間が実際に違いを生むのでしょうか？ 夜中にプログラミングしたい/会社から許可されているのならすればいいし、したくないのならしなければいい。 時間が関係するのは、長時間プログラミングをしていて眠れなかったときだけだ！」。 実際の時刻は、チームに影響を与えない限り、重要ではありません (たとえば、意図的に皆を避けるために真夜中のプログラミングで仕事をする)。
エディターのテーマについても同様で、なぜ暗いテーマが実際にあなたを良くするのでしょうか。 ヒントをあげましょう、それはありません。 ダークテーマはその目的を持っていますが、それは確かにそれではない。 わざわざ複雑なものを作らない
これは明らかかもしれませんが、前の週に別の Twitter スレッドで、何かを複雑にプログラミングすることは良いことだというような話がありました。 私たちの仕事と同僚の仕事を難しくすることが、いつ良いことだったのでしょうか? これは、ソリューションをプログラミングする最初の試みで起こる可能性があり、通常、コードのリファクタリングや、前の週/月/年に書いたコードを「誇りに思わない」ことについて話しているのを耳にするときです。 チーム」の「私」を考えない
本当にコンパイラからすべてのビジネスロジックまで、ソースコードのすべての行を自分で書いていない限り、彼らはそれがチームの努力であることを知っています。 彼らはチームの誰かからスポットライトを浴びようとはせず、プロジェクトを成功に導いたすべての貢献を強調するのです。 チームプロジェクトは、（悪意がない限り）個人としてではなく、チームとして失敗するものです。 チーム全体が失敗から学び、再発を防ぐ手助けをしてくれる。 6075>
一日の終わりに、これらの偉大な開発者は、あなたが実際に一緒に働くことを楽しむ人々です。 職場に現れ (またはリモートで)、このような素晴らしいチームと一緒に仕事ができることを喜んでいるのです。