यह जॉन एसेस्पॉ द्वारा लिखे गए एक लेख का अनुवाद है, जो वर्तमान में एटसी में प्रौद्योगिकी के वरिष्ठ उपाध्यक्ष हैं।यहाँ अनुवाद का सिलसिला जारी हैहमारी गतिविधि के क्षेत्र में, ज्ञान के विशाल खंड हमारे लिए उपलब्ध हैं, विशेष रूप से वे जो डेवलपर को प्रभावी बनने की अनुमति देते हैं। लेकिन किसी कारण से, गैर-तकनीकी क्षेत्रों में प्रबंधकों के विशिष्ट कार्यों और जिम्मेदारियों पर कई पुस्तकों के अस्तित्व के बावजूद, मैं व्यावहारिक रूप से एक अच्छी
अग्रणी डेवलपर बनने के लिए नई किताबें या लेख नहीं देखता हूं। एक उल्लेखनीय अपवाद, निश्चित रूप से,
केट मात्सुदाईरा द्वारा लेख है
[अनुवादक से: फोटोग्राफ में, वैसे, वह वह है] ,
जिन्होंने इंजीनियरिंग के सांस्कृतिक घटकों के बारे में बहुत कुछ
लिखा है ।
लेकिन एक ही समय में, मेरे सभी परिचित जो सफल डेवलपर्स हैं, अपने गुरुओं को याद करते हैं जिन्होंने उन्हें सिखाया कि इसका
"नेता" होने का क्या मतलब है।
मैं अपने दोस्त थियो के साथ "होस्ट" के अर्थ को परिभाषित करने में पूरी तरह सहमत हूं। ओ'रेली की
वेब ऑपरेशंस बुक में अपने अध्याय में, वे लिखते हैं:
जेनरेशन एक्स (और इससे भी अधिक पीढ़ी वाई ) तत्काल संतुष्टि की संस्कृति है। मैंने इंजीनियरों की एक आश्चर्यजनक संख्या के साथ काम किया, जो सोचते हैं कि वरिष्ठ इंजीनियरिंग पदों के लिए उनका "कैरियर पथ" केवल पांच साल से अधिक नहीं लेगा क्योंकि वे स्मार्ट हैं। लेकिन यह बस संभव नहीं है। उनमें से बहुत सारे हैं। हर कोई नेता नहीं हो सकता। सच में, अगर पांच साल में आप एक नेता हैं, तो आप अपने विकास के चरम पर हैं? क्या आपको पाँच वर्षों में और भी अधिक मूल्यवान अनुभव नहीं मिलेगा? फिर क्या? सुपर इंजीनियर? और पाँच साल बाद? "सुपर-डुपर इंजीनियर।" मुझे लगता है कि समस्या हमारे उद्योग के युवाओं में है। और वास्तव में, कुछ पंद्रह वर्षों से वेब संचालन में शामिल हैं। उद्योग के विकास की गतिशीलता को देखते हुए, कई लोग प्रबंधकीय पदों या एक उद्यमी दौड़ के जोखिम को पसंद करते हैं।
वह सही है, वेब प्रशासन क्षेत्र अभी भी बहुत छोटा है। और इसलिए, किसी को आश्चर्यचकित नहीं होना चाहिए जब "अग्रणी" शीर्षक वाले लोग तकनीकी और मानवीय दृष्टिकोण से, अपरिपक्व व्यवहार प्रदर्शित करते हैं। यदि आपने पूरे थियो अध्याय को नहीं पढ़ा है, तो मेरा सुझाव है कि आप ऐसा करें।
लेकिन फिर भी, हमारे लिए "नेता" होने का क्या मतलब है? मुझे उन डेवलपर्स को काम पर रखना, समर्थन करना और मदद करना है, जिन्हें "अग्रणी" माना जाता है, और इस मुद्दे पर मेरी निश्चित रूप से एक राय है। यह विचार कि करियर के विकास में एक निश्चित सीमा है, लेकिन मैं यह जोड़ूंगा कि यह सीमा धुंधली है - यह कार्यों की एक सरल सूची नहीं है। आप केवल एक सुबह "नेता" नहीं बनेंगे, क्योंकि आपकी स्थिति का नया नाम प्रचार के बाद इसके बारे में बोलता है। अग्रणी डेवलपर्स सब कुछ नहीं जान सकते। उनका तकनीकी ज्ञान सही नहीं है, लेकिन वे इसके बारे में चिंता नहीं करते हैं।
रैंक और धुंधली उम्मीदों के बीच भ्रम से बचने के लिए, मैं इंजीनियरिंग
परिपक्वता के बारे में बात करूंगा।
मेरा मानना है कि "लीड" इंजीनियर एक
परिपक्व इंजीनियर है।
मैं उस हिस्से को छोड़ दूंगा जहां तकनीकी क्षेत्रों को सूचीबद्ध करना संभव होगा, जो एक परिपक्व इंजीनियर को एक या दूसरे तरीके से होना चाहिए या जिसे समझना चाहिए (उदाहरण के लिए, नेटवर्क, फ़ाइल सिस्टम, एल्गोरिदम, आदि), और, इसके बजाय, उन व्यक्तिगत गुणों को उजागर करें। जो मुझे बताते हैं कि एक व्यक्ति किसी संगठन या व्यवसाय के तकनीकी पक्ष को सकारात्मक रूप से प्रभावित कर सकता है।
मुझे Quora पर एक प्रश्न पूछा गया था: “
तकनीकी विभागों के सर्वश्रेष्ठ प्रबंधकों में निहित विशिष्ट विशेषताएं (तकनीकी कौशल और अनुभव के अलावा) क्या हैं? "। प्रश्न का उत्तर देते हुए, मुझे एहसास हुआ कि मैं स्वयं उत्तर में वर्णित गुणों के अधिकारी होने का निरंतर प्रयास करता हूं। यह पोस्ट उस उत्तर के समान है।
यह कहने योग्य है कि वेब विकास और प्रशासन में अग्रणी इंजीनियरों में अन्य क्षेत्रों के प्रमुख इंजीनियरों (यांत्रिकी, इलेक्ट्रिक्स, रसायन विज्ञान, आदि) के समान विशेषताएं हैं, जिसके लिए "
इंजीनियरिंग के लिखित कानून " लागू होते हैं। फिर, यदि आपने इस पुस्तक को नहीं पढ़ा है, तो मैं इसे करने की सलाह देता हूं। यह 1944 में
अमेरिकन सोसाइटी ऑफ मैकेनिकल इंजीनियर्स द्वारा प्रकाशित किया गया था। पुस्तक का एक अंश
यहाँ पढ़ा जा सकता
है ।
इस तथ्य के बावजूद कि पुस्तक की संरचना और शब्दांश पुरानी हैं (
"... कार्यस्थल पर बेईमानी भाषा का उपयोग करने से बचना चाहिए ..." या
"... पुरुषों को दाढ़ी और मूंछों को शेविंग करने पर थोड़ा ध्यान देना चाहिए" ), यह गैर-तकनीकी अपेक्षाओं, जिम्मेदारियों का एक अच्छा विवरण देता है। प्रबंधकों और परिपक्व इंजीनियरों को कैसे कार्य करना चाहिए, इस बारे में एक तकनीकी संगठन के आंतरिक कामकाज।
परिपक्व इंजीनियरों के अनिवार्य गुण
आवश्यक गुणों का वर्णन करने के प्रयासों के साथ सभी लेख उनकी लिस्टिंग में बिंदुओं से भरे होंगे: इंजीनियरिंग में बात करने के लिए कुछ है। मैं केवल कुछ गुणों का वर्णन करूंगा: मैं कुछ स्वयं तक पहुंच गया, मैंने कुछ अलग-अलग स्रोतों से लिया, कई ऊपर लिखे गए लिखित कानूनों से।
परिपक्व डेवलपर्स अपने विचारों की रचनात्मक आलोचना का स्वागत करते हैं
परियोजना के विकास और योजना के अंत में मैंने जितने भी सफल इंजीनियरों से मुलाकात की, वे लगातार अपने सहयोगियों से इसी तरह के सवाल पूछते हैं:
- मैं क्या याद कर सकता था?
- यह काम क्यों नहीं हो सकता है?
- मैं क्या गलत हो सकता है?
- यदि तकनीकी दृष्टि से भी यह सही लगता है, तो क्या यह पूरे संगठन के लिए पर्याप्त होगा कि वह इसका प्रबंधन, रखरखाव और विस्तार कर सके?
वे जानते हैं कि उनके द्वारा किया गया कुछ भी केवल उनके हाथों में नहीं रहेगा, और सहकर्मियों का एक अच्छा परीक्षण है जो उनके उत्पाद को बेहतर बनाएगा। जैसा कि कहीं कहा गया था, वे "बुरी खबर से खुश हैं।"
परिपक्व डेवलपर्स को एहसास होता है कि उन्हें व्यक्तिगत तरीके से कैसे माना जाता है
एर्लांग में
ब्लूम फिल्टर या सी में एक मल्टीथ्रेडेड प्रोग्राम लिखना पर्याप्त नहीं है। एक सपने में, यह सब कोई फर्क नहीं पड़ता कि कोई भी आपके साथ काम नहीं करना चाहता है। एक परिपक्व इंजीनियर जानता है कि उसके विचारों की पूर्णता, लालित्य और श्रेष्ठता का मतलब कुछ भी नहीं है अगर कोई उसके साथ काम नहीं करना चाहता है क्योंकि वह एक
मूर्ख है । भोग, कमज़ोरी, संकीर्णता और आत्म-प्रचार अन्य इंजीनियरों को आपसे दूर कर देते हैं (शायद केवल अवचेतन पर)। लेकिन एक मायने में विकास का आनंद लोगों की उस कंपनी का आनंद लेने में है, जिसके साथ आप कुछ नया कर रहे हैं। एक इंजीनियर जो आसानी से दूसरे मोरन को बुलाता है, उसके विकास में बाधा उत्पन्न होती है।
इसलिए, परिपक्व डेवलपर्स विचार कर रहे हैं कि वे दूसरों के साथ कैसे बातचीत करते हैं। हां, सभी परिपक्व इंजीनियर आसानी से लोगों के साथ संवाद नहीं कर सकते हैं, लेकिन हर कोई जानता है कि वे क्या बेहतर कर सकते हैं, और लगातार अपने सहयोगियों और प्रबंधकों से सावधानीपूर्वक जांच करने के लिए कहें कि वे क्या और कैसे करते हैं। उनके विचारों को प्रसारित करने में मुखर होना महत्वपूर्ण है, लेकिन निष्क्रिय या आक्रामक नहीं।
मैंने पहले ही
कहा है , लेकिन यह फिर से जोर देने के लायक है: दूसरे लोग जो आपके साथ काम करना चाहते हैं, वह सीधे इंगित करता है कि आप अपने विकास करियर में कितने सफल होंगे। वह व्यक्ति बनें जिसके साथ हर कोई काम करना चाहता है।
इसका मतलब यह नहीं है कि आपको किसी अन्य व्यक्ति द्वारा किए गए
कार्य (या आलोचना को सुनने) की रचनात्मक आलोचना नहीं करनी चाहिए, किसी को नाराज करने से डरना चाहिए। किसी को मोरन कहने और उनके कोड या उत्पाद की खामियों को इंगित करने के बीच अंतर है। हमारी बातचीत में, थियो ने एक और क्षेत्र नोट किया जिसमें हम बेहतर के लिए बदल सकते हैं:
हमें, एक उद्योग के रूप में, एक दूसरे के चरित्र या उपस्थिति की आलोचना नहीं करनी चाहिए, लेकिन हमें अपने काम के परिणामों की आलोचना करनी चाहिए। हमें मोटी त्वचा विकसित करने की आवश्यकता है और आलोचना को उस दृष्टिकोण से सीखना चाहिए जो व्यक्ति पर ध्यान केंद्रित नहीं करता है।
ड्यूक थे और हमेशा रहेंगे, और उन्हें सावधान रहना चाहिए। लेकिन हमें उनके बच्चे के रूप में किसी और के कोड से छुटकारा पाना चाहिए। कोड कुछ भी महसूस नहीं करता है, इसमें परिसरों नहीं है, और, स्वाभाविक रूप से, यह आपके जीन में एम्बेडेड सबसे महत्वपूर्ण गुणवत्ता (प्रजनन करने की क्षमता) नहीं दिखाएगा।
इसके साथ, मुझे लगता है, "लिखित कानून" (मेरा जोर) से एक अंश है:
पत्रों, नोटों, और अन्य दस्तावेजों के प्राप्तकर्ता के रूप में चिन्हित करें, जिन पर अन्य विभागों के हित प्रभावित हो सकते हैं।
युवा श्रमिकों द्वारा बहुत नुकसान पहुंचाया गया था जिन्होंने हानिकारक या असुविधाजनक जानकारी वाले दस्तावेजों को वितरित किया था। हां, एक नवागंतुक के लिए इस तरह के एक दस्तावेज में "बम" को पहचानना आसान नहीं है, लेकिन, सामान्य तौर पर, यह स्पष्ट है कि अगर किसी के हितों को नोट में या अन्य लोगों की खामियों का पता चलता है तो समस्याएं उत्पन्न हो सकती हैं। यदि दस्तावेज़ व्यापक रूप से वितरित किया जाता है या यदि यह उत्पादन समस्याओं या क्लाइंट्स पर चर्चा करता है, और यदि आप पूरी तरह से सुनिश्चित नहीं हैं कि आप सही हैं, तो आप अपने बॉस से बेहतर परामर्श करेंगे।
यह उद्धरण पुस्तक की काफी उम्र पर जोर देता है, लेकिन मेरा मानना है कि अब भी इन शब्दों का सार प्रासंगिक है। छोटी सोच और अज्ञानता के बारे में कुछ भी नहीं कहा जाता है क्योंकि एक बुरा विचार, असंयमित, जहरीला हमला ट्वीट फेंक रहा है। शुरुआती परिष्कृत तकनीकों पर 140 वर्णों में भाग कर गलती करते हैं।
मैं हमेशा ऐसे सार्वजनिक बयानों पर ध्यान देता हूं, जब मैं उनके सामने आता हूं, और अगर ऐसा व्यक्ति एटसी में हमारे साथ साक्षात्कार के लिए आता है, तो मैं उसे काम पर रखने से पहले ध्यान से सोचूंगा (क्रिस्टोफर ब्राउन
ने वेलोसिटी लंदन में अपनी रिपोर्ट
में इस बारे में
बात की )।
परिपक्व डेवलपर्स पूर्वानुमान को दूर नहीं करते हैं, और लगातार उनमें सुधार करते हैं
लिखित कानूनों से :
वादे, कार्यक्रम और पूर्वानुमान एक सुव्यवस्थित व्यवसाय के लिए आवश्यक और महत्वपूर्ण उपकरण हैं। कई इंजीनियर इसे नहीं समझते हैं और अपने दायित्वों के लिए कष्टप्रद जिम्मेदारी से बचते हैं। आपको जिन कार्यों के लिए जिम्मेदार हैं और जिन विभागों से आप जुड़े हुए हैं, उनके पूर्वानुमान के आधार पर आपको अपने पूर्वानुमानों के आधार पर वादे करने होंगे। इस शब्द के साथ किसी को भी काम में देरी नहीं करनी चाहिए: "मैं कुछ भी वादा नहीं कर सकता, मेरा काम बहुत सारे अनिश्चित कारकों से जुड़ा हुआ है।"
पूर्वानुमान के लिए जिम्मेदारी से बचना ऐसा है: "मैं बुनियादी ढांचे के महत्वपूर्ण हिस्सों को लिखने के लिए विश्वसनीय होने के लिए तैयार नहीं हूं।" सभी मामले पूर्वानुमान पर निर्भर करते हैं, और परियोजना में शामिल सभी डेवलपर्स
संयुक्त गतिविधियों में लगे हुए
हैं , जिसका अर्थ है कि सभी को अपनी
भविष्यवाणी के लिए जिम्मेदार होना चाहिए। सामान्य तौर पर, परिपक्व इंजीनियर सुरक्षित रूप से एक निश्चित गैर-शून्य स्तर अनिश्चितता और जोखिम के साथ काम कर सकते हैं।
परिपक्व डेवलपर्स ने अंतर्ज्ञान विकसित किया है, भले ही वे इसके बारे में नहीं जानते हों।
यह कोड बहुत अच्छा लग रहा है, मुझे खुद पर गर्व है। मैंने अन्य लोगों से इसे जांचने के लिए कहा और सभी समीक्षाएं लिखीं। और मुझे फिर से लिखने और सही करने में कितना समय लगेगा? जब यह वहां पहुंच जाएगा तो मेरा कोड सर्वर को कैसे प्रभावित करेगा? CPU / मेमोरी / डिस्क / नेटवर्क उपयोग परिवर्तन कैसे और कितना होगा? क्या अन्य इस कोड को समझ सकते हैं? क्या दूसरों के लिए खुदाई करने और उस पर विस्तार करने के लिए मेरा कोड सरल है?
परिपक्व डेवलपर्स समझते हैं कि हर परियोजना स्वर्ग से सितारों को याद नहीं करेगी
कोई फर्क नहीं पड़ता कि आपके पहले असाइनमेंट कितने अर्थहीन या महत्वहीन लग सकते हैं, उनके लिए अपना सर्वश्रेष्ठ प्रदर्शन करें।
चीजों को अंत तक लाने की क्षमता का अर्थ है वह करना, जिसमें आपकी रुचि नहीं है। कोई फर्क नहीं पड़ता कि परियोजना कितनी आकर्षक है, फिर भी उबाऊ और थकाऊ कार्य होंगे, ऐसे कार्य जो शुरुआती अपनी गरिमा या स्थिति से नीचे मानते हैं। मेरा दोस्त, केलन इलियट-मैक्र्री (एट्टी में सीटीओ), निम्नलिखित कहता है:
कभी-कभी उबाऊ कार्यों की सादगी में मुक्ति पाई जा सकती है। परिपक्वता का कहना है कि ऐसे कार्यों को जल्दी से पूरा करने और आगे बढ़ने की आवश्यकता है। कभी-कभी उबाऊ कार्यों में अत्यधिक अनुशासन और एकाग्रता की आवश्यकता होती है। अजीब तरह से पर्याप्त, सबसे उबाऊ कार्य जो केवल प्रमुख इंजीनियरों द्वारा किए जाते हैं वे एक ही समय में सबसे असामान्य हो सकते हैं।
परिपक्व डेवलपर्स कौशल और दूसरों की योग्यता को पंप करते हैं
उन्होंने महसूस किया कि कुछ बिंदु पर उनके व्यक्तिगत योगदान अब परियोजना की संभावित गति के अनुरूप नहीं होंगे। उन्हें पता चलता है कि कोई भी आदमी एक ही बार में सब कुछ नहीं कर सकता है, और दुनिया के सबसे बड़े करतब
टीमों द्वारा पूरे किए जाते
हैं , ना कि उत्कृष्ट एकल द्वारा। टॉम लिमोनसेल्टी ने अपने ब्लॉग में
इसे साबित किया है।
Etsy में, हम इसे "मन का इनाम" कहते हैं। मन की उदारता हमारे सबसे महत्वपूर्ण इंजीनियरिंग मूल्यों में से एक है, लेकिन, इसके अलावा, यह हमारे इंजीनियरिंग कर्मचारियों की मुख्य जिम्मेदारी है। ये लोग अपना समय युवा और नए डेवलपर्स को प्रशिक्षित करने में लगाते हैं ताकि जितना संभव हो उतने कर्मचारी न केवल समझ सकें कि वे
क्या कर रहे हैं, बल्कि
क्यों । इस स्तर पर "मछली को पढ़ाने" की क्षमता अनिवार्य है, और इसके लिए पूरे संगठन के धैर्य और दूरदर्शी निवेश दोनों की आवश्यकता होती है।
इसलिए, यह कहने के बजाय, "तो, आगे बढ़ें, मुझे इसे करने दें," हम कहते हैं, "स्पष्ट है, चलो इससे निपटते हैं। मैं आपको दिखाऊंगा कि मैं कैसे / डीबग / इत्यादि लिखता हूं, फिर आप ऐसा ही करेंगे ताकि मैं यह सुनिश्चित कर सकूं कि आप इसे कैसे और क्यों समझते हैं। "
यह अनुवाद के पहले भाग को पूरा करता है। मुझे रचनात्मक आलोचना और सलाह पर खुशी होगी। मैंने कोशिश की, लेकिन शायद मैंने कुछ समझा और गलत तरीके से या अनाड़ी रूप से अनुवाद किया - अपने विकल्पों का सुझाव दें। GitHub पूल अनुरोध स्वीकार किए जाते हैं।दूसरा भाग