"एक अच्छा प्रोग्रामर औसत दर्जे की तुलना में 10X गुना अधिक उत्पादक हो सकता है" [बंद]


54

मैंने एक महान प्रोग्रामर के साथ एक साक्षात्कार पढ़ा था (यह अंग्रेजी में नहीं है) और इसमें उन्होंने कहा कि "एक महान प्रोग्रामर एक औसत दर्जे का 10 गुना अच्छा हो सकता है" इसका कारण यह है कि अच्छे प्रोग्रामर को बहुत अच्छी तरह से भुगतान किया जाता है और क्यों प्रोग्रामिंग कंपनियां अपने कर्मचारियों के लिए कई सुविधाएं देती हैं। यह विचार था कि उपरोक्त कारणों से अच्छे प्रोग्रामर की बहुत बड़ी मांग है, और इसीलिए कंपनियां उन्हें लाने के लिए बहुत अधिक भुगतान करती हैं।

क्या आप इस कथन से सहमत हैं? क्या आप ऐसे किसी वस्तुपरक तथ्य को जानते हैं जो इसका समर्थन कर सकता है?

संपादित करें: सवाल का अनुभव से कोई लेना-देना नहीं है; यदि आप 1 वर्ष के अनुभव के साथ एक महान प्रोग्रामर के बारे में बात करते हैं, तो उसे 1 वर्ष के अनुभव के साथ औसत दर्जे के प्रोग्रामर की तुलना में 10 गुना अधिक उत्पादक होना चाहिए। मैं इस बात से सहमत हूं कि कुछ वर्षों के अनुभव के बाद, चीजें फैलने लगती हैं, लेकिन यह सवाल का उद्देश्य नहीं है।


क्या आप साक्षात्कार के लिए लिंक पोस्ट कर सकते हैं?
मिर्को

1
@ area404 जैसा कि मैंने कहा, यह अंग्रेजी में नहीं है: economie.hotnews.ro/…
m3th0dman


9
10X उत्पादकता अंतर एक ज्ञात तथ्य है जो प्रोग्रामर के लिए मापा जाता है (मैककोनेल 1 , 2 )
gnat

जवाबों:


41

एक बहुत गहन अवलोकन और उत्पादकता अंतर के बारे में अनुसंधान का विश्लेषण स्टीव मैककोनेल द्वारा लिखित दो लेखों में प्रदान किया गया है :

पहला लेख ( उत्पादकता विविधता ... ) बताता है:

... मूल अध्ययन जिसमें व्यक्तिगत प्रोग्रामिंग उत्पादकता में भारी भिन्नता पाई गई, 1960 के दशक के अंत में सैकमैन, एरिकसन और ग्रांट (1968) द्वारा आयोजित की गई थी। उन्होंने 7 साल के अनुभव के औसत के साथ पेशेवर प्रोग्रामर का अध्ययन किया और पाया कि सबसे अच्छे और सबसे खराब प्रोग्रामर के बीच प्रारंभिक कोडिंग समय का अनुपात लगभग 20 से 1 था; डिबगिंग समय का अनुपात 25 से 1 से अधिक; कार्यक्रम का आकार 5 से 1; और कार्यक्रम निष्पादन गति 10 से 1. के बारे में। उन्हें प्रोग्रामर के अनुभव और कोड की गुणवत्ता या उत्पादकता के बीच कोई संबंध नहीं मिला।

सैकमैन, एरिकसन और ग्रांट के निष्कर्षों की विस्तृत परीक्षा उनकी कार्यप्रणाली में कुछ खामियों को दिखाती है ... हालांकि, खामियों के लिए लेखांकन के बाद भी, उनका डेटा अभी भी सर्वश्रेष्ठ प्रोग्रामर और सबसे खराब के बीच 10 गुना से अधिक अंतर दिखाता है।

मूल अध्ययन के बाद के वर्षों में, सामान्य खोज "प्रोग्रामर्स के बीच आदेश-में-अंतर भिन्नताएं हैं" की पुष्टि पेशेवर प्रोग्रामर (कर्टिस 1981, मिल्स 1983, डेमार्को और लिस्टर 1985, क्रेसिस एट अल 1986) के कई अन्य अध्ययनों द्वारा की गई है। , कार्ड 1987, बोहेम और पपीशियो 1988, वालेट और मैकग्रेरी 1989, बोहेम एट अल 2000) ...

