काम पर पीड़ित होना आवश्यक नहीं है

मैंने दूसरे दिन पैसिफिक ++ 2018 सम्मेलन में केट ग्रेगरी प्रदर्शन देखा।


केट एक अच्छे प्रोग्रामर और एक बेहतरीन वक्ता हैं। रिपोर्ट सामान्य तौर पर C ++ प्रोग्रामिंग और प्रोग्रामिंग के बारे में बहुत सी दिलचस्प बातें उठाती है (एक नज़र)। लेकिन सबसे अधिक मुझे एक (वास्तव में गुजरने में) लगा कि उसने व्यक्त किया। केट बहुत संक्षेप में और इस मामले में प्रोग्रामर की प्रेरणा की पहचान करने में सक्षम थे। वह इस तरह लग रहा था: "प्रोग्रामर, काम करते समय, अपनी खुशी को अधिकतम करने की कोशिश करता है।" यह सुनने में अजीब लगता है, लेकिन यह वास्तव में है।

हम कह सकते हैं कि हम परियोजना, ग्राहक, कंपनी, मानवता और विश्व शांति का समर्थन करते हैं (और यह सच भी हो सकता है)। लेकिन चलो ईमानदार हो। हम लोग हैं, और सभी लोगों की तरह, पहली जगह में, हम अपनी खुशी को अधिकतम करने का प्रयास करते हैं - हमारे जीवन में विश्व स्तर पर, हमारे करियर में रणनीतिक रूप से, वर्तमान परियोजना में, और यहाँ और अब, इस फ़ंक्शन को लिखते समय, कोड की यह पंक्ति। हां, हम ऐसा कर रहे हैं और यह पता लगाना अच्छा होगा कि क्या हमें खुश करता है और क्या हमें कम बनाता है। इससे हम अपने सहयोगियों, अधीनस्थों और खुद को बेहतर ढंग से समझ पाएंगे।

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

परीक्षण

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

बगफिगिंग और नई कार्यक्षमता का विकास

"मैं आपको पूरे ओडेसा के लिए नहीं बताऊंगा", लेकिन मेरे जीवन में जितने भी प्रोग्रामर मुझसे मिले, उनमें से ज्यादातर को लेगैक कोड फिक्स करने की तुलना में नई कार्यक्षमता लिखने का शौक था। और क्यों? लेकिन क्योंकि बग को छूना किसी और के दुर्भाग्य को छू रहा है। किसी के लिए कुछ गलत हो गया था और यह इतना महत्वपूर्ण था कि वह डेवलपर के लिए अपने दुख को लाने के लिए बहुत आलसी नहीं था। उसकी स्थिति में जाना है, पुन: पेश करने का प्रयास करना है। और फिर आखिरकार, यह या तो पुन: पेश करने में सफल होगा - और एक बग के कारण आत्म-सम्मान को झटका होगा, या यह काम नहीं करेगा और आपको (मेरे भगवान, नहीं!) एक जीवित व्यक्ति से संपर्क करना चाहिए जिसने समस्या की खोज की है और अधिक जानकारी प्राप्त करने का प्रयास करें। यह सब सुखद नहीं कहा जा सकता।

इसी समय, एक नया कार्यात्मक लिखना खुशी का एक संभावित स्पर्श है। हमने अभी तक कुछ भी नहीं तोड़ा है, यह हमारी गलती नहीं है। हम नई समस्याओं को हल करने के लिए नए कोड लिख रहे हैं। शायद यह सफल होगा। शायद हम अच्छी तरह से योग्य प्रशंसा (बोनस, पदोन्नति) प्राप्त करेंगे। यह पहले से ही मास्लो के अनुसार मानव आवश्यकताओं के पिरामिड के ऊपरी स्तरों के करीब है।

निष्कर्ष क्या है? प्रोग्रामर का काम संतुलित होना चाहिए, इसमें एक बग फिक्सिंग नहीं होनी चाहिए। प्रत्येक प्रोग्रामर को समय-समय पर नई सुविधाओं के विकास को सौंपने की आवश्यकता होती है। हां, बगफिक्सिंग से कोई बचा नहीं है, लेकिन हम कम से कम इस मामले में खुशी और नाखुशी के "शून्य शून्य" संतुलन को प्राप्त करने की कोशिश कर सकते हैं।

रिफैक्टरिंग

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

आधुनिक पुस्तकालयों और उपकरणों का उपयोग करना

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

वैसे, ऐसे उपयोगी कार्यों पर खर्च किया गया समय वास्तव में आपको न केवल यहां और अब थोड़ा खुश कर सकता है, बल्कि बहुत ही "डरावने" कारणों को भी खत्म कर सकता है, क्योंकि नए उपकरणों का उपयोग करने के लिए स्विच करना असंभव था। मेरे जीवन से वास्तविक स्थिति:

- हमें यकीन नहीं है कि एक नई लाइब्रेरी के लिए संक्रमण हमें नई समस्याएं नहीं लाएगा ...
- और यहां मैंने इस लाइब्रेरी का उपयोग करते हुए कोड के लिए 200 टेस्ट लिखे, चलो पास करने की कोशिश करते हैं और हम उन्हें लॉन्च करेंगे।
- हम्म, चलो।

2 सप्ताह के बाद - उत्पादन में एक नया पुस्तकालय।

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