2つの真実、1つの嘘:「優れたプログラマー」に関する一般的な概念

伝説的なソフトウェア開発者であり、極端なプログラミング方法論とテスト駆動開発の作成者であり、多くのプログラミング本の著者であるケント・ベックは、かつてこう言いました 。「私は素晴らしいプログラマーではありません。 プログラミングのロックスターにはどんな習慣や能力がありますか?



「スーパープログラマ」についての3つの人気のある声明を作成して、どれが真実で、どれがかなり誇張であるかを理解してみましょう。





/写真コニー CC



箱の外側を考える



スーパーデベロッパーに関する最も人気のある意見の1つは、適切なタイミングで問題に対して非標準のソリューションを提供できるということです。 このようなソリューションは通常、多くの開発の成功事例の根底にあります。



それらの1つは、Quoraの居住者でプログラマーのPeter Blainによって共有されています。 彼 、困難な状況の1つで、「デッドエンド」プロジェクトの実用的なソリューションが、タスクに慣れるのに最低限の時間を費やした新しい開発者によって突然提案されたと言います。



彼のアプローチは、アーキテクチャというよりも実装に関するものでした。彼は問題を特定し、複数のオープンソース製品を組み合わせて一度に解決することを許可しました。 もちろん、この提案は自発的なものではありませんでしたが、それでも経験と並外れた能力が問題を解決する役割を果たしただけでなく、プロジェクトの新しい人の新鮮な見た目も役割を果たしました。 ピーターによると、開発者は従来のアプローチを超えて新しいレベルに進むことができ、文字通り「単なる優れたプログラマー」から「グランドマスター」に変わることができます。



ちなみに、700以上の質問がQuoraの枠を超えた思考のトピックに当てられています。ほとんどのトップスターターは、この能力を自分で開発する方法を理解したいと考えています。 答えは非常に異なります-定期的な休憩や運動のヒントから、パズルを解き、現在のアクティビティに関連する(またはまったく関連しない)地域の本を読むための提案まで。 プログラマーに適用されるこの現象の研究へのより体系的なアプローチは、ワシントン大学の科学者とマイクロソフトの代表者によって適用されました。



彼らは、優れたプログラマと単なる「良い」とを区別するものを見つけようとして、 調査を実施しました。 インタビューを受けた開発者は、説明によれば、悪名高い「箱の外」に対応する特性に気付いたことが判明しました。 彼らは彼女に「森と木を見る」能力、つまり技術的なニュアンス、産業動向、会社のビジョン、顧客のニーズを含む4つの異なる抽象化レベルで状況を調べる能力を呼びました。



もちろん、このアプローチは突然の巧妙な洞察を与えるものではなく、状況の適切な評価と質問への回答です。当社の価値は?」は、毎日のパズルを解くよりも良い結果をもたらすことができます。



このアプローチにより、少なくとも「森と木を見る」能力を開発できると述べることができます。13のMicrosoft部門の代表者との59のインタビューがこれの証拠となります。



集団精神



優れたプログラマーのもう1つの重要な特徴は、ワシントンの研究者が指摘したように、適切なタイミングで助けを求め、他の人を助ける能力です。 Bob Martin(Robert C. Martin)の著書 The Ideal Programmer。 「ソフトウェア開発の専門家になる方法」は、この点でさらに強力な声明を出します 。彼 、プログラミングは非常に難しく、誰もそれをうまくできないと書いています。 あなたが非常に経験豊富な開発者であっても、同僚の考えやアイデアはきっとあなたに利益をもたらすでしょう。



陳腐に聞こえるかもしれませんが、この点は成功のもう1つの重要な要素です。 最終的に、膨大な量のリソース(同じHabrを含む)があり、あらゆる方法で開発者がお互いに経験を共有することを奨励し、プロジェクトの同僚だけでなく喜んで支援します。



たとえば、Redditでの2か月半にわたるこのスレッドのトピックスターターは、R​​ubyでのプログラミング方法の学習に失敗しました。 プラットフォームユーザーは169のコメントに具体的なヒントを残し、一部のユーザーは質問の作成者に個人的に連絡して、実際に彼を支援しました。 スレッドの最初の投稿では、著者がどれほど感謝しているかを見ることができます-仲間のプログラマーは彼を助けただけでなく、この方向で開発を続けようと動機付けました。



一部のプログラマーは、質問を正しく行い、適切な答えを特別な芸術として提供する能力を検討しています。 別のRuby開発者であるSteven Hirlstonは、仕事中に学んだ主なことの1つは次のとおりであると指摘しています。優れたプログラマーは他のユーザーを悩ませることなく質問をする方法を知っており、優秀なプログラマーはar慢。



一般に、コミュニケーションはチームワークの重要な要素です。 ワシントン大学とマイクロソフトの研究に戻ると、科学者は、チームのコミュニケーションと行動に関連する「優秀なプログラマー」の17もの特徴を特定しました。



「妥協の決定において肯定的な側面を見つける」能力、礼儀正しさ、コードに関するコメントを受け取らない、または心臓の近くで作業する能力、およびコミュニケーションの過程における周囲のコンテキストへの注意を含む。



大規模なチームプロジェクトに関しては、目を閉じたボンネット内の閉鎖的で非社交的な開発者のイメージは真実とはほど遠いことがわかります。 そして、この考えは新しいものではありません-アメリカの科学者ジェラルドワインバーグは、1971年に彼の著書 「コンピュータプログラミングの心理学」でこれについて書いています。



その後、StackOverflowの作成者の1人であるJeff Atwoodがブログで次のように述べています。

「あの男にならないで。」 暗いオフィスでコードを書いて、コーラを購入する必要があるときにだけ人前に現れる人にならないでください。 「誰もその男を知らず、誰も見ていません。そして、彼はチーム内で誰もがオープンでお互いを助け合う用意ができていません。」


10倍のプログラミング



ソフトウェア開発の「スター」に関する最も古い(そして粘り強い) コンセプトの 1つは、スーパー開発者の生産性は通常の開発者よりも10〜15%ではなく、時には10倍になるということです。 このアイデアがどのように生まれ、この声明の背後にあるものを理解してみましょう。



Construx SoftwareのCEOおよびリード開発者であり、多くの有名な本の著者であるSteve McConnellは、10xの起源に関する記事で次のことについて語っています。 1960年代後半、研究者のSackman、Erickson、Grant(Sackman、Erikson、Grant)は、プロのプログラマーのパフォーマンスを分析する最初の試みを行いました(この研究には、平均的な実務経験が約7年の開発者が関与しました)。



その結果、最良の結果と最悪の結果のコード書き込み時間の差は20対1、デバッグ時間の差は25対1、「最悪」と「最良」のコード長の差は5対1、プログラム実行速度は10 1に。しかし、彼らはプログラマの経験と彼のコードの品質の間に関係を見つけませんでした。



印象的ですね。 一方、オートデスクの開発者Ashrafful Alamが正しく指摘しているように、その年に作成されたソフトウェアは、現在作成中の製品よりもはるかに簡単でした。



したがって、さまざまな年齢の開発者を比較することは意味がありません。 一方、当時のプログラマーには、現在利用可能なライブラリ、ツール、およびフレームワークの豊富な選択肢がありませんでした。 これは、これらの開発者がコードを書くことに直接注意を払ったことを意味します。 この理論はまた、60年代に設定された実験が明らかに誰も繰り返さないという事実に反対しています。



今年の10月に、Belitsoft PHP開発はプログラミングの「ロックスター」(つまり、潜在的な10倍のプログラマー)にインタビューしました。 インタビューしたスーパーデベロッパー全員が、彼らの能力をそれほど優れているとは考えていないことが判明しました。



たとえば、ProQuestの主任開発者であるVictor Volkmanは、2人のプログラマの生産性の10倍の違いは大きな誇張であると考えています。最終的に、プログラムのサイズは常に品質と相関しません。 そのため、プロジェクトの成功は、コードの記述速度ではなく、問題のシンプルでエレガントな解決策を見つける能力に依存することが多く、これは追跡と測定がはるかに困難です。



もちろん、経験豊富な開発者と初心者、優れた才能、優れたプログラマーの間には違いがあります。 もう1つのことは、星でさえ「宇宙加速」の技術を所有していない可能性が高いということです。



「スーパープログラマー」の特性の中で、これは最も信頼性が低いことが判明しています。 最終的に、不明瞭なコードを非常に速い速度で記述する開発者は、映画でのみ需要があります。






PS最初の企業IaaSブログでは、他に何を書いていますか:






All Articles