विश्वविद्यालय में, मुझे कोडिंग बहुत पसंद थी। अब यह एक रूटीन बन गया है। पूर्व फ्यूज पर कैसे लौटें?

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

“यदि आप आगे नहीं बढ़ते हैं, तो आप स्थिर नहीं रहते हैं। दुनिया आगे बढ़ रही है, लेकिन आप नहीं हैं। इस प्रकार, आप वापस जा रहे हैं! " © (कोई बहुत चालाक है)

सूक्ति

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

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

गहरा आंदोलन

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

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

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

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

जाहिर है, किसी भी सॉफ्टवेयर उत्पाद पूरी टीम के काम का परिणाम है, लेकिन परियोजना में मेरी भागीदारी के स्तर के साथ, मैंने व्यक्तिगत घटकों को नहीं, बल्कि पूरे उत्पाद को बनाने में शामिल महसूस किया। उसी समय, आपको अविश्वसनीय ड्राइव मिलती है, और भी अधिक जिम्मेदारी होती है।

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

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

वैसे, वर्कफ़्लो के संगठन के बारे में एक और टिप्पणी है, जिसका पालन विशेष रूप से, DevOps दर्शन और SRE के रूप में ज्ञात विकास और संचालन के दृष्टिकोण से किया जाता है, जो मूल रूप से Google से आया था। विकास, कार्यान्वयन और समर्थन टीमों, सहयोग की दिशा में आंदोलन के बीच अलगाव को खत्म करने का प्रयास करना आवश्यक है।

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

बग़ल में आंदोलन

कई मायनों में, प्रोग्रामर की अपने काम में रुचि उस विषय क्षेत्र में उसकी रुचि से निर्धारित होती है जिसमें वह काम करता है। उदाहरण के लिए, आप वित्तीय अनुप्रयोगों से ऊब सकते हैं, लेकिन ऐसे अनुप्रयोगों के लिए बुनियादी ढांचे पर काम करना दिलचस्प होगा।

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

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

चौड़ाई में आंदोलन

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

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

हमेशा की तरह, मैंने Google से शुरुआत की। मुझे जोएल स्पोल्स्की के कई लेख मिले, उन्हें निगल लिया, जिन पुस्तकों का उन्होंने उल्लेख किया, उन्हें पढ़ा, फिर इन पुस्तकों के लिंक, अधिक व्यवस्थित रूप से अध्ययन करने के लिए गए, और इसलिए, धीरे-धीरे, एक नए विषय क्षेत्र में गोता लगाने लगे - परियोजना प्रबंधन, टीम, विकास प्रक्रिया का प्रबंधन।

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

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

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

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

निष्कर्ष

अभ्यास से पता चलता है कि यदि आप सक्रिय रूप से उपरोक्त निर्देशों में से कम से कम एक में चलना शुरू करते हैं, तो कुछ समय बाद एक और आंदोलन अनिवार्य रूप से होगा - पदानुक्रमित सीढ़ी। अगर ऐसी कोई इच्छा है, तो यह भी एक बहुत ही दिलचस्प विकल्प है। यहां मुख्य बात यह है कि संगठनात्मक और तकनीकी कार्यों के बीच आवश्यक संतुलन के बारे में नहीं भूलना है जिसे आप बनाए रखना चाहते हैं।

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

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

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

कुछ अच्छी किताबें, बहुत सी इच्छा और थोड़ी सी हलचल सभी एक बड़ा बदलाव ला सकती है। सौभाग्य है

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