लिडा किस बारे में चुप है: एक डेवलपर के करियर की शुरुआत। सिद्धांत या कैसे एक Middl बनने के लिए

नमस्ते! प्रोग्रामिंग एक जटिल विषय है, और औद्योगिक सॉफ्टवेयर विकास बहुत जटिल है। हमारे आईटी उद्योग में, "मैं कैसे विकसित होऊं?" श्रृंखला में कनिष्ठ सहयोगियों से प्रश्न सुनना इतना दुर्लभ नहीं है, "मुझे उच्च-स्तरीय पेशेवर बनने के लिए और जितनी जल्दी हो सके क्या करना चाहिए?", "मुझे क्या करना चाहिए अगर मैं विकसित कर सकता हूं, लेकिन क्या करूं?" कोई दिलचस्प परियोजनाएं नहीं हैं? ”,“ मध्य को क्या जानना चाहिए? ”। यदि आपके पास आईटी में 0 से 3 साल का अनुभव है, तो आप एक शुरुआती विशेषज्ञ हैं (या बस एक बनने के लिए) और पेशेवर और कैरियर विकास के लिए समान लक्ष्य निर्धारित करते हैं, इन लक्ष्यों को प्राप्त करने के लिए सही तरीके की तलाश कर रहे हैं - यह पोस्ट आपके लिए अच्छा है बिल्ली के नीचे शिकायत। शायद वह टीम के नेताओं और प्रबंधकों के लिए भी रुचि रखते हैं, सामान्य तौर पर, विशेषज्ञों के प्रशिक्षण और विकास में शामिल सभी लोगों के लिए।

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

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

1. ब्रॉड बनाम संकीर्ण विशेषज्ञता

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

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

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

2. कार्यात्मक क्षेत्र

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

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

3. मानसिक और स्वाध्याय

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

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

कुल: एक नौकरी की तलाश करें जहां ऐसे लोग हों जो विषय को जानते हों और आपको इसे बेहतर बनाने में रुचि रखते हों! यह आपको काफी कम समय में अपनी विशेषज्ञता के स्तर को बढ़ाने की अनुमति देगा। उन जगहों से बचें जहां आप ज्ञान साझा करने के लिए बिल्कुल भी तैयार नहीं हैं। ऐसी जगह में 4 साल का काम दूसरे में दो (या उससे कम) के बराबर होगा।

4. चांदी की गोली नहीं है

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

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

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

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

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

5. बड़ी और छोटी कंपनियों के बारे में, आईटी के बारे में और आईटी के बारे में नहीं

कई युवा पेशेवर उन कंपनियों के लिए काम करना चाहते हैं जिनके बारे में उन्होंने सुना है और जिनके उत्पादों या उत्पादों का उन्होंने इस्तेमाल किया है। कुछ ऐप्पल, Google या Microsoft में (हाल ही में एक अच्छा शब्द सामने आया है - "गाइंडबुक") या उनके रूसी समकक्षों (जितना संभव हो)। एक बड़ी कंपनी में कैरियर शुरू करना एक बहुत ही मूल्यवान अनुभव है। (आप इसे इस अनुभव के 11 वें वर्ष में विशेष रूप से समझते हैं :)) यह देखने के लिए कि एक बड़ी कंपनी अंदर से कैसे काम करती है और इसमें कैसे प्रक्रियाएं आयोजित की जाती हैं - मेरा विश्वास करो, यह इसके लायक है। संभवतः, मेरे लिए एक बड़ी आईटी कंपनी के सेट और अपने करियर की शुरुआत में एक बुद्धिमान टीम से बेहतर कुछ कल्पना करना मुश्किल है। हालाँकि, हमेशा BUT होते हैं।

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

6. खाद्य और आउटसोर्सिंग कंपनियां

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

मैं जवाब दूंगा: नहीं। इतना सरल नहीं है।

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

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

7. vs

. : . , . , , . , – . , ( ) , . , , , . , . , , () () . . ? – . – . , , 2 : ) ) ( ). : , . , . , , , , , . – .

: - ( - ) , - . - , ( — , ) – .

8.

. , , - . - , . , , , . . . , . , . — . .

— , , , , . , , , , ( ), : , — , , .
? , ? .

, ? : , , , , , , , .

9.

(, ) , backend . (, Web , ). - . , ? , . , . , — . — . , . : , , . . , . , , . . , : , , UX/UI — , , , , .

10.

: . . - : , .

, , . : 1.5-2 . , , , , . . , 1-2 , - . — 4 , ? : , B. , . , , . , . , , — , , . , , , , .

: 1-3 , , . : skills 3 — 1. , — 2. — 3. , , , , 4 , , .

निष्कर्ष

— , , . , . , , — . . , , ! , : ) hard skills ) c ) . , !

PS: . , , , .