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

टर्मिनल में अजीब चरित्र दर्ज करने के लिए नियमित रूप से धन प्राप्त करने के इस पहले दशक के बारे में सोचकर, मैं कुछ टिप्पणियों को साझा करना चाहूंगा कि मेरी सोच काम के वर्षों में कैसे बदल गई है ।

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

वर्तमान वरिष्ठ भी अपने कनिष्ठ अनुभव से सीखे गए पाठों के बारे में मजेदार (और थोड़ा अपमानजनक) कहानियाँ साझा करना चाहते हैं।

स्पष्टता के लिए, मैं इस बात पर जोर देता हूं कि जूनियर्स अद्भुत हैं : बस नई चीजों को सीखने के लिए काम पर दिखाई दे रहे हैं - इसके लिए पहले से ही बहुत सारे साहस की आवश्यकता होती है। यह लेख मेरे अपने अनुभव और प्रशिक्षण के बारे में है। मैं बिल्कुल भी सामान्य नहीं करता हूं कि सभी जूनियर डेवलपर्स इस तरह से सोचते हैं या व्यवहार करते हैं।

मुझे उम्मीद है कि आप पोस्ट का आनंद लेंगे और आपको अतीत या वर्तमान से कुछ याद दिलाएंगे।

प्रतिक्रिया के लिए Artyom और Sarah को धन्यवाद!

कनिष्ठ का पूर्ण सत्य जिसमें से अनलिंक करना आवश्यक था

1. मैं एक वरिष्ठ डेवलपर हूं

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

इससे पहले कि मैं अपने बेडरूम में कई वर्षों से कोडिंग कर रहा था, मुझे यकीन था कि इन वर्षों को "अनुभव के वर्षों" के रूप में गिना जाता है। इसलिए, जब मुझसे पूछा गया कि मैंने PHP में कितना अनुभव लिखा है, तो मैंने आत्मविश्वास से उत्तर दिया: "3 या 4 साल!"

मुझे लगा कि मैं SQL के बारे में बहुत कुछ जानता हूं क्योंकि मैं बाहरी जॉइन (बाहरी जुड़ाव) कर सकता हूं।

और जब मैंने गुगली की, तो मुझे पता चला कि तीन से चार साल के अनुभव का मतलब बहुत पैसा है।

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

इसलिए मैं 24 साल की परिपक्व उम्र में एक वरिष्ठ डेवलपर बन गया।

आखिरकार, वे मुझे यह पद नहीं देते अगर मैं वास्तव में एक वरिष्ठ डेवलपर नहीं होता, ठीक है? बेशक, मेरे प्रभावशाली अनुभव ने मुझे इस मुकाम तक पहुंचाया है, इसलिए लोगों को मेरी बात सुननी चाहिए !!! मैं अपने तकनीकी करियर के चरम पर हूं, जबकि कार्यालय में सबसे छोटा हूं।

बिल्कुल बॉस की तरह।

मुझे आखिर समझ में क्या आया

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

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

मैंने यह भी सीखा कि नौकरी के शीर्षक का अपने आप से कोई मतलब नहीं है । CTO की स्थिति 5 लोगों, 50 या 500 लोगों की टीम में हो सकती है। यह पूरी तरह से अलग काम है, हालांकि नाम समान है। इसलिए "वरिष्ठ" का मेरा शीर्षक मुझे एक अग्रणी प्रोग्रामर नहीं बनाता था। इसके अलावा, पदानुक्रमित शीर्षक स्वाभाविक रूप से त्रुटिपूर्ण हैं और तुलना करना मुश्किल है। मैंने महसूस किया कि नामों में फंसना महत्वपूर्ण नहीं है और आपको उन्हें किसी प्रकार के बाहरी चेक के रूप में उपयोग नहीं करना चाहिए।

2. हर कोई परीक्षण लिखता है

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

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

क्योंकि ... ठीक है, यह मुफ़्त है।

आप वित्तीय आय या विशिष्ट परिणामों के लिए भी जिम्मेदार नहीं हैं। हालांकि, एक वैज्ञानिक संस्थान में एक प्रोग्रामर का काम पूरी तरह से अलग लेख के लिए एक विषय है।

