अपने CTO के लिए उचित उम्मीदें

मैं आपका नया सीटीओ हूं।

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

क्या हम पेशेवर हैं?

यह मुख्य प्रश्न है। मैं आपको बताऊंगा कि मैं आपसे क्या उम्मीद करता हूं, और यह इस सवाल का जवाब निर्धारित करेगा कि क्या हम पेशेवर हैं।

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

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

मैं उम्मीद करता हूं

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

मुझे उम्मीद है कि हम हमेशा तैयार रहेंगे।

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

स्थिर प्रदर्शन

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

मुझे सस्ता अनुकूलन चाहिए।

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

निर्भीक क्षमता

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

चरम गुणवत्ता

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

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

हम क्यूए को दोष नहीं देंगे

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

स्वचालन

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

कोई नाजुकता नहीं

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

हम एक दूसरे का समर्थन करते हैं

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

समय का ईमानदार अनुमान

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

कहो ना

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

आक्रामक प्रशिक्षण जारी है

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

tutorship

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

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

आपका ध्यान देने के लिए धन्यवाद।