कैसे मैंने नफरत करना बंद कर दिया और विकास से प्यार हो गया

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


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

त्याग

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

अत्यधिक जटिलता

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

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

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

बहुत ज्यादा और साक्षात्कार

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

हर बार जब मैं साक्षात्कार से दर्द की एक और कहानी पढ़ता हूं "वे ईएस 6 में परिवर्तनों की पूरी सूची जानना चाहते हैं," मैं दुखी हूं। वे केवल एक ही बात जानना चाहते हैं: क्या आप उनकी टीम के अनुरूप होंगे। और "वे" हम हैं, केवल मेज के दूसरी तरफ हैं। हम नहीं जानते कि कैसे पूछना है, और पता नहीं कैसे जवाब देना है।

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

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

आईटी के लोग

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

स्वीकार करें: लोग अलग हैं। यदि आपको लोगों की ज़रूरत है - "अपने" की तलाश करें।

संभवतः प्रबंधकों के साथ घृणा की अधिकतम मात्रा जुड़ी हुई है। और यहाँ हम फिर से एक दुष्चक्र में हैं: प्रबंधक अपना काम नहीं करना चाहता है या नहीं कर सकता है - और इसलिए हम उससे दूर हो जाते हैं और खुद सब कुछ करते हैं। वह वैसे भी बेकार है। इस सवाल में चला जाता है

व्यापार

बिजनेस के साथ टेक्नोलॉजी के युद्ध के मैदान में कई प्रतियाँ टूटी हैं। मुझे खुद को दोहराने का मन नहीं है, इसलिए मैं संदर्भ के एक बड़े टुकड़े को छोड़ देता हूं और सीधे मुख्य बिंदु पर जाता हूं।

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

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


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

अपने बारे में

20 साल की उम्र में, मैं दिनों के लिए कोडिंग कर रहा था और खुशी-खुशी काम पर चला गया।
25 साल की उम्र में, मैंने देखा कि सब कुछ कितना खराब था और पीड़ित था, शुक्रवार और एक पालतू परियोजना की उम्मीद थी जिसमें सब कुछ ठीक है।
30 साल की उम्र में, मैं काम के बारे में भावुक हूं ... शुक्रवार और सप्ताहांत में खुशी-खुशी मिल रहा हूं।

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

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

किसी ने भी अब तक नहीं कहा है, हालांकि मैं कभी-कभी कुछ सहयोगियों को इस कोने में चलाता हूं :)