संक्षेप में, मैंने बड़ी उम्मीदों के साथ संस्थान छोड़ दिया।

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

हम्म ...

इसलिए मेरे आश्चर्य की कल्पना करें जब स्टार्टअप में पहले कार्य दिवस पर मुझे कोई परीक्षण नहीं मिला। इंटरफ़ेस में कोई परीक्षण नहीं। बैकेंड में कोई परीक्षण नहीं। कोई परीक्षण नहीं।

हाँ। कोई बात नहीं। शून्य। NaN। परीक्षण एक घटना के रूप में गायब हैं।

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

लेकिन इसलिए नहीं कि लोग उन्हें लिखना नहीं जानते।

या तो उन्होंने कभी भी परीक्षणों की कमी से समस्याओं का अनुभव नहीं किया, या उन्होंने पुराने परीक्षणों की उपस्थिति से समस्याओं का अनुभव किया। दो चीजें जिनका मैंने कभी सामना नहीं किया।

मुझे आखिर समझ में क्या आया

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

किसी भी कंपनी के पास एक आदर्श तकनीकी स्थापना नहीं है । प्रत्येक कंपनी की समस्याएं हैं, प्रत्येक के पास एक तकनीकी ऋण है। सवाल यह है कि वे इसके साथ क्या करते हैं। नौकरी के लिए आवेदन करते समय, आपको स्पष्ट रूप से यह समझने की आवश्यकता है कि सब कुछ वहां क्रम में नहीं है, अन्यथा वे एक रिक्ति नहीं खोलते।

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

3. हम बाकी के पीछे हैं (उर्फ लाभ के सिंड्रोम का तकनीकी संस्करण)

यह इकाई परीक्षण के विषय से निकटता से संबंधित है। मेरी कंपनी ने परीक्षण नहीं किया, लेकिन, निश्चित रूप से, अन्य सभी कंपनियों ने उन्हें किया, है ना?

मैंने ब्लॉग पोस्टों का एक समूह पढ़ा। मैंने YouTube पर बहुत सारे सम्मेलन भाषण देखे। लानत है, मैं हर समय "उस नारंगी साइट" को पढ़ता हूं [शायद हैकर न्यूज का जिक्र करते हुए - लगभग। ट्रांस।]। हर कोई शानदार प्रदर्शन और ट्रेंडी एनिमेशन के साथ सुपर-परिष्कृत और उच्च-गुणवत्ता वाले ऐप लिख रहा है, जबकि मैं सिर्फ समय सीमा तक पकड़ने की कोशिश कर रहा हूं।

मैंने शाब्दिक रूप से उन सभी अन्य कंपनियों को आइडल किया, जिनके बारे में मैंने पढ़ा था, और इस बात से निराश था कि मेरी कंपनी और प्रोजेक्ट उनसे कितना पीछे रह गए।

मुझे आखिर समझ में क्या आया

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

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

4. कोड की गुणवत्ता बहुत महत्वपूर्ण है।

पुराने दिनों में, मैं एक बहुत कठिन कोड समीक्षा कर सकता था ।

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

अपने पुल अनुरोध में 50 से अधिक टिप्पणियाँ सबमिट करें जो आपके द्वारा याद किए गए सभी अर्धविरामों को सूचीबद्ध करता है!

क्योंकि मेरे पास चील की तरह आँखें हैं - और यह चील अपने सभी उच्च-गुणवत्ता वाले अर्धविरामों को प्राप्त करना चाहती है!