इस लेख में एक दिलचस्प पक्ष नोट भी है:

भिन्नता की यह डिग्री सॉफ्टवेयर के लिए अद्वितीय नहीं है। नॉर्म ऑगस्टीन के एक अध्ययन में पाया गया कि विभिन्न प्रकार के व्यवसायों में - लेखन, फुटबॉल, आविष्कार, पुलिस का काम और अन्य व्यवसाय - शीर्ष 20 प्रतिशत लोगों ने लगभग 50 प्रतिशत उत्पादन किया, चाहे उत्पादन टचडाउन हो, पेटेंट हो , हल किए गए मामले या सॉफ़्टवेयर (अगस्तीन 1979)।


दूसरा लेख ( ... वलिड इज द अंडरलाइंग रिसर्च? ) मुख्य रूप से लौरेंत कुमारवती द्वारा पहले एक की समीक्षा को संबोधित करने के लिए लिखा गया है :

दूसरे लेख में, "10x" मेक सपोर्टिंग इन द रिसर्च के सेक्शन ए डेपर डाइव में मैककॉनेल ने पहले लेख में इस्तेमाल किए गए संदर्भों का अधिक विवरण फिर से जांचा और निष्कर्ष निकाला:

... जैसा कि मैंने इस आलेख को लिखने में एक बार फिर इन उद्धरणों की समीक्षा की, मैंने फिर से निष्कर्ष निकाला कि वे सामान्य खोज का समर्थन करते हैं कि प्रोग्रामर के बीच 10x उत्पादकता अंतर हैं। अध्ययन ने सामूहिक रूप से प्रोग्रामिंग गतिविधियों के एक स्पेक्ट्रम में सैकड़ों पेशेवर प्रोग्रामर शामिल किए हैं।

... अनुसंधान का शरीर जो 10x दावे का समर्थन करता है, वह उतना ही ठोस है जितना कि सॉफ्टवेयर इंजीनियरिंग में किया गया कोई शोध। अध्ययन जो 10x दावे का समर्थन करते हैं, वे चित्र 1 में वर्णित पद्धतिगत सीमा के अधीन नहीं हैं, क्योंकि वे व्यक्तिगत परिवर्तनशीलता का अध्ययन कर रहे हैं (यानी, केवल आंकड़े के बाईं ओर)। बोसाविट एक भी अध्ययन का हवाला नहीं देता - त्रुटिपूर्ण या अन्यथा - जो 10x दावे को गिनता है, और मैंने ऐसा कोई अध्ययन भी नहीं देखा है। तथ्य यह है कि किसी भी अध्ययन ने निष्कर्ष नहीं निकाला है कि 10x दावे के विपरीत 10x दावे में और भी अधिक आत्मविश्वास प्रदान करता है। जब मैं उन अध्ययनों की संख्या पर विचार करता हूं, जो कुल मिलाकर, मुझे लगता है कि शोध न केवल विचारोत्तेजक है, बल्कि निर्णायक है - जो कि सॉफ्टवेयर इंजीनियरिंग अनुसंधान में दुर्लभ है।


संपूर्णता के लिए, उत्पादकता विविधता में उपयोग किए गए संदर्भों की सूची ... नीचे भी उद्धृत की गई है:

संदर्भ

ऑगस्टाइन, एनआर 1979। "ऑगस्टीन के नियम और प्रमुख प्रणाली विकास कार्यक्रम।" रक्षा प्रणाली प्रबंधन की समीक्षा: 50-76।

बोहम, बैरी डब्लू।, और फिलिप एन। पपीशियो। 1988. "सॉफ्टवेयर लागतों को समझना और नियंत्रित करना।" आईईईई सॉफ्टवेयर इंजीनियरिंग एसई -14 पर लेनदेन, नहीं। 10 (अक्टूबर): 1462-77।

बोएहम, बैरी, एट अल, 2000. कोकोमो II, बोस्टन, मास के साथ सॉफ्टवेयर लागत अनुमान: एडिसन वेस्ले, 2000।

बोहम, बैरी डब्ल्यू।, टीई ग्रे और टी। सीवाल्ड्ट। 1984. "प्रोटोटाइप वर्सेस स्पेसिफिकेशन: ए मल्टीप्रोजेक्ट एक्सपेरिमेंट।" आईईईई सॉफ्टवेयर इंजीनियरिंग एसई -10 पर लेनदेन, सं। 3 (मई): 290-303। जोन्स 1986 बी में भी।

