हर कोई जानता है कि "दस गुना" प्रोग्रामर हैं जो एक साधारण प्रोग्रामर की तुलना में 10 गुना अधिक उत्पादक हैं। हम प्रदर्शन को माप नहीं सकते, इसलिए हमें पता नहीं है कि क्या यह सच है। लेकिन वास्तव में काफी कम लोग हैं जो असामान्य रूप से उत्पादक हैं, "दस गुना प्रोग्रामर" के अस्तित्व को साबित करने के लिए पर्याप्त हैं।
वे इसे कैसे हासिल करते हैं?
यह अक्सर माना जाता है कि दस गुना उत्पादकता दस गुना क्षमता या दस गुना ज्ञान से उपजी है। मुझे ऐसा नहीं लगता। मैं यह नहीं कहना चाहता कि क्षमता या ज्ञान बेकार है। लेकिन इन वर्षों में, मैंने देखा कि यहाँ सबसे महत्वपूर्ण बात दस गुना
समझदारी है । लगातार काम से बचने के लिए चाल है।
और इसके द्वारा मेरा मतलब "बौद्धिक रूप से असंतोषजनक" नहीं है। घटिया काम की परिभाषा यह है कि इसका परिणाम सीधे शौचालय में जाता है।
मैं खुद बहुत घटिया काम करता हूं, खासकर जब मैं अनुभवहीन और अनुभवहीन था। (अनुभव के महान लाभों में से एक यह है कि एक व्यक्ति कम भोला बन जाता है - और यह अधिक से अधिक मेमोरी मेमोरी से वाष्पीकरण के लिए क्षतिपूर्ति करता है)।
मैं आपको केवल कड़ी मेहनत का एक अच्छा उदाहरण दूंगा, सीधे शौचालय में विकास और जा रहा हूं: एक निश्चित बिंदु के साथ दस साल पहले का मेरा रोमांच।
क्या आप जानते हैं कि "निश्चित बिंदु अंकगणित" क्या है? मैं आपको बताऊंगा। यह तब होता है जब आप पूर्णांकों के साथ काम करते हैं, लेकिन भिन्न होने का दिखावा करते हैं, तो यह मानकर कि पूर्णांक x वास्तव में x / 2 ^ N है एन के कुछ मान के लिए।
दो नंबर जोड़ने के लिए, आप बस x + y की गणना करते हैं। गुणन के लिए आपको x * y >> N की आवश्यकता है, क्योंकि सिर्फ x * y - यह x * y / 2 ^ 2N होगा, है ना? यह सावधानी बरतने के लिए भी आवश्यक है कि यह बकवास अतिप्रवाह न हो, किसी तरह एक अभिव्यक्ति में विभिन्न एन के साथ व्यवहार करें, और इसी तरह।
फिर, 90 के दशक की शुरुआत में, मैंने प्रोग्राम को एक प्रोसेसर में पोर्ट किया जो हमारी कंपनी में विकसित किया गया था। फ़्लोटिंग पॉइंट के लिए हार्डवेयर इकाई की योजना उसके लिए नहीं थी - "हम एक निश्चित बिंदु के साथ सब कुछ करेंगे।"
यहाँ मेरे तत्कालीन मामलों का एक हिस्सा है:
- InteliFixed <N> नामक एक C ++ टेम्प्लेट जल्दी में तैयार होने के लिए तैयार था (यह अभी भी मौजूद है, मैं मूर्ख नहीं हूं)। मैंने इसे बनाने में बहुत काम किया, उम्म ... धीमे हाथ से थप्पड़ मारा (क्या यह तेज हाथ के विपरीत है?)। उदाहरण के लिए, ऑपरेटर + कम्यूटेटिव बनाने के लिए यह आवश्यक था जब इसे विभिन्न प्रकार के दो निश्चित-बिंदु संख्याएं प्राप्त हों (परिणाम प्रकार क्या होगा?); 64-बिट मध्यवर्ती गुणा इनलाइन बेहतर करता है कि भयानक इनलाइन कोडांतरक कोड बना; आदि, आदि।
- मेरे मालिक ने मुझे कोड के दो संस्करणों को रखने के लिए कहा - एक फ्लोटिंग पॉइंट के साथ, एक एल्गोरिदम के महान डेवलपर्स के लिए, और दूसरा एक निश्चित के साथ, हमारे लिए, काम करने वाले कोड के साथ काम करने वाले मजदूर। इसलिए, मैंने इन संस्करणों को मैन्युअल रूप से सिंक्रनाइज़ किया है।
- सटीकता के नुकसान की त्रुटियों को खोजने के लिए, बॉस ने एक अस्थायी बिंदु के साथ कोड का हिस्सा चलाने का एक तरीका और भाग - नहीं आने का भी आदेश दिया। इसलिए, मैंने एक C ++ हेयुरिस्टिक पार्सर लिखा है जो दो संस्करणों को स्वचालित रूप से एक में मिला देता है। उन्होंने "फ़्लोटिंग" संस्करण से कुछ फ़ंक्शन लिए, और "फिक्स्ड" एक से अन्य, उन्हें हेडर जैसी विशेष फ़ाइल से चयन किया।
बेशक, यह सब विलीन बकवास शुरू नहीं हुआ था और यहां तक कि बस संकलन नहीं किया था, है ना? इसलिए, मैंने मैक्रोज़ बनाया, जिसके लिए आपने वेक्टर <फ्लोट> पास नहीं किया, लेकिन फ़ंक्शन के लिए संदर्भ (वेक्टर <फ्लोट>), और कोड का एक भयानक टुकड़ा लिखा जो वेक्टर <InteliFixit> (कोड के अंदर का समर्थन किया) कार्यों ने इसे वेक्टर <फ्लोट>) में बदल दिया। - और इन सभी मेटा-प्रोग्रामिंग के अलावा, ज़ाहिर है, प्रोग्रामिंग ही था। उदाहरण के लिए, एक निश्चित बिंदु के साथ शोर डेटा श्रृंखला के लिए बहुपदों का चयन करने के लिए समीकरणों की 5x5 प्रणाली को हल करना। मैं इसे सामान्यीकरण के साथ खौफनाक चाल का उपयोग करके काम करने में कामयाब रहा, और कोडांतरक कोड ने 96 बिट्स सटीक का उपयोग किया। मेरा कोड सामान्यीकरण के बिना एकल-सटीक फ़्लोटिंग-पॉइंट कोड से भी बेहतर काम करता था! वाह!
महीनों और महीनों के लिए, मैंने पूरी ताकत से काम किया, जटिल और डीबग कोड का उत्पादन किया - सब कुछ, हमेशा की तरह।
और यहाँ है कि मैं वास्तव में क्या करने की जरूरत है:
- इस बदबूदार चिप में एक अस्थायी बिंदु के साथ बदबूदार ब्लॉक को रटना करने के लिए अधिकारियों को समझाने के लिए। इसके लिए सिलिकॉन के इतने वर्ग मिलीमीटर की आवश्यकता नहीं होगी - मुझे यह गणना करने पर जोर देना था कि अगले प्रोसेसर संस्करण में कितने (हार्डवेयर FPUs जोड़े गए थे)।
- यदि यह काम नहीं करता है, तो मुझे सर्किट सिमुलेटर पर जाना होगा, एक फ्लोटिंग पॉइंट का अनुकरण करने की लागत को मापना होगा और इसे कोड के उन स्थानों पर लागू करना होगा जहां यह स्वीकार्य है (धीरे-धीरे हमने किया)।
- बॉस को यह बताना असंभव है कि दो संस्करणों को सिंक्रनाइज़ करना असंभव है जैसा वह चाहता है - वे आगे और आगे विचलन करेंगे, और अंत में, स्वयं शैतान की मदद से भी, वे परिणामी कोड को विलय या चलाने में सक्षम नहीं होंगे (बेशक, यह इसी तरह समाप्त हो गया है)।
यह सब महाकाव्य कई महीनों के घटिया काम में क्यों बदल गया, जिसके लिए कुछ उपयोगी हो सकता है? क्योंकि मुझे पता नहीं था कि क्या हो रहा है; क्योंकि मुझे एहसास नहीं था कि आप बॉस के साथ बहस कर सकते हैं; और क्योंकि काम रचनात्मक और दिलचस्प था। जो बहुत जल्दी शौचालय में चला गया।
इन दस गुना लोगों को "प्रबंधित" करने के लिए सबसे मुश्किल काम - वे जिन्हें हर कोई जानता है कि वे बहुत उत्पादक हैं - उन्हें कार्य लेने के लिए राजी करना है। (बाकी सब कुछ पहले से बहुत आसान है - वे खुद जानते हैं कि कितना? यदि उन्होंने कुछ करने का उपक्रम किया, तो यह किया जाएगा)।
आप कुछ पूरी तरह से अलग होने की उम्मीद कर रहे थे, स्वीकार करते हैं? मेरा मतलब है, यदि आप इतने उत्पादक हैं, तो चिंता करने की क्या बात है? आप तेजी से काम करते हैं; सबसे बुरी चीज जो आपको इंतजार कर रही है वह यह है कि परिणाम के रूप में कुछ भी नहीं निकलेगा - और फिर आप जल्दी से कुछ और करेंगे, है ना? मेरा मतलब है, यह धीमा है और बहुत उत्पादक लोग नहीं हैं जिन्हें पिकी होने की आवश्यकता है - वे धीमे हैं और उनके पास कुछ नया करने की क्षमता कम है - सही है?
लेकिन यह सिर्फ एक ऑप्टिकल भ्रम है: अधिक उत्पादक लोग इतनी तेजी से काम नहीं करते हैं - दस गुना तेजी से नहीं। वे जिस कारण से 10 गुना तेज
प्रतीत होते हैं, वह इसलिए है क्योंकि उन्होंने जो कुछ किया है उसका लगभग कुछ भी नहीं है - दूसरों के काम के ढेर के विपरीत।
और उत्पादकता में फेंके गए मामलों पर विचार नहीं किया जाता है। आप उस व्यक्ति को "एक्स बनाने वाले व्यक्ति" के रूप में मानते हैं, जहां एक्स की उपयोगिता सभी को पता है - और आप उन सभी वाई के बारे में भूल जाते हैं जो विशेष रूप से उपयोगी नहीं थे, प्रयासों और प्रतिभा के बावजूद जो उन्हें बनाने में चले गए। भले ही इसके लिए किसी को दोषी ठहराया जाए - प्रबंधक, या समय की कमी, या जो कुछ भी हो।
यदि आप प्रसिद्ध उदाहरण लेते हैं - आप केन थॉम्पसन को सी और यूनिक्स से जानते हैं - लेकिन योजना 9 से नहीं, वास्तव में, और गो से नहीं। अब तक विपरीत - गो ने आपका ध्यान केवल इसलिए आकर्षित किया क्योंकि यह उन लोगों के दिमाग की उपज है जिन्होंने यूनिक्स बनाया था। आप लिनुस टॉर्वाल्ड्स को जानते हैं, हालांकि लिनक्स यूनिक्स का एक क्लोन है, और गीत बिटकिपर का क्लोन है
क्योंकि वे सफल उत्पादों के क्लोन हैं, और वे सफल रहे क्योंकि वे समय पर दिखाई दिए।
पहली चीज जिसे आप देखते हैं, वह मौलिकता नहीं है और यह लिखना कितना मुश्किल था, या किसी विशिष्ट मानदंड के लिए यह बात कितनी अच्छी है: आप इसे कैसे उपयोग किया जा सकता है।
दस गुना प्रोग्रामर, एक नियम के रूप में, एक वास्तविक युद्ध की व्यवस्था करता है, केवल उस चीज में संलग्न नहीं होने के लिए जिसका कभी उपयोग नहीं किया जाएगा।
इन स्मार्ट लोगों में से एक ने मुझसे एक बार
जांचे गए
चिट्ठों के बारे में
पूछा जो मैंने अभी-अभी समाप्त किया है: "क्या कोई इसका उपयोग करता है?" उसी ब्रांडेड विडंबना के साथ। मैंने कहा मुझे नहीं पता; किसी ने हैकर न्यूज़ पर टिप्पणी में लिखा कि वे कोशिश कर सकते हैं।
मुझे पता है कि यह एक अद्भुत बात है; इसकी सहायता से आप मल्टीथ्रेडेड कार्यक्रमों में अपनी सभी त्रुटियों को पा सकते हैं। लेकिन यह pthreads के लिए एक प्रतिस्थापन नहीं है, आपको नए इंटरफेस - अच्छे, सरल इंटरफेस का उपयोग करके कोड लिखना होगा, लेकिन उन लोगों को नहीं जो आप पहले से ही उपयोग करते हैं। इसलिए यह संभावना है कि मेरी लाइब्रेरी में थोड़ी दिलचस्पी होगी; हालांकि
हेलग्रिंड और
थ्रेड सैनिटाइज़र के पास झूठी सकारात्मकता का एक गुच्छा है, वे कम से कम उन इंटरफेस के साथ काम करते हैं जो लोग व्यापक रूप से उपयोग करते हैं।
मैं भी ऐसा क्यों करूंगा? क्योंकि पहले संस्करण को लिखने में मुझे केवल एक दिन का समय लगा (तब मैंने फैसला नहीं किया था कि समानांतर नेस्टेड छोरों और उस सब को शुरू करने के लिए), और मैंने सोचा कि अगर ब्लॉग पर मेरे कार्यक्रम के बारे में लिखा है तो कुछ मौका होगा (मैं अभी क्या कर रहा हूं) )। अगर मैंने कई पोस्ट लिखीं, जिसमें मैंने समझाया कि पुराने ढंग के समानांतर साझा मेमोरी कोड में
त्रुटियों को ट्रैक करना व्यावहारिक रूप से कैसे संभव
है , सी में रूस्ट, या गो, या एर्लैंग की तुलना में भी आसान है, तो शायद लोग ध्यान देंगे।
लेकिन दस गुना भीड़ के बीच विफलता के कई मौके हैं जो मैं व्यक्तिगत रूप से जानता हूं - आपको भी प्रयास नहीं करना चाहिए। भले ही हम घर पर चेकथ्रेड्स की तरह कुछ का उपयोग करें और बहुत सफलतापूर्वक। दरअसल, मैंने उस आदमी से एक विडंबनापूर्ण सवाल सुना, जिसने इस बहुत ही आंतरिक संस्करण में बहुत काम डाला - क्योंकि यह बहुत संभावना है कि हमारे कार्यक्रम का उपयोग किया जाएगा।
आप देखते हैं? प्रदर्शन के विफल होने की संभावना नहीं है, जहां प्रदर्शन है
कैसे काम करने लायक कुछ चुनना है? विचार करने के लिए कई चीजें हैं:
- क्या पहले से उपलब्ध विकल्प है? वह कितना बुरा है ? यदि सहिष्णु है, तो अपने आप को कुछ भी न करें - एक अच्छी चीज को सुधारना मुश्किल है, और यहां तक कि हर किसी को यह समझाने में भी मुश्किल है कि यह सुधार एक नए संस्करण में संक्रमण के लायक है
- यह बात कितनी महत्वपूर्ण है? इसके बिना, कुछ भी काम नहीं करेगा या यह केवल एक छोटी सी बात है जो किसी को नोटिस नहीं होगी?
- उपयोगकर्ताओं को कुछ लाभ प्राप्त करने में कितना काम लगेगा? क्या यह पहले से ही मौजूदा कोड या डेटा के साथ काम करता है? क्या लोगों को कुछ नया सीखना होगा या क्या वे काम करने में सक्षम होंगे जैसा वे करते थे?
- कम से कम इसे फैलाने के लिए कितने लोगों को इस चीज के बारे में सीखना चाहिए ? क्या उपयोगकर्ता इसके बारे में कुछ भी जाने बिना कोड चलाएंगे, क्योंकि यह पुराने कोड के साथ आता है, या उन्हें कुछ स्थापित करना होगा? (किसी फ़ंक्शन को स्वचालित रूप से प्राप्त करना और फिर उसके व्यावहारिक अध्ययन में संलग्न होना अक्सर कुछ नया स्थापित करने और वहीं भूल जाने से बेहतर है। सोचें कि कितने लोगों ने अंततः एक्सेल में एक नया फ़ंक्शन सीखा, और कितने बैकअप प्रोग्राम का उपयोग करें; पृष्ठभूमि में)।
- कितना कोड अच्छा है? एमपीईजी प्रारूप में एक छोटे कर्नेल कम्प्रेसिंग ध्वनियों की नब्ज के नुकसान का अनुकूलन करना 1.2 बार के त्वरण को प्राप्त करने के लिए कोड की एक लाख लाइनों को देखने की तुलना में अधिक उपयोगी लगता है (हालांकि बाद वाला विकल्प अपने आप उपयोगी हो सकता है; लेकिन आमतौर पर इसे दस गुना अधिक प्रोग्रामर की आवश्यकता होती है; , और न सिर्फ एक "दस गुना" प्रोग्रामर)।
- क्या एक नया अवसर खुद की रक्षा कर सकता है? यदि उपयोगकर्ता कुछ गलत करते हैं (या "गलत"), तो क्या यह चुपचाप बेकार हो जाएगा (जैसे स्थिर कोड विश्लेषण जब विश्लेषक अब प्रोग्राम को नहीं समझता है) या जब तक त्रुटि ठीक नहीं हो जाती तब तक यह काम करना बंद कर देगा (जैसे आउट-ऑफ-बाउंड्स सरणी के लिए जाँच करना )?
- ...
आप आसानी से इस सूची को जारी रख सकते हैं; उनका मुख्य विचार यह है कि इस बात की क्या संभावना है कि मैं इस बात को समाप्त कर दूंगा और फिर इसका उपयोग किया जाएगा? एक ही विचार हर फ़ंक्शन, सबफ़ंक्शन और कोड की रेखा पर पुनरावर्ती लागू होता है: क्या संपूर्ण उनके लिए उपयोगी होगा? और क्या मैं किसी और चीज पर समय नहीं बिताता हूं जो अधिक लाभ लाएगा?
बेशक, यह अभी भी अधिक जटिल है; कुछ उपयोगी चीजें विभिन्न कारणों से दूसरों के ऊपर मूल्यवान हैं। यह वह जगह है जहाँ रिचर्ड स्टेलमैन प्रकट होता है और मांग करता है कि हम लिनक्स को "जीएनयू / लिनक्स" कहें क्योंकि जीएनयू ने अधिकांश उपयोगकर्ता कार्यक्रमों को लिखा है। और हालांकि, मैं "ग्नू-लिनक्स" प्रणाली को कॉल नहीं करने जा रहा हूं, लेकिन उनके दावे, दुर्भाग्य से, उनकी अपनी सच्चाई है, इस अर्थ में कि हां, दुर्भाग्य से, कुछ कठिन और महत्वपूर्ण काम अन्य कठिन और महत्वपूर्ण काम के रूप में ध्यान देने योग्य नहीं हैं।
लेकिन न्याय एक और विषय है। आखिरकार, एक दस गुना प्रदर्शन आपको दस गुना मुआवजा देने की संभावना नहीं है।
इसलिए, "धोखा" देने के कई कारण नहीं हैं और आप की तुलना में अधिक उत्पादक लगते हैं। लोगों को उत्पादक होने का मुख्य कारण यह है कि वे गधे में सिलाई कर रहे थे, सता रहे थे, न कि कुछ ठोस लाभ।
यहां मैं यह कहना चाहता हूं: अधिक करने के लिए, आपको
तेजी से सफल होने के लिए बहुत अधिक आवश्यकता नहीं है (हालांकि यह चोट नहीं करता है), लेकिन
असफल होने के लिए अक्सर कम होता है । और सभी विफलताएं ज्ञान या अनुभव की कमी के कारण नहीं होती हैं; उनमें से ज्यादातर तब होते हैं जब एक कार्यक्रम को एक मंच पर छोड़ दिया जाता है जब इसका उपयोग करना अभी भी असंभव है - या क्योंकि कोई भी शुरुआत से ही इसका उपयोग करने वाला नहीं था।
इसलिए, मैं, एक व्यक्ति के रूप में जिसने शौचालय के लिए बहुत सारे कोड लिखे, मुझे लगता है कि उत्पादकता प्राप्त करने के लिए
काम की
कमी के रूप में
काम करना इतना आवश्यक नहीं है - ऐसा करने के लिए नहीं जो अंततः कचरे में फेंक दिया जाएगा।
जोसेफ Kreinin द्वारा पोस्ट किया गया
मूल:
www.yosefk.com/blog/10x-more-selective.html