(सौभाग्य से, कंप्यूटर पर काम करने के कई वर्षों के बाद, एक ईगल की दृष्टि गायब हो गई है, इसलिए अब आपको चिंता करने की कोई बात नहीं है - # चुटकुले

मुझे आखिर समझ में क्या आया

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

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

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

5. सब कुछ प्रलेखित होना चाहिए !!!

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

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

तो, मैंने इस तथ्य से कैसे निपटा कि अपरिचित कोड की 300 लाइनों ने मुझे ऐसा महसूस कराया कि मैं डूब रहा हूं?

JSDOC। हर जगह।

मैंने समझदारी दिखाने की कोशिश के लिए सब कुछ टिप्पणी करना शुरू कर दिया। मेरे द्वारा प्राप्त की जाने वाली प्रत्येक सुविधा के लिए टिप्पणियां।

मैंने यह सब फैंसी कोणीय-विशिष्ट JSDoc सिंटैक्स सीखा। मेरा कोड हमेशा दो बार था क्योंकि इसमें बहुत सारे दस्तावेज और टिप्पणियां थीं।

मुझे आखिर समझ में क्या आया

प्रलेखन कभी-कभी झूठ होता है । यह सोचना आसान है कि प्रलेखन सभी मुद्दों को हल करता है। "हम डॉक्स की जरूरत है!" हालाँकि प्रलेखन कठिन काम है, इसे करने की आवश्यकता है। आपको सिर्फ सही चीजों का सही तरीके से दस्तावेज बनाना है। एक नियम के रूप में, अनावश्यक चीजों का अत्यधिक प्रलेखन, उन लोगों को रोकता है जो एक वास्तविक समस्या को हल करने की कोशिश कर रहे हैं।

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

6. तकनीकी ऋण खराब है

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

चूँकि मैंने किसी भी "अव्यवस्थित" कोड को तकनीकी कर्तव्य माना था, इसलिए मैंने तुरंत इसे पूरी गंभीरता के साथ खत्म करने की कोशिश की!

एक बार जब मैंने शाब्दिक रूप से 800 लाइनिंग त्रुटियों को सही करते हुए एक सप्ताहांत बिताया।

यही कारण है कि मैं एक विक्षिप्त था।

(डिस्क्लेमर: यह स्वचालित सुधार दिखाई देने से पहले था)।

मुझे आखिर समझ में क्या आया

असंगठित या गड़बड़ कोड तकनीकी कर्तव्य के समान नहीं है । बस अपूर्ण स्थिति का मतलब यह नहीं है कि यह एक तकनीकी कर्तव्य है। तकनीकी ऋण वास्तव में आपको किसी तरह से धीमा कर देता है, या कुछ प्रकार के परिवर्तनों को कठिन या त्रुटि प्रवण बनाता है। यदि कोड थोड़ा गड़बड़ है, तो यह सिर्फ थोड़ा गड़बड़ है। सफाई आपके समय के लायक नहीं हो सकती है।

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

7. एक प्रोग्रामर की स्थिति जितनी अधिक होगी, वह उतना ही बेहतर प्रोग्राम करेगा

काफी कम उम्र में प्रोग्रामिंग शुरू करने के बाद, मैं छोरों के लिए एक सच्चा पेशेवर बन गया, उन्हें 15 वर्षों में ऑटोमेटिज्म का सम्मान दिया। अपने आप में प्रोग्रामिंग मेरे लिए सांस लेने जैसा है। जब समाधान स्पष्ट होता है, तो मैं बस गैर-रोक कोड प्रिंट कर सकता हूं, जैसे ब्लॉग या ईमेल पर पाठ। मैं दूसरों की तुलना में तेजी से समाधान सांकेतिक शब्दों में बदलना कर सकते हैं, और आमतौर पर अधिक जटिल परियोजनाओं पर ले लिया।

लंबे समय तक, मुझे लगा कि मुख्य डेवलपर का सार है।

क्या सब कुछ एक साथ फिट होता है? आखिरकार, स्थिति को "लीड डेवलपर" कहा जाता है, न कि "लीड कम्युनिकेटर" या "लीड प्रोजेक्ट मैनेजर"। मुझे वास्तव में समझ नहीं आया कि वास्तव में "लीडर" बनने के लिए कितने और कौशल विकसित करने की आवश्यकता है।

मुझे आखिर समझ में क्या आया

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

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

कुछ क्षेत्रों में हम अभी भी जूनियर हैं । आपके पास कितना भी अनुभव क्यों न हो, हमेशा ऐसी जगहें होती हैं जहाँ आपको कम जानकारी होती है। किसी विशेष क्षेत्र में अपनी अक्षमता को पहचानना इस अंतर को भरने के लिए पहला कदम है और अधिक अनुभवी साथियों की मदद लेना है।

बोनस : मैं वास्तव में "एक अग्रणी प्रोग्रामर होने के नाते" लेख पसंद आया। बड़ी बात, अगर आप सोच रहे हैं कि इस काम का क्या मतलब है।