"जूनियर प्रोग्रामर" होने का वास्तव में क्या मतलब है

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

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

मुझे 80% यकीन था कि मुझे यह पोस्ट उस ईमेल को पढ़ने के बाद लिखनी चाहिए। 15% ने मुझे इसका , यह और यह पढ़ने का मौका दिया। पिछले 5% मुझे इसे पढ़ने के बाद प्राप्त हुआ।

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

एक औपचारिक परिभाषा देने के बजाय, मैं कुछ उदाहरण प्रस्तुत करूंगा जिनसे आप इस अर्थ का अर्थ निकाल सकते हैं। खैर ... चलाई।

मेरे दोस्त के लिए अस्वीकरण : मैं अब भी तुमसे प्यार करता हूं, दोस्त। [:)]।

बुद्धिमान पुरुष

मैं शर्त लगाता हूं कि हम में से 98% जूनियर डेवलपर्स वैसे भी इस चरण से गुजरते हैं। इसे बेहतर ढंग से समझाने के लिए, मैं एक काल्पनिक चरित्र - जैक का उपयोग करता हूं।

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

अरे हाँ, वैसे, जैक को Node.js, Java, Haxe, ooc जैसे विभिन्न प्लेटफार्मों के बारे में सब कुछ का एक टन पता है, और यहां तक ​​कि एक जिसे आपने कल रात अपने निजी GitHub रिपॉजिटरी में जोड़ा था। मेरा विश्वास करो, वह यह सब जानता है। OMG! मैं कैसे भूल सकता था? जैक असेंबली लैंग्वेज में भी प्रोग्राम करते हैं।

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

अनुभवी

“जो एक दिन उड़ना सीखेगा, उसे पहले चलना और दौड़ना और चढ़ना और नृत्य करना सीखना होगा; एक उड़ान में नहीं जा सकता है ”(सरल से कठिन तक जाओ) - फ्रेडरिक विल्हेम नीत्शे

महान दार्शनिक और कवि, फ्रेडरिक विल्हेम नीत्शे की अद्भुत अभिव्यक्ति।

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

अस्वीकरण : मैं अभी भी सीख रहा हूँ और यह सब करने की आदत है। मैं किसी भी तरह से इस बात की पुष्टि नहीं करता हूं कि यह सब मुझ पर भी लागू नहीं होता है।

भावनाओं

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

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

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

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

उपयोगी पढ़ना: नियम नंबर एक प्रोग्रामर - भावनाओं को दहलीज के पीछे छोड़ दें

डिजाइन और प्रक्रिया

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

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

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

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

अब मेरे पास यह सीखने का अवसर है कि प्रक्रिया को सही तरीके से कैसे बनाया जाए।

By और बड़े, déjà vu एक विशेषज्ञ हैं और बड़े और jamais vu एक विशेषज्ञ हैं।

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

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

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

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

तो क्या मतलब है, जोनाथन, कह "द्वारा और बड़े, déjà वु विशेषज्ञ।" मैं सच्चे विशेषज्ञों की बात कर रहा हूं। उनकी क्षमता केवल एक या दो क्षेत्रों तक बढ़ सकती है, लेकिन उन्होंने इन क्षेत्रों में बहुत सी चीजों को पहले ही देखा है। वे स्केलेबल सिस्टम बना सकते हैं, उन्हें पारिस्थितिकी तंत्र की गहरी समझ है, वे शॉर्टकट जानते हैं जो आपदा की ओर ले जाते हैं, वे जानते हैं कि अनुकूलन कब लागू करना है, आदि। वाह! "स्केलेबल सिस्टम" ... यह किस तरह की चीज है? आप देखते हैं, सौभाग्य से , इस समय, हम (कनिष्ठ डेवलपर्स) "समग्र, जमैका विशेषज्ञ" की श्रेणी में आते हैं। हम विशेषज्ञ हो सकते हैं (आप पर ध्यान दें, यह पर्याप्त नहीं है " सच ") विभिन्न चीजों में, हम यह जान सकते हैं कि सिस्टम कैसे बनाया जाए, हमारे पास पारिस्थितिकी तंत्र के बारे में एक अवधारणा हो सकती है, हम बहुत सारे शॉर्टकट जान सकते हैं, लेकिन हमें (वास्तव में) कोई सिस्टम नहीं है कि हम सिस्टम को कैसे स्केल करें हम बनाते हैं, पारिस्थितिक तंत्र की हमारी समझ बहुत सतही है, हमारे द्वारा चुने गए शॉर्टकट अनिवार्य रूप से अनावश्यक हैं, और हम समय से पहले अनुकूलन पर बहुत समय बिताते हैं।

लोग, क्यों भीड़?

भीड़ की कोई जरूरत नहीं है।

मैं अपने बुकमार्क में से एक लेख को कभी नहीं हटाऊंगा , " 10 साल में खुद को प्रोग्राम करना सिखाएं " , अद्भुत पीटर नॉरविग द्वारा लिखा गया था।

यदि आपने इसे अभी तक नहीं पढ़ा है, तो अपने आप को Mott के प्राकृतिक 100% Apple जूस का एक गिलास डालें (क्योंकि यह आपके लिए उपयोगी होगा और चूंकि यह वही है जो मैं अब खुद पी रहा हूं ... [; p]), टीवी बंद करें, इसे अपने भाई के सिर पर क्रैक करें (ठीक है ... मैंने ऐसा कभी नहीं कहा), ऊपर दिए गए लिंक का पालन करें और ध्यान से सब कुछ पढ़ें।

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

खैर ... बस इतना ही। अंत।

अनुवाद टॉल्स्टॉय समर कैंप और मेटाबेता स्टार्टअप स्कूल के हिस्से के रूप में किया गया था।