कार्ड, डेविड एन। 1987. "एक सॉफ्टवेयर प्रौद्योगिकी मूल्यांकन कार्यक्रम।" सूचना और सॉफ्टवेयर प्रौद्योगिकी 29, नहीं। 6 (जुलाई / अगस्त): 291-300।

कर्टिस, बिल। 1981. "सब्स्टीट्यूटिंग प्रोग्रामर वेरिएबिलिटी।" IEEE 69 की कार्यवाही, नहीं। 7: 846।

कर्टिस, बिल, एट अल। 1986. "सॉफ्टवेयर मनोविज्ञान: एक अंतःविषय कार्यक्रम की आवश्यकता।" IEEE 74 की कार्यवाही, सं। 8: 1092-1106।

डेमार्को, टॉम और टिमोथी लिस्टर। 1985. "प्रोग्रामर का प्रदर्शन और कार्यस्थल का प्रभाव।" सॉफ्टवेयर इंजीनियरिंग पर 8 वें अंतर्राष्ट्रीय सम्मेलन की कार्यवाही। वाशिंगटन, डीसी: IEEE कंप्यूटर सोसायटी प्रेस, 268-72।

डेमार्को, टॉम एंड टिमोथी लिस्टर, 1999. पीपुलवेयर: प्रोडक्टिव प्रोजेक्ट्स एंड टीम्स, 2 डी एड। न्यूयॉर्क: डोर्सेट हाउस, 1999।

मिल्स, हरलान डी। 1983. सॉफ्टवेयर उत्पादकता। बोस्टन, मास .: लिटिल, ब्राउन।

सैकमैन, एच।, डब्ल्यूजे एरिकसन, और ईई ग्रांट। 1968। "ऑनलाइन और ऑफलाइन प्रोग्रामिंग प्रदर्शन की तुलनात्मक प्रयोगात्मक अध्ययन।" एसीएम 11 के संचार, सं। 1 (जनवरी): 3-11।

वैलेट, जे।, और फे मैकगरी। 1989. "सॉफ्टवेयर इंजीनियरिंग प्रयोगशाला में सॉफ्टवेयर मापन अनुभवों का सारांश।" सिस्टम और सॉफ्टवेयर 9 की पत्रिका, नहीं। 2 (फरवरी): 137-48।

वेनबर्ग, गेराल्ड एम।, और एडवर्ड एल। शुलमैन। 1974. "कंप्यूटर प्रोग्रामिंग में लक्ष्य और प्रदर्शन।" मानव कारक 16, नहीं। 1 (फरवरी): 70-77।


13
"10x दावे का समर्थन करने वाले शोध का शरीर उतना ही ठोस है जितना कि सॉफ्टवेयर इंजीनियरिंग में किया गया कोई शोध" - हाँ, यह वास्तव में उतना ही बुरा है। :)

मैककॉनेल के दूसरे लेख
डीएनए

92

वास्तव में भयानक प्रोग्रामर में उप-शून्य उत्पादकता हो सकती है (वे बग को ठीक करने में जितना समय लगाते हैं, उससे अधिक समय उनके लिए काम करने में लगता है)।

और वास्तव में महान प्रोग्रामर उन चीजों को कर सकता है जो खराब और औसत प्रोग्रामर कभी भी हासिल नहीं करेंगे , भले ही आपने उन्हें कितना समय दिया हो।

तो इन कारणों के लिए, "उत्पादक के रूप में 10x" या "उत्पादक के रूप में 100x" के बारे में बात करना मुश्किल है।

हालांकि, याद रखने वाली बात यह है कि प्रोग्रामर के अधिकांश नियोक्ताओं को उन कठिन कार्यों को करने की कोई आवश्यकता नहीं है जो औसत प्रोग्रामर प्रबंधित नहीं कर सकते। अधिकांश कोड जो लिखा जा रहा है वह है वेबसाइट्स, बिजनेस एप्स की लाइन, इंट्रानेट एप्स इत्यादि, यह वास्तव में उतना मुश्किल नहीं है। उस वातावरण में उत्पादक प्रोग्रामर वह है जो उपयोगकर्ताओं की जरूरतों को समझने और लागू करने में सबसे अच्छा है, न कि वह जो सबसे चतुर कोड लिख सकता है।

