क्या आपके प्रोग्रामर पसीने से तर या आलसी हैं?

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

2004 में, मैंने एक केबल टेलीविजन कंपनी के बिलिंग और सेवा विभाग की एक बड़ी टीम में एक जूनियर डेवलपर के रूप में काम किया। सभी बड़ी प्रणालियों की तरह, इसमें कई अपेक्षाकृत स्वतंत्र घटक शामिल थे, जिन पर व्यक्तिगत कर्मचारियों या छोटे समूहों ने काम किया। डिजिटल और एनालॉग टीवी सिस्टम लगभग एक दूसरे से पूरी तरह से अलग थे, प्रत्येक टीम की अपनी टीम थी।

एनालॉग टीवी टीम ने अपने सिस्टम को Microsoft BizTalk के पुराने संस्करण में तैनात किया था। हमारे चार लोगों और Microsoft की एक टीम ने सिस्टम विकसित किया और इसे लॉन्च किया। ऐसा लगता था कि वे सभी कड़ी मेहनत करते थे। वे अक्सर रात और सप्ताहांत में कार्यस्थल पर बने रहते थे। वे काम पर समस्याओं के साथ मदद करने के लिए अपने मामलों को फेंक देते थे, अक्सर एक ही मेज के चारों ओर भीड़ होती थी, जो गलत हो सकता है, और इसे कैसे ठीक किया जाए, के आगे सुझाव रखे। वे लगातार कुछ कर रहे थे, और उन पर एक नज़र से यह स्पष्ट था कि हमारे पास एक करीबी टीम थी जो कड़ी मेहनत कर रही है।

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

नतीजतन, यह बहुत ज्यादा नहीं था जैसे हम कड़ी मेहनत कर रहे थे। मैं 5:30 बजे घर गया, कभी सप्ताहांत पर काम नहीं किया, हम एक-दूसरे की तालिकाओं के आसपास घंटों तक भीड़ नहीं लगाते थे, यह अनुमान लगाते हुए कि गिरती प्रणालियों के साथ क्या गलत हुआ। लोगों को यह लग रहा होगा कि एनालॉग टीवी टीम के काम की तुलना में हमारा काम बहुत सरल है। सच में, हमारे लिए आवश्यकताएं बहुत समान थीं, हमारे पास बस बेहतर लिखित और कार्यान्वित किया गया सॉफ़्टवेयर और एक बेहतर समर्थन बुनियादी ढांचा, विशेष रूप से इकाई परीक्षण।

अधिकारियों ने घोषणा की कि वे प्रदर्शन के आधार पर मजदूरी बढ़ाना चाहते हैं। जब बॉस के साथ बात करने की मेरी बारी थी, तो उन्होंने समझाया कि अगर यह लोग बहुत मेहनत करते हैं, तो यह उचित होगा, और हमारी टीम को कंपनी के बारे में इतनी चिंता नहीं लगती है, खासकर उन नायकों की तुलना में जो अपनी शाम को बलिदान करते हैं और सप्ताहांत।

केबल कंपनी के साथ कहानी एक विशेष मामला है, क्योंकि वहां आप अपनी आँखों से अच्छे और बुरे सॉफ्टवेयर और टीम के व्यवहार के परिणाम देख सकते हैं। अधिकांश कंपनियों को ऐसी तुलना नहीं मिल सकती है। यदि कोई व्यक्ति कड़ी मेहनत करता है, सप्ताहांत में देर से काम करता है और उसके पास समय नहीं है, तो यह कहना मुश्किल है कि क्या वह वास्तव में बहुत कठिन काम करता है या सिर्फ बहुत सारी गलतियाँ करता है। यदि आप एक ही समस्या को हल करने के लिए दो या अधिक प्रतिस्पर्धी टीमों को नियुक्त नहीं कर सकते (और कौन करेगा?), तो आप यह सुनिश्चित करने में सक्षम नहीं होंगे। और इसके विपरीत, उस आदमी के बारे में क्या है जो कोने में बैठता है, 9 से 5 तक काम करता है, और लगता है कि इंटरनेट पर बहुत समय बैठ रहा है? क्या उसे स्थिर, विश्वसनीय कोड लिखने का बहुत अनुभव है, या यह सिर्फ इतना है कि उसका काम बाकी की तुलना में आसान है? यदि आप पक्ष से देखते हैं, तो पहला बहुत कठिन काम करता है, लेकिन दूसरा नहीं करता है। मेहनत अच्छी है, आलस्य बुरा है, है ना?

मैं कहूंगा कि कड़ी मेहनत अक्सर त्रुटियों को इंगित करती है। अगर आपको दबाया जाता है और लगातार परेशान किया जाता है, तो अच्छे सॉफ्टवेयर विकसित करना मुश्किल है। ओवरटाइम का काम अक्सर इतना अच्छा नहीं होता है। कभी-कभी, एक जटिल समस्या को हल करने के लिए, इसके बारे में सोचना बंद करने, टहलने के लिए जाने या यहां तक ​​कि एक अच्छी रात की नींद पाने के लिए अपने अवचेतन मन का पता लगाने के लिए सबसे अच्छा है। मेरी पसंदीदा पुस्तकों में से एक ए गणितज्ञ की माफी जी.एच. हार्डी (जीएच हार्डी), 20 वीं शताब्दी के प्रमुख ब्रिटिश गणितज्ञों में से एक। इसमें, वह अपनी दिनचर्या का वर्णन करता है: सुबह में चार घंटे का काम, दोपहर में क्रिकेट देखना। उनका कहना है कि दिन में चार घंटे से अधिक समय तक भारी मानसिक काम करना व्यर्थ और अनुत्पादक है।

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