10x プログラマーは、最近のソフトウェア業界ではホットな話題なので、この点に関する私の見解を共有するのは良い考えだと思います。
10x プログラマーの正確な定義は正直わかりませんが、それは生産性の高いプログラマー（正確に10倍の生産性と一致しないかもしれませんが、10倍近くかそれ以上のかなりのレベル）を指すと推測されます。
私がスタートアップや企業で超大型のソフトウェアを提供したときのいくつかの成功例と、数人の一流の開発者との共同作業に基づいて、このトピックについていくつかの洞察を共有することができます。 その一方で、当時はどんな機能でも実装できるようなライブラリやフレームワークはほんの一握りしかありませんでした。 10 倍プログラマと通常のプログラマが同じ機能セットを実装するために費やしたコア プログラミングの労力の差です。
The 10x Engineer Now
詳細に入る前に、ひとつだけ明確にしておきます。
特にインターネット上では、消費者と組織の両方によるソフトウェアの使用が増加しているため、ソフトウェアは非常に複雑であり、ゼロから何かを構築するのは非常識な判断かもしれません。 正直なところ、完全に新しいプラットフォームやオペレーティング システムでない限り、現代のソフトウェアを開発するために必要なコア プログラミングは、古い取り組みと比較してそれほど激しくありません。
プログラミングの知識と努力は依然として非常に重要ですが、優れたソフトウェア (バグなしで安全、かつ販売可能) を作るために必要な努力量は、エンジニアリングにおけるものです。
つまり、今日の文脈では、10 倍のプログラマーは業界にあまり価値をもたらさないかもしれませんが、10 倍のエンジニアは開発プロセスにおいて非常に幅広い影響を与えます。 コーディングだけでなく、プロセスの文書化、データのフォーマット、ログデータの読み取り、レポートの送信、自動テスト、手動テスト、複雑なデバッグ、手動での問題調査など、さまざまな努力を伴います。
膨大な労力は、（クライアントの予算やその他の制約に適した）適切なツールとプラットフォームのセットを使用することにより、非常に効率的にすることができます。 Visual Studio や Eclipse などの最新の IDE は、開発者の生産性を高めるために非常に多くの機能を提供していますが、これらの機能の大部分はほとんどの開発者には知られていないものです。
IDE 以外にも、NotePad++ や MarkdownPad などのエディターも、関連する状況では非常に便利です。
ユーティリティとオンラインサービス
大きなログファイルの読み取りや検索、Fiddler などの http デバッガー、構築および展開ツールなどのユーティリティとオンラインサービスです。
独自のツール
10x エンジニアは、適切なソフトウェアが外部で利用できないような反復的な動作を実行するために、独自のツール セットを作成することもできます。
ソフトウェア開発者は、雇用するのに最も高価な人の一部であり、彼らのために正しいツールにお金を使うことは価値があります。
.net 開発者チームのリーダーとして、最新の .net コーディング プラクティスに従って ASP.NET Core & Visual Studio スターター テストを開発すると、チーム全体の生産性が 3 倍に向上しました。 彼らは車輪を再発明しない
過去 30 年間でソフトウェア業界は非常に成熟してきました。 開発者がコーディングによって解決しようとしているほとんどすべての問題は解決され、API (バイナリまたは Web サービス) として利用可能で、そのうちのいくつかは商用であり、他のものは無料です。
さらに、オープン ソース フレームワークは、ユーザーが必要に応じて基本的な API 動作やカスタマイズを理解するための大きな柔軟性を提供します。
プログラミングに飛び込む前に、10 倍のエンジニアは実際に、この問題が以前に完全に (または部分的に) 解決されていないか、解決されていても使用できないかを確認します。
3. 彼らは (継続的に) 美しく設計されたコードを書く
優れたソフトウェアを書くには、優れた設計パターンと原則に従うだけではなく、最新のインフラストラクチャを活用した優れたアーキテクチャを定義することが求められます。 しかし、美しいエンジニアリングには継続的な改善が必要です。
私の専門的なキャリアにおいて、さまざまなソフトウェア プロジェクトで驚くほど多くの低品質のコードを目にし、それが常に技術的負債を増やしてきました。 5 年前に開始した単純なプロジェクトは、エンジニアリングされていない醜いコードでいっぱいで、開発サイクルを処理するために 20 人以上の人を必要とします (彼らは時間の 80% を実際にバグ修正に費やしています)。
このひどい状況の背後にある主な理由の 1 つは、「恐れ」だと私は発見しました。
ソフトウェア開発は、ツール、フレームワーク、およびエンジニアリングの面で非常に変化の速い分野であり、正しい場所に到達するために継続的な変更が必要です。
変化は恐ろしいものですが、特にソフトウェア業界では（ツールと人々の正しいセットで）言うほど危険ではありません。 しかし、期待通りに行われないと、いつかそのプロジェクトが完全に放棄されるのにそれほど時間はかからないでしょう。
。