वास्तव में, प्रोग्रामर के अधिकांश नियोक्ता एक महान व्यक्ति के बजाय एक अच्छे प्रोग्रामर के साथ बेहतर होंगे, क्योंकि महान व्यक्ति बस ऊब जाएगा और छोड़ देगा। प्रोग्रामर और जॉब्स के बीच एक अच्छा मैच है।


33
जैसे भयानक प्रोग्रामर अपने आसपास के लोगों की उत्पादकता को कम कर सकते हैं, वैसे ही महान प्रोग्रामर अपने आसपास के लोगों की उत्पादकता में सुधार कर सकते हैं। वे कोड का विस्तार करते हैं जो आसान है और उनके साथ पांच मिनट की बातचीत अन्य प्रोग्रामर को बेहतर ट्रैक पर ला सकती है।
को रोबोट को

8
अपने वास्तविक भयानक प्रोग्रामर की तुलना में, शून्य उत्पादकता वाला एक प्रोग्रामर शानदार होगा।
ग्लेनट्रॉन

आप एक अच्छे कवि को एक बुरे कवि से अधिक उत्पादक कैसे मापेंगे? यदि आप शीर्ष गुणवत्ता आउटपुट चाहते हैं, तो कुछ लोग इसका उत्पादन करने में सक्षम हो सकते हैं, और अन्य लोग इसका उत्पादन करने में असमर्थ हो सकते हैं। अब आपकी कंपनी कविता का निर्माण कर रही है, या ग्राहकों को अनुस्मारक ईमेल भेज रही है? : पी
मीका

30

सॉफ्टवेयर इंजीनियरिंग राज्यों के तथ्य और विसंगतियां (Fact 2, amazon प्रीव्यू में उपलब्ध):

"व्यक्तिगत अंतर" शोध के अनुसार, सबसे अच्छे प्रोग्रामर सबसे खराब प्रोग्रामर से 28 गुना बेहतर हैं। यह देखते हुए कि उनका वेतन कभी कम्यूनिकेट नहीं है, वे सॉफ्टवेयर क्षेत्र में सबसे बड़े सौदेबाज हैं।

(शोध के लिए सूत्रों की सूची देखें)

बेशक, यदि आप किसी गैर-प्रोग्रामर (या बहुत खराब प्रोग्रामर) की उत्पादकता की तुलना अच्छे (अनुभव और ज्ञान की दृष्टि से) करते हैं, तो अंतर असीम रूप से बड़ा हो सकता है ( n/0 == infinityकिसी भी सकारात्मक के लिए n), लेकिन यह न तो उचित है न ही समझदार तुलना।

आपका वेतन कई कारकों पर निर्भर हो सकता है (यादृच्छिक क्रम में):

  • प्रौद्योगिकियों का इस्तेमाल किया
  • जिस देश / राज्य में आप काम करते हैं
  • कंपनी का धन
  • कंपनी का व्यवसाय प्रकार
  • कंपनी में डेवलपर्स की संख्या
  • आप कंपनी में कब तक काम करते हैं
  • कार्यालय की राजनीती

अपने व्यक्तिगत के साथ ...

  • उत्पादकता
  • ज्ञान और अनुभव
  • कंपनी के व्यवसाय में भागीदारी (स्टार्टअप्स के लिए)
  • मोलभाव करने के गुण
  • यौन आकर्षण और कौशल, योग्य (अच्छी तरह से, बुद्धिमान सेक्सी है)

20

मेरा उत्तर है "हाँ, लेकिन सावधान रहें कि आप उस मीट्रिक का उपयोग कैसे करते हैं"।

एक प्रोग्रामर जो है, हम कहेंगे, आशावादी रूप से कार्य करना, वह है जो कार्यक्षमता के लिए बनाता है और कम त्रुटियों का कारण बनता है जिसे उसके निचले प्रदर्शन वाले ब्रेटेन की तुलना में फिक्सिंग की आवश्यकता होती है। मुझे यह विश्वास करना बिलकुल भी मुश्किल नहीं है कि ये लोग 10X पर दूसरों की प्रोडक्टिविटी का प्रदर्शन कर सकते हैं, खासकर जब आप यह मानते हैं कि एक घंटे में किया गया एक अच्छा या बुरा विकल्प आसानी से 10 घंटे का प्रभाव डाल सकता है, और प्रोग्रामर ऐसे कई विकल्प बनाते हैं ज्यादातर दिनों।

