मैं 100x डेवलपर कैसे बना - एक जूनियर के रूप में

एक 10x डेवलपर, या एक रॉकस्टार डेवलपर, हर चीज में हर दूसरे डेवलपर से बेहतर होने का विचार एक मिथक है। इसके बजाय, आपको बहुत विशिष्ट परिस्थितियों में 100x डेवलपर, कुछ में 10x डेवलपर और यथासंभव अधिक से अधिक 1x डेवलपर बनने का प्रयास करना चाहिए। उन क्षेत्रों से अवगत होना महत्वपूर्ण है जिनमें आप उत्कृष्टता प्राप्त करते हैं और जिन क्षेत्रों में आपको काम करने की आवश्यकता हो सकती है। जब तक आप एक बड़ी टेक कंपनी के लिए काम नहीं करते हैं, तब तक संभावना है कि आप कई टोपियां पहनेंगे। दैनिक आधार पर, आपको जावा या टाइपस्क्रिप्ट जैसे फ्रंट-एंड, बैक-एंड और भाषा-विशिष्ट विकास के बीच स्विच करने में सक्षम होने की आवश्यकता होगी। यह हमारे उद्योग की हमेशा बदलती प्रकृति और समान कार्यों को प्राप्त करने के तरीकों की संख्या के कारण है - जैसे 400 से अधिक विभिन्न प्रोग्रामिंग भाषाओं में "हैलो वर्ल्ड" प्रिंट करना। हर चीज में अच्छा होना असंभव है, लेकिन किसी चीज में महान होना संभव है। विस्तृत रूप से, मैं एक दशक पहले की एक कहानी साझा करना चाहता हूं जो एक जीवन बदलने वाला क्षण था जिसका मेरे करियर पर बहुत बड़ा प्रभाव पड़ा। मैं एक 100x डेवलपर कैसे बना - एक जूनियर के रूप में मैंने एक बड़ी एमएनसी के साथ काम किया और उस टीम का हिस्सा था जो मांग को पूरा करने के लिए संघर्ष कर रही थी। उन्होंने एक कस्टम जावा वेब एप्लिकेशन बनाया था जिसका हजारों कर्मचारी दैनिक उपयोग कर रहे थे, लेकिन जैसे-जैसे SQL सर्वर के अंदर और बाहर जाने वाले रिकॉर्ड की संख्या बढ़ती गई। चीजें धीमी हो रही थीं। उन्होंने पहले ही SQL सर्वर को उसकी सीमा तक अपग्रेड कर दिया था और नए समाधानों की आवश्यकता थी। एक स्पष्ट परिणाम कुछ परिणामों को कैश करने के लिए मेम्कैश का उपयोग करना था। दुर्भाग्य से, अतीत में कुछ सुरक्षा घटनाओं और HA की कमी के कारण memcache पर प्रतिबंध लगा दिया गया था। प्रबंधक एक वर्ष से अधिक समय से मेमकैश के लिए अनुमोदन प्राप्त करने का प्रयास कर रहे थे लेकिन असफल रहे। इस बीच, देवों ने एक कठिन लड़ाई लड़ी क्योंकि प्रत्येक 10% सुधार को उपयोगकर्ता वृद्धि में दोगुने से नकार दिया गया था। यहीं पर मैं आया और शामिल हुआ। मुझे उनके पिछले 1 साल के संघर्ष के बारे में कोई जानकारी नहीं थी और यूआई में कुछ मामूली सुधार करने में मदद करने के लिए एक जूनियर डेवलपर के रूप में बोर्ड पर लाया गया था, जबकि वरिष्ठों ने प्रदर्शन पर ध्यान केंद्रित किया था। हालाँकि, क्योंकि मैं देव सर्वर के धीमे प्रदर्शन से बहुत नाराज़ था। और मैं हेज़ेलकास्ट के साथ खेल रहा था - एक नया जावा-आधारित सर्वर क्लस्टरिंग और कैशिंग लाइब्रेरी। मैंने इसे memcache के विकल्प के रूप में इस्तेमाल किया। और इसे एप्लिकेशन पर चलाने में सक्षम था, जिसमें कोई विशेष प्रतिबंध या विशेष अनुमोदन आवश्यकता नहीं थी, जिसने पिछले सभी समाधानों को समाप्त कर दिया। और एक ही सप्ताह के भीतर तैयार डेमो के साथ एक कार्यशील प्रोटोटाइप था। प्लेटफ़ॉर्म में एक पृष्ठ के लिए, एपीआई कॉल 10 सेकंड से अधिक से एक सेकंड से कम हो गई। यह गेम-चेंजर था। पूरी टीम बोर्ड पर कूद गई, और एक महीने के भीतर, हमारे पास उत्पादन में "क्लस्टरिंग समाधान जो निश्चित रूप से memcache नहीं है" था। जैसा कि मेरे टीम मैनेजर और उनके बॉस ने सभी के साथ भोज किया, मेरे प्रबंधक ने मुझसे कहा, कि जब वह मुझे एक स्मार्ट बच्चे के रूप में बोर्ड पर लाए, तो उन्होंने कभी मुझसे 10x या 100x प्रोग्रामर बनने की उम्मीद नहीं की थी जो रातोंरात उनकी समस्याओं को हल कर सके। और उस बयान ने मुझे बुरी तरह प्रभावित किया। क्योंकि मैं एक धोखेबाज था - एक भाग्यशाली ढोंग के अलावा कुछ नहीं। लकी इम्पोस्टर - जो एक 0.1x डेवलपर था तकनीकी रूप से, मैं 1x या 10x डेवलपर भी नहीं था। मैं अपने साथियों से कम जानता था, और मैं काम पर सीख रहा था। मेरे साथी मुझसे बेहतर फ्रंट एंड कर सकते थे और टीम जानती थी कि SQL को कैसे ऑप्टिमाइज़ करना है (और मुझे सिखाया, धन्यवाद!) मेरा सबसे बड़ा श्रेय यह था कि मैं "एनपीएम इंस्टाल मिरेकल" के बराबर करने में सक्षम था और इसे कॉन्फ़िगर करने के तरीके पर इसके मैनुअल को पढ़ा। पीछे देखने में, कई मुद्दे थे जिन्हें मैंने भाग्य से चकमा दिया था। राजनीति (जिसने पहली बार मेमकेचे को अवरुद्ध किया) केस का उपयोग करें (हमारे पास कोई लेखन विवाद सुरक्षा नहीं थी, जिसका अर्थ है कि यदि 2 संपादन एक ही एमएस में होते हैं, तो कैश बुरी तरह से अपडेट हो जाएगा। शुक्र है, ऐसा शायद ही कभी होता है) स्थिरता (hazelcast का v1 पागलों की तरह क्रैश हो जाता है, शुक्र है कि एपीआई सर्वर को HA मोड में तैनात करने के लिए डिज़ाइन किया गया था, इसलिए यह इंफ्रा टीम के लिए सबसे खराब बात थी) सुरक्षा (एक क्लस्टर में एपीआई सर्वर पर सभी डेटा के लिए एक खुला पोर्ट होना, मेरी ओर से एक बुरा विचार था, और एक बहुत ही छोटी गलती थी जब तक कि एक अन्य वरिष्ठ ने इसे सुरक्षित करने के तरीके पर डॉक्स को धन्यवाद नहीं पढ़ा) भाषा स्टैक (यदि सर्वर पायथन, .NET, C# या रूबी में था, तो मुझे नहीं पता होगा कि स्थानीय क्लस्टर कैश को कैसे शामिल किया जाए) मैं भाग्यशाली था कि मेरे पास मुट्ठी भर वन-ट्रिक टट्टू थे, जिसने मुझे सही स्थितियों में 100 गुना कर दिया। जो केवल टीम के बाकी सदस्यों द्वारा किए गए मूलभूत कार्यों के कारण ही संभव हुआ। मैं भी भाग्यशाली था कि मेरे प्रबंधकों और मालिकों ने मुझे उन समस्याओं को चुनने की अनुमति दी जिन्हें मैं ठीक करना चाहता था, क्योंकि उन्होंने मुझे तेजी से ट्रैक किया, और "उनकी समस्याओं को ठीक करने" के लिए मुझे कई टीमों में फेंक दिया। मुझे अपने भाग्य-से-प्रभाव अनुपात को अधिकतम करने और "चमत्कार" दोहराने की अनुमति देते हुए। अनुभव के साथ, मुझे इसके विपरीत का भी एहसास हुआ - मैं फ्रंट-एंड डेवलपमेंट में धीमा हूं। 10x इंजीनियर के रूप में तेजी से ट्रैक किए जाने से पहले मुझे मूल रूप से यही करना चाहिए था और इसने मुझे वर्षों में बहुत कुछ प्रतिबिंबित किया। जैसा कि यह रास्ता हो सकता था, मैं फंस गया होता। इसने मुझे यह भी मारा कि दृष्टिहीनता में, हेज़ेलकास्ट, और कई अन्य तकनीकों में "महारत हासिल" की। अन्य टीमों के लिए यह कितना विफल रहा होगा, यहां तक कि एक ही संगठन में, क्या यह अद्वितीय स्थिति और सुरक्षा उपायों के लिए नहीं था, जिसका श्रेय बाकी टीम को दिया जाना चाहिए था। मैं भाग्यशाली रहा, एक जूनियर के रूप में, अगर कुछ और। https://twitter.com/CenturiiC/status/1566060367825883136?embedable=true यही कारण है कि वरिष्ठ डेवलपर्स 10x जूनियर डेवलपर्स होते हैं एक बार जब हम इंजीनियरिंग के सामान्यीकरण से परे देखते हैं, तो यह स्पष्ट हो जाता है कि हर किसी का अपना कौशल होता है, जो 100x से 0.1x तक हो सकता है। इन वर्षों में, जैसा कि मैंने कई टीमों और परियोजनाओं में स्थानांतरित किया, मैं अंततः "वरिष्ठ" डेवलपर बन गया। इस समय के दौरान, मैंने महसूस किया कि वरिष्ठों के पास आमतौर पर अधिक कौशल होता है, और वे जानते हैं कि वे किसमें अच्छे और बुरे हैं। वे सक्रिय रूप से अपने प्रबंधकों को सूचित कर सकते हैं और तदनुसार कार्यों को प्राथमिकता दे सकते हैं। इसका मतलब यह नहीं है कि वे सब कुछ करना जानते हैं, लेकिन इसका मतलब यह है कि वे जानते हैं कि क्या नहीं करना है। दूसरी ओर, जूनियर्स को इससे जूझना पड़ता है क्योंकि उनके पास यह जानने का अनुभव नहीं होता कि वे किसमें अच्छे हैं या किसमें खराब। केवल "कोशिश" करने के अलावा इसका पता लगाने का कोई आसान तरीका नहीं है। एक बार जब यह समझ में आ जाता है, तो यह स्पष्ट हो जाता है कि यह उन चीजों की संख्या को अधिकतम करने के बारे में है जिन्हें आप जानते हैं कि आप मज़बूती से और अच्छी तरह से कर सकते हैं। जब कार्यों को सौंपे जाने की बात आती है तो यह आपके भाग्य कारक को अधिकतम करने के बारे में भी है, और यह सुनिश्चित करने के बारे में है कि आप उन चीजों से नहीं फंस रहे हैं जिनमें आप खराब हैं। एक तरह से जूनियर्स के लिए, उनकी प्रगति काफी हद तक उनके भाग्य और कौशल के संरेखण पर निर्भर करेगी। वरिष्ठों के पास अपनी प्रगति को चलाने के तरीके पर अधिक (लेकिन पूर्ण नहीं) नियंत्रण था। इस मामले में: किस्मत बाइनरी नहीं है। आप अपने साथ संरेखित होने वाली स्थितियों की संख्या बढ़ा सकते हैं। 100x और 10x पर अपनी स्थिति भाग्य को कैसे अधिकतम करें सभी के लिए, लेकिन विशेष रूप से जूनियर्स के लिए और जो अभी शुरुआत कर रहे हैं, उनके लिए सबसे अच्छी बात यह है कि तकनीक और खोज में नई चीजों को आजमाते रहें। इससे आपको यह पता लगाने में मदद मिलेगी कि आप किसमें अच्छे हैं और किसमें खराब हैं। जिन लोगों को इस बात का बेहतर अंदाजा है कि वे किस चीज में अच्छे हैं, उनके लिए अगला कदम उन स्थितियों की संख्या का विस्तार करना है जहां वे अपना सर्वश्रेष्ठ प्रदर्शन कर सकते हैं। इसमें कुछ अभ्यास और उन तकनीकों से संबंधित अनुसंधान शामिल हैं जिन्हें वे पहले से जानते हैं। एक बार जब आप किसी चीज़ में महान हो जाते हैं, तो सुनिश्चित करें कि आप इसे अपना लें ताकि आपके प्रबंधकों और मालिकों को पता चले कि यह वही है जो उन्हें आपको देना चाहिए। इससे उन 10x या 100x स्थितियों के बार-बार हिट होने की संभावना बढ़ जाएगी। कम से कम एक ऐसी चीज़ खोजें जिसमें आप अच्छे हों, भले ही वह बहुत छोटी और संकीर्ण चीज़ हो। वहां से निर्माण करें। (कुछ उल्लेखनीय उदाहरणों में रेगेक्स और वेबपैक को कॉन्फ़िगर करना शामिल है।) वरिष्ठ नागरिकों के लिए, यदि आपने अभी तक ऐसा नहीं किया है, तो विकास के तकनीकी पहलुओं से परे देखना शुरू करें। इसका मतलब यह नहीं है कि आपको प्रबंधन में जाना होगा। लेकिन अपने अद्वितीय तकनीकी ज्ञान के साथ, आप उपयोगकर्ता या व्यावसायिक उपयोग के मामले को समझने में अधिक सक्रिय भूमिका निभा सकते हैं। यह आपको और आपकी टीम के लिए 10x या 100x सफलता दर सुनिश्चित करने के लिए अपने प्रबंधकों के साथ अनुकूलन करने की अनुमति देगा। उन लोगों के लिए जो नौकरी की तलाश में हैं, यदि आप जानते हैं कि आप किसी चीज में अच्छे हैं, भले ही वह 10 गुना हो, तो कुछ शोध करें और अपनी नौकरी की खोज में गहराई तक उतरें। एक अच्छी तरह से वित्तपोषित स्टार्टअप या एमएनसी खोजने की कोशिश करें, जो उस चीज़ में कठिनाई का सामना कर रहा है जिसमें आप अच्छे हैं। हालांकि इसे पूरा करना मुश्किल हो सकता है और इसमें कुछ नेटवर्किंग शामिल होती है, अगर आप खुद को सही जगह और समय पर रखते हैं, तो यह आपके और इसमें शामिल कंपनी दोनों के लिए प्रभाव को अधिकतम करेगा। भाग्य कारक को सुधारने के लिए ये सभी चीजें हैं, आप समय के साथ धीरे-धीरे कर सकते हैं। और उस 10x अनुभव को लगातार वितरित करें। भाग्य बनाने के तरीके पर लेख पढ़ने के लिए विशेष शाउट आउट: स्विक्स swyx.io/create-luck सीटीओ और टीम लीडर के रूप में आज भी, यह अभी भी कायम है - 10x एक मिथक है - हर कोई 100x और 0.1x दोनों है कुछ लोग सोच सकते हैं कि जैसे यूआई परीक्षण उपकरण का सीटीओ फ्रंट-एंड प्रौद्योगिकियों के साथ अच्छा होगा। हालाँकि, यह सच्चाई से बहुत दूर है। जब Vue.js या React जैसे आधुनिक फ्रंट-एंड फ्रेमवर्क के साथ फ्रंट-एंड कंपोनेंट्स लिखने की बात आती है, तो कंपनी में हमारा औसत फ्रेश हायर या जूनियर आमतौर पर मुझसे CTO से तेज होता है। Uilicious.com इसने एक टीम लीडर/मैनेजर के रूप में मेरे दृष्टिकोण को बदल दिया है। इसने मुझे दिखाया कि 10x इंजीनियर मिथक कितना जहरीला और बुरा है। यह लेबलों का अत्यधिक सरलीकरण और बहुत ही विशिष्ट स्थितियों का सामान्यीकरण है। यह एक जहरीली भ्रांति है जिसे ठीक करने की जरूरत है। लगभग हर स्टार्टअप 10x इंजीनियर मिथक, जब गहराई से देखा जाता है, तो सही जगह और समय में अद्वितीय ज्ञान वाला एक व्यक्ति होता है। और उन कार्यों से बचने में सक्षम थे जिनमें वे 0.1x थे। मेरे मामले में, यह फ्रंट-एंड डेवलपमेंट पर बुनियादी ढांचे पर ध्यान केंद्रित कर रहा था। इसके बजाय, मेरे पास टीम के अन्य सदस्य हैं जो फ्रंटएंड डेवलपमेंट करने में 1000 गुना बेहतर हैं। एक प्रबंधक के रूप में यह एक महत्वपूर्ण अहसास है, क्योंकि प्रत्येक व्यक्ति के लिए जो एक कार्य में 100x है, एक कार्य है जो उन्हें 0.1x बनाता है क्योंकि वे एक समय सिंक में फंस जाते हैं। यह समझने और पहचानने के बारे में है कि प्रत्येक व्यक्ति 100x किस पर है, और वे 0.1x किस पर हैं। हालांकि यह बहुत सीधा लगता है, व्यवहार में यह काफी कठिन है। ऐसी बहुत सी बातें हैं जो एक टीम लीडर या डेवलपर को तब तक नहीं पता होंगी जब तक कि उन्होंने इसे पहले आजमाया न हो। या उन विशिष्ट परिस्थितियों में शामिल कौशल को सुधारने और मास्टर करने के लिए समय और अवसर दिया जाता है। ऐसी कई चीजें भी हैं, विशेष रूप से नई प्रौद्योगिकियां, जिनमें कोई भी अच्छा नहीं है, और यह सब जोखिम लेने और अवसर लेने के बारे में है। यह टीम लीडर का काम है कि वह हर किसी की जरूरतों के हिसाब से कार्यों को व्यवस्थित करे। और अगर यह संभव नहीं है, तो यह समझने के बारे में भी है कि भले ही कोई आपकी स्थिति में 100 गुना नहीं हो सकता है, वे संभावित रूप से अन्य टीमों में कहीं और हो सकते हैं। और प्रत्येक डेवलपर पर है, यह पता लगाने के लिए कि वे क्या अच्छे और बुरे हैं, और तदनुसार उनकी टीम को संवाद करने के लिए। तो 10x इंजीनियर मिथक के साथ मौत, विशिष्ट परिस्थितियों में 100x इंजीनियर लंबे समय तक जीवित रहें पुनश्च: यदि आपने कोई नए साल के संकल्प नहीं किए हैं। शायद आपका भाग्य सतह क्षेत्र बढ़ाना यह हो सकता है! ~ 🖖 जियो और खूब तरक्की करो यूजीन चीह: का सीटीओ uilicious.com मूल रूप से पोस्ट किया गया: https://substack.tech-talk-cto.com/p/dev-to-cto-how-do-i-become-a-10x छवि क्रेडिट ऑस्टिन नील - रॉकस्टार छवि: unsplash.com/photos/sxxnM-tRlVg XKCD - मानकों पर कॉमिक: xkcd.com/927 CenturiiC - अनुभवी इंजीनियरों पर कॉमिक: twitter.com/CenturiiC/status/15660603678258.. लुकास सैंटोस - पासा चित्र: unsplash.com/photos/XIIsv6AshJY व्लाद हिलिटानु - लेगो फ़िग्स: unsplash.com/photos/1FI2QAYPa-Y