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

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

ऐसा कैसे हो सकता है? मैं हंसी के माध्यम से अपना चेहरा और सोब कवर करता हूं। मेरे सहकर्मी पूछते हैं कि क्या हुआ था, और मैं थोक में सबसे खराब हिट्स ऑफ बुलकडाटाइमीटर.जेएस 2018 को देखता हूं । हर कोई सहानुभूतिपूर्वक मेरे लिए सिर हिलाता है और सहमत होता है: वे हमारे साथ ऐसा कैसे कर सकते थे?

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

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



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

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



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

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

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

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

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

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

नकारात्मकता का बेचैन फिसलन भरा ट्रैक

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

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

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

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

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

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



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

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

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

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

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

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

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

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



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

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

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

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

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

अंत में, नकारात्मकता सचमुच आपके स्वास्थ्य को परेशान करती है ।


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

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

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

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

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

मुझे एक नया अवसर मिला जब मैंने स्टाफ मूल्यांकन के प्रमुख का पद संभाला। पूर्व मुख्य अभियंता के रूप में, मैं ध्यान से हमारे (लगातार सुधार) विरासत कोड पर अपनी राय की निगरानी करता हूं। परिवर्तन को अनुमोदित करने के लिए, आपको वर्तमान स्थिति की कल्पना करने की आवश्यकता है, लेकिन आप कुछ भी करने के लिए नहीं आते हैं यदि आप कराहते हुए, हमला करते हुए या ऐसा कुछ करते हैं। , , , , , .

, , , , . (« »), . , , (?) (« , , »). , .

, : , .