परंतु...

आप इसे मापने में सावधान रहें। मैं वास्तव में उत्पादकता पर अधिकांश मापों पर भरोसा नहीं करता, क्योंकि मैंने अंतहीन मामलों को देखा है, जहां हर ज्ञात मीट्रिक के बारे में मैं टीम उत्पादकता के लिए महत्वपूर्ण कुछ पर विचार करने में विफल रहता हूं। इसलिए मैं आम तौर पर "उत्पादकता" के लिए ऐसे कठिन नंबरों से नफरत करता हूं। यहाँ कुछ उदाहरण हैं:

  • कोड की लाइनें (LOC) - आम तौर पर नफरत मेट्रिक, चूँकि एक विचारहीन प्रोग्रामर कई भयानक, क्रियात्मक, अकुशल, कोड की डीबग करने के लिए कठिन पैदा कर सकता है, जबकि एक अच्छा प्रोग्रामर कुछ, सुरुचिपूर्ण, ठीक करने में आसान बनाता है, शायद ही कभी कोड की टूटी हुई लाइनें। अधिक समय में, लेकिन कुल मिलाकर एक बेहतर विकल्प है।
  • कीड़े उत्पन्न और / या ठीक करने के लिए समय - हर कोई कुछ कीड़े उत्पन्न करेगा, और अक्सर सबसे महंगे कीड़े बुरे निर्णयों की एक श्रृंखला द्वारा उत्पन्न होते हैं जिसके लिए मुद्दे का जनरेटर डोमिनोज़ प्रभाव में अंतिम है। इसके अलावा, आपके महान डिबगर हमेशा आपके महान डिजाइनर नहीं होते हैं - आपको दोनों की आवश्यकता होती है।
  • लगभग किसी भी मीट्रिक द्वारा, ऐसे महान डेवलपर हैं जो एक टीम में होने के लिए इस तरह के दर्द हैं, कि 1 "सुपर उत्पादक" डेवलपर 10 मूल रूप से अच्छे डेवलपर्स को चलाएगा और मैं शायद ही कभी किसी को देखता हूं जो सब कुछ अच्छा कर सकता है , इसलिए हमें आवश्यकता होगी परियोजना पर 1 से अधिक व्यक्ति।
  • उन अद्भुत लोगों के लिए आसानी से हिसाब करने का कोई तरीका नहीं है जो समस्याओं को गंभीर होने से पहले देखते हैं और उन्हें बंद कर देते हैं, खासकर जब समस्या एक प्रक्रिया में अंतराल है - दोषपूर्ण सीएम, अक्षम निर्माण, परीक्षण में एक अंतर, एक सुरक्षा दोष - ये अक्सर समय की एक बड़ी बर्बादी की तरह देखते हैं जब तक आप महसूस करते हैं कि वे आपको आपदा से बचाते हैं - इसे मापने का कोई तरीका नहीं है।
  • इसके अलावा, ऐसे लोग हैं जिन्हें मैं एक निश्चित आकार की एक टीम पर आवश्यक मानता हूं जिसे मैं "सामंजस्य बनाने वाले" कहता हूं - शायद ही कभी उत्पादकता के पूर्ण शीर्ष पर, वे आमतौर पर ऊपरी 20% में होते हैं और वे रैंप अप की मदद करने का अमूल्य काम करते हैं नए लोग, डॉट्स को जोड़ते हैं और सुनिश्चित करते हैं कि सही प्रश्न पूछे जाते हैं और सही लोगों को लूप में रखा जाता है, वे लिखते हैं (नकाब उतारना!) दस्तावेज़ का मुख्य टुकड़ा जिसे हर कोई संदर्भित करता है क्योंकि यह केवल सही दस्तावेज नहीं है, लेकिन यह सिर्फ सही तरीके से एक साथ रखा गया है। यदि आप चाहते हैं कि 10 लोग चरम दक्षता पर काम करें, तो आपको इन लोगों में से एक की ज़रूरत है और यदि आप एक कमरे में 10 सुपर डेवलपर्स डालते हैं, तो आपको यह नहीं मिलेगा।

