क्या अधिक महत्वपूर्ण है: एक प्रोग्रामिंग भाषा जानने के लिए या एक व्यावसायिक समस्या को हल करने में सक्षम होने के लिए?

विकास के क्षेत्र में करियर बनाने के लिए एक प्रोग्रामिंग भाषा सीखने लायक क्या है, इस पर बहुत बहस है। लेकिन मुझे इस बात का गहरा यकीन है कि ज्ञान के आवश्यक सेट की भाषा सीमित नहीं है। दुर्भाग्य से, हर कोई इसे नहीं समझता है।



कार्यों की चर्चा में, व्यवसाय और डेवलपर्स विभिन्न भाषाएं बोलते हैं।

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

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

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

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

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

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

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

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

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

व्यापार के मुद्दों की बेहतर समझ के लिए एक छोटे से अतिरिक्त के रूप में, मैं उद्योग-विशिष्ट सम्मेलनों में भाग लेने की सलाह देता हूं। वहां, वक्ताओं ने अपने अनुभवों को साझा किया कि कैसे उन्होंने आईटी प्रौद्योगिकी का उपयोग करके एक व्यावसायिक समस्या को हल किया। अक्सर वहां से आपको उपयोगी जानकारी मिल सकती है कि किस दिशा में जाना है। हालांकि, ज़ाहिर है, किसी को भी विस्तार से दूसरों के अनुभव को दोहराने की आवश्यकता नहीं है।

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

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

आप इस बारे में क्या सोचते हैं?

लेख लेखक: सर्गेई मरीना

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