कोड पर गुस्सा: प्रोग्रामर और नकारात्मकता

मैं कोड का एक टुकड़ा देख रहा हूं। यह शायद अब तक का मेरे द्वारा देखा गया सबसे खराब कोड हो सकता है। डेटाबेस में केवल एक रिकॉर्ड को अद्यतन करने के लिए, यह संग्रह में सभी रिकॉर्ड पुनर्प्राप्त करता है और फिर डेटाबेस में प्रत्येक रिकॉर्ड के लिए एक अद्यतन अनुरोध भेजता है, यहां तक ​​कि जिन्हें अद्यतन करने की आवश्यकता नहीं है। एक मानचित्र फ़ंक्शन है जो केवल उसे दिए गए मान को लौटाता है। जाहिरा तौर पर समान मूल्य वाले चर के लिए सशर्त परीक्षण होते हैं, जिन्हें अलग-अलग शैलियों में नामित किया जाता है (firstName и first_name). प्रत्येक अद्यतन के लिए, कोड एक अलग कतार में एक संदेश भेजता है, जिसे एक अलग सर्वर रहित फ़ंक्शन द्वारा नियंत्रित किया जाता है, लेकिन जो एक ही डेटाबेस में एक अलग संग्रह के लिए सभी काम करता है। क्या मैंने बताया कि यह सर्वर रहित फ़ंक्शन क्लाउड-आधारित "सेवा-उन्मुख आर्किटेक्चर" से है जिसमें पर्यावरण में 100 से अधिक फ़ंक्शन शामिल हैं?

ऐसा करना कैसे संभव हुआ? मैं अपना चेहरा ढँक लेता हूँ और अपनी हँसी के कारण स्पष्ट रूप से सिसकने लगता हूँ। मेरे सहकर्मी पूछते हैं कि क्या हुआ, और मैं इसे रंगों से दोबारा बताता हूं BullkDataImporter.js 2018 की सबसे खराब हिट. हर कोई मुझ पर सहानुभूतिपूर्वक सिर हिलाता है और सहमत होता है: वे हमारे साथ ऐसा कैसे कर सकते हैं?

नकारात्मकता: प्रोग्रामर संस्कृति में एक भावनात्मक उपकरण

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

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

जब हम पहली बार प्रोग्राम करना सीखते हैं, तो "प्रोग्रामिंग अनुभव" की गहराई के बारे में हमारी समझ अन्य लोगों की भावनात्मक प्रतिक्रियाओं को देखने पर आधारित होती है। यह इन पोस्टों से स्पष्ट रूप से देखा जा सकता है सबसे प्रोग्रामरहास्य, जहां बहुत सारे नौसिखिया प्रोग्रामर घूमते हैं। कई हास्य, किसी न किसी हद तक, नकारात्मकता के विभिन्न रंगों से रंगे होते हैं: निराशा, निराशावाद, आक्रोश, कृपालुता और अन्य। और यदि यह आपको पर्याप्त नहीं लगता है, तो टिप्पणियाँ पढ़ें।

मैंने देखा कि जैसे-जैसे प्रोग्रामर अनुभव प्राप्त करते हैं, वे अधिक से अधिक नकारात्मक होते जाते हैं। शुरुआती, आने वाली कठिनाइयों से अनजान, उत्साह और यह विश्वास करने की इच्छा के साथ शुरुआत करते हैं कि इन कठिनाइयों का कारण केवल अनुभव और ज्ञान की कमी है; और आख़िरकार उनका सामना चीज़ों की वास्तविकता से होगा।

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

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

• "इस मॉड्यूल में बहुत सारी तार्किक विसंगतियाँ हैं, यह महत्वपूर्ण प्रदर्शन अनुकूलन के लिए एक अच्छा उम्मीदवार है।"
• "यह मॉड्यूल बहुत खराब है, हमें इसे दोबारा तैयार करने की जरूरत है।"
• "इस मॉड्यूल का कोई मतलब नहीं है, इसे फिर से लिखने की जरूरत है।"
• "यह मॉड्यूल बेकार है, इसे ठीक करने की जरूरत है।"
• "यह राम का एक टुकड़ा है, मॉड्यूल नहीं, इसे लिखने की बिल्कुल भी आवश्यकता नहीं थी, इसका लेखक क्या सोच रहा था।"

वैसे, यह "भावनात्मक रिलीज" है जो डेवलपर्स को कोड को "सेक्सी" कहने पर मजबूर करती है, जो शायद ही उचित है - जब तक कि आप पोर्नहब पर काम नहीं करते हैं।

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

नकारात्मकता की एक परेशान फिसलन भरी ढलान

कुछ साल पहले, मैं एक अनौपचारिक टीम लीड था और मैंने एक डेवलपर का साक्षात्कार लिया था। हम वास्तव में उसे पसंद करते थे: वह चतुर था, अच्छे प्रश्न पूछता था, तकनीक-प्रेमी था, और हमारी संस्कृति में अच्छी तरह से फिट बैठता था। मैं विशेष रूप से उसकी सकारात्मकता से प्रभावित हुआ और वह कितना उद्यमशील लग रहा था। और मैंने उसे काम पर रख लिया.

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

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

नकारात्मक तरीके

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

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

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

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

वास्तविकता शायद इन दोनों चरम सीमाओं के बीच में कहीं है।

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

नकारात्मकता इंजीनियरिंग पॉप संस्कृति है

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

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

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

प्रोग्रामिंग की दुनिया तेजी से बढ़ रही है और अपने कंटेनर की सीमाओं के खिलाफ जा रही है - गैर-प्रोग्रामिंग की दुनिया (या प्रोग्रामिंग की दुनिया गैर-प्रोग्रामिंग की दुनिया के लिए एक कंटेनर है? अच्छा सवाल है)।

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

मैंने नकारात्मकता के बारे में क्या सीखा

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

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

अंत में, नकारात्मक वस्तुतः आपके स्वास्थ्य को हानि पहुँचाता है.

मुझे लगता है कि मुस्कुराहट पर एक मास्टर क्लास इसी तरह होनी चाहिए।

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

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

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

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

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

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

मूलतः, मैं एक महत्वपूर्ण सबक लगातार सीख रहा हूं और पुनः सीख रहा हूं: लगातार क्रोधित होने और दर्द में रहने के लिए जीवन बहुत छोटा है।

स्रोत: www.habr.com