कई मापन प्रणालियों ने इन कारकों को ध्यान में रखने की कोशिश की है, लेकिन मुझे अभी तक यह देखना है कि इन सभी मुद्दों को ध्यान में रखा गया है, इसलिए मैं कभी भी उन कारकों से प्रभावित नहीं होता जैसे "एक अच्छा डेवलपर 10X एक से अधिक उत्पादक है औसत दर्जे का एक "क्योंकि मुझे आश्चर्य होता है कि क्या मीट्रिक वास्तव में उन सभी कार्यों के लिए जिम्मेदार है जो एक सफल चल रहे उत्पाद या सफल, संपन्न टीम में जाने की आवश्यकता है।

तो मेरा बड़ा चेतावनी है - आप इस मीट्रिक के साथ क्या करने जा रहे हैं? मैं कुछ इस तरह से उपयोग करूँगा कि यह जानने के लिए कि सही उपकरण और प्रतिभा काम करने के तरीके में बड़ा अंतर पैदा कर सकती है, लेकिन यदि आप एक टीम को अनुकूलित करने का प्रयास करते हैं, जहाँ प्रत्येक व्यक्ति 10X "विशिष्ट" आउटपुट का उत्पादन करता है, तो आप इसके लिए बाध्य हैं हताशा का मामला। बेहतर यह है कि अपनी टीम को 2-3X करने के लिए एक तरीका खोजा जाए कि वे पहले से बेहतर काम करके क्या कर रहे थे।


कहने की जरूरत नहीं, मेरे पास भी है। :)
बेतालक्ष्मी

यह एक बहुत अच्छा बिंदु है जो 10x दावे को बनाने और विश्वास करने वाले लोगों के लिए स्पष्ट होना चाहिए। आप प्रोग्रामर उत्पादकता कैसे मापते हैं? जब तक हम ऐसा नहीं कर सकते, ठीक, ठीक और मज़बूती से, दावा सिर्फ एक मिथक है।
जॉर्डन रीगर

यह एक मिथक नहीं है, अन्य उत्तरों में संदर्भ देखें। यहां पर किए गए बिंदु प्रतिनियुक्ति नहीं हैं, बल्कि उत्पादकता पर व्यापक गुंजाइश देते हैं।
फू

10

अपनी पुस्तक लेप्रचेचंस ऑफ सॉफ्टवेयर इंजीनियरिंग में , लॉरेंट बोसावित ने 10x उत्पादकता के दावे पर शोध किया। उन्होंने पाया कि इसके पीछे ध्वनि संख्याएँ नहीं हैं - यह दावा सट्टेबाजी से क्रमिक रूप से "स्थापित तथ्य" के लिए चला गया है, जो कि प्रशस्ति पत्र में क्रमिक रूप से अधिक ठोस दावों का एक टेलीफोन गेम है। ब्लॉग पोस्ट जिसमें 10x दावे पर अध्याय शामिल है, और प्रासंगिक उद्धरण और गलत उद्धरण शामिल हैं, सॉफ्टवेयर इंजीनियरिंग में तथ्य और लोककथाएं हैं

उसने जो पाया वह कुछ इस तरह है: किसी ने 1968 में एक अध्ययन किया, जिसमें लोगों ने एक विशेष डिबगिंग समस्या को हल करने वाले लोगों की तुलना की, और पाया कि उनमें से कुछ ने इसे दूसरों की तुलना में 10 गुना तेज किया। इससे हम यह निष्कर्ष निकाल सकते हैं कि कुछ लोग उस समस्या को हल करने में 10x बेहतर हैं , या हम यह निष्कर्ष निकाल सकते हैं कि कुछ लोग भाग्यशाली थे , या विभिन्न चीजों की एक विस्तृत विविधता। कुछ लोगों ने इसे उद्धृत करने के लिए चुना (ये सभी पैराफ्रीज हैं) "एक अध्ययन (सैकमैन एट अल, 1968) ने पाया कि कुछ प्रोग्रामर दूसरों की तुलना में 10x तेज काम करते हैं"। फिर यह "अध्ययनों से पता चला है कि अच्छे प्रोग्रामर औसत से 10x बेहतर हैं" फिर अंत में "यह सामान्य ज्ञान है कि प्रोग्रामर उत्पादकता व्यक्तियों के बीच 10x से भिन्न होती है"। फिर कोई इन सभी उद्धरणों को एकत्र करता है , एक मूल स्रोत को गलत तरीके से प्रस्तुत करता है कहने के लिए "कई शोधकर्ताओं का मानना ​​है ..."।

बेशक, यह एक टेलीफोन गेम नहीं होगा यदि केवल दावे की सत्यता बदल गई: गुणक 11 तक जाता है और इससे परे भी।


मैककॉनेल के दूसरे लेख
डीएनए

2

" उस वातावरण में उत्पादक प्रोग्रामर वह है जो उपयोगकर्ताओं की जरूरतों को समझने और लागू करने में सबसे अच्छा है, न कि वह जो सबसे चतुर कोड लिख सकता है। " ( कार्सन 63000 उत्तर से)

वह मुख्य बिंदु बेटीलक्ष्मी के साथ युग्मित हुआएक बड़ा बिंदु बनाता है। एक महान डेवलपर वास्तविकता के अपने एक स्लाइस में महान हो सकता है लेकिन जैसे ही दुनिया बदलती है, टूट जाती है। व्यवसाय की ज़रूरतों को पूरा करने में सक्षम होना किसी भी चीज़ की तुलना में कहीं अधिक महत्वपूर्ण है। दिन के अंत में, जब तक आपका व्यवसाय प्रौद्योगिकी नहीं है, तब तक व्यवसाय प्रौद्योगिकी के बारे में परवाह नहीं करता है; उन्हें समाधान चाहिए। तो डिजाइन पैटर्न के साथ महान होने का मतलब यह नहीं है कि एंड-यूजर्स को वेब साइट पर दिखाने के लिए डेटा डंप की जरूरत नहीं है। मैंने देखा है कि सामान्य डेवलपर्स खुद को एक व्यवसाय के लिए खानपान द्वारा सुरक्षित करते हैं जो उनका समर्थन करता है जबकि महान डेवलपर्स ऊब जाते हैं और कभी न खत्म होने वाली चुनौती की तलाश में चलते हैं। आपके संगठन और परियोजना के आधार पर, इन चुनौती देने वाले डेवलपर्स को खिलाने के लिए संभव है, लेकिन संभावना है, समय में एक बिंदु होगा जब आप सिर्फ डॉन करते हैं ' टी प्रसंस्करण शक्ति की राशि की जरूरत है। ये डेवलपर्स केवल प्रोसेसर की तरह बेकार बैठना पसंद नहीं करते हैं। वे बंद और रिबूट करेंगे कहीं और।

अंत में, मैं कहूंगा कि यह जानना ठीक है कि आपके "प्रमुख" कलाकार कौन हैं, लेकिन एक विकास "टीम" अभी भी एक टीम है। बेटलक्ष्मी को दोहराते हुए, " आप इस मीट्रिक के साथ क्या करने जा रहे हैं?"यदि आपको एक टीम की आवश्यकता है जो एक टीम की तरह व्यवहार करती है, तो मैं इन पर मैट्रिक्स पर ध्यान केंद्रित नहीं करूंगा। मुझे एहसास होगा कि सबसे छोटा खिलाड़ी अभी भी टीम का एक महत्वपूर्ण हिस्सा है। यहां तक ​​कि आपकी कुंजी की उत्पादकता का 60% कम है। खिलाड़ी, कि एक खिलाड़ी आपकी टीम को उसकी ज़रूरत के अनुसार कुछ दे सकता है। पता करें कि यह क्या है और इसे गुणा करने की कोशिश करें। अपने प्रमुख खिलाड़ी को यह न समझें कि उसे टीम का नेतृत्व करना चाहिए, अपने आउटपुट को भी गुणा करना चाहिए, उस महानता के साथ अन्य खिलाड़ियों को दूषित करके। इसके लिए थोड़ी रचनात्मकता की आवश्यकता है, न केवल संख्या। अंत में, आप सीख सकते हैं कि एक अच्छा प्रोग्रामर जो बनाता है वह प्रोग्रामर भी नहीं है, यह उसके साथियों, कार्यस्थल में उसके अवसर हो सकता है। या यह आप भी हो सकते हैं।


संपादन की सराहना करें। अब, क्यों डाउन वोट? क्या हम कह रहे हैं कि टीम डायनेमिक्स किसी डेवलपर के मूल्य और उत्पादकता की परीक्षा में बेकार है?
ड्रैगहोन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.