जूनियर पर वरिष्ठ के लिए छोटे सुझाव

नए लोग समय-समय पर गलत काम क्यों करते हैं? वे वरिष्ठ इंजीनियरों को क्यों नहीं समझते हैं? क्या यह हमेशा अनुभव की कमी के कारण होता है? और क्यों, समय-समय पर, रसोई में बातचीत के दौरान, वही नवागंतुक अपने लीड को "एम * बतख" कहते हैं?

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

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


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

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

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

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

अर्थात्, दूसरे शब्दों में, अच्छा कोड लिखने के लिए, और वास्तव में अच्छे विश्वास में किसी भी व्यवसाय को करने के लिए, आपको तीन नियमों का पालन करना चाहिए:
1. नर्वस न हों
2. जल्दी में नहीं
3. पता करें कि आपको क्या घेर रहा है

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

अब इस समस्या पर विचार करें कि परियोजना के पुराने समय के चेहरे: किसी कारण से, पुराने लोगों में से कुछ युवा डेवलपर्स को समझना या समझना नहीं चाहते हैं कि क्या हो रहा है। वे सवाल पूछना नहीं सिखाते, वे सरल नहीं समझाते, उनकी राय में, चीजें। वे यह नहीं बताते कि कैसे सोचा जाए और विचार की श्रृंखला कैसे बनाई जाए।
यह उनकी घातक गलती है - एक व्यक्ति को यह समझाने की आवश्यकता है कि यह कैसे करना है, क्या करना है, और बिल्कुल क्यों। यह कुछ ऐसा लगता है कि शुरुआत करने वाले को प्रक्रिया में खुद को सब कुछ मिलेगा। लेकिन वास्तविकता हमेशा उतनी ही दूर होती है, जितना कि उन्हें लगता है।
एक समस्या का सामना करते हुए, लोग साइकिल में जाना शुरू करते हैं, जो बताया या पूछा जा सकता है, उसके निर्णय पर समय बिताने के लिए। वे गलत सवाल पूछते हैं क्योंकि वे नहीं जानते कि अपने विचारों को सही तरीके से कैसे बनाया जाए । वे गलत काम करते हैं क्योंकि वे नहीं जानते कि वे क्या हासिल करना चाहते हैं।
और मुख्य समस्या यह है कि वे अपने तरीके से लीड के मामूली अस्पष्ट संकेत की व्याख्या करते हैं!
निराधार नहीं होने के लिए, मैं एक उदाहरण दूंगा जिसने हमें विकास के दस अतिरिक्त दिनों में काम में लिया। लीड ने असाइनमेंट के विवरण (कार्ड का असली पाठ) के साथ मध्य इंजीनियर को एक पत्र भेजा:
1. उपयोगकर्ता प्रवेश चालान दृश्य को पढ़ने के लिए उपयोग के साथ
2. व्यवस्थापक को इनवॉयस दृश्य के लिए उपयोगकर्ता तक पहुंच हटा दें
3. चालान दृश्य के साथ उपयोगकर्ता ताज़ा पृष्ठ
4. उपयोगकर्ता के पास अभी भी चालान दृश्य तक पहुंच है
5. उपयोगकर्ता सिस्टम को पुनः लोड करता है
6. उपयोगकर्ता चालान दृश्य तक पहुँच नहीं है

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

सारांशित करते हुए, मैं दोहराता हूं: यदि आपको नए लोगों को "गाइड" करने की आवश्यकता है, तो पहले दिन से उन्हें बताएं और समझाएं कि सॉफ्टवेयर इंजीनियर के रूप में कैरियर के आगे विकास के लिए उन्हें चार नियमों का पालन करने के लिए सीखने की अत्यधिक अनुशंसा की जाती है:
1. नर्वस न हों
2. जल्दी मत करो
3. पता करें कि आपको क्या घेर रहा है
4. अपने विचारों की अस्पष्ट भाषा से बचें