प्रमुख डेवलपर कैसे बनें। भाग २

अग्रणी डेवलपर्स के व्यक्तिगत गुणों के बारे में जॉन ऑलसॉ द्वारा एक लेख का निरंतर अनुवाद ।

परिपक्व डेवलपर्स केवल शिकायत नहीं करते हैं

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

परिपक्व डेवलपर्स अपने निर्णयों और निर्णयों में खुले तौर पर समझौता करते हैं

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

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

इस तरह के समझौतों के बारे में बहुत सारे लेकोनिक कथन हैं, और परिपक्व डेवलपर्स जानते हैं कि यह हमेशा इन दार्शनिक बातों पर भरोसा करने के लायक नहीं है (यह बात मेरे शब्दों पर भी लागू होती है):

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

संक्षेप में, व्यापार-नापसंद पर: हर कोई कोनों में कटौती करता है, किसी भी परियोजना में [और इस अनुवाद में :) मैं किसी भी सुधार पर खुश हूं!] । अपरिपक्व डेवलपर्स के लिए, यह घृणित है, और जानबूझकर परिपक्व, परियोजना की शुरुआत में, ऐसे कोणों को नामित करते हैं, उन्हें अनुमति देते हैं और इसे एक अच्छे डिजाइन का हिस्सा मानते हैं।

(उसी के लिए: आपका कोड सुरुचिपूर्ण हो सकता है, लेकिन मेरा, कुतिया, काम करता है )

परिपक्व इंजीनियर खुद को बाड़ नहीं देते हैं

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

आत्म-उत्थान का एक उदाहरण: “यह मेरी गलती नहीं है कि सब कुछ उनके साथ टूट गया। उन्होंने कुछ गलत किया है। मेरे पास विनिर्देश के अनुसार सब कुछ है, और अगर इसमें त्रुटियां थीं, तो मुझे इससे कोई लेना-देना नहीं है। ”

परिपक्व डेवलपर्स सहानुभूति कर सकते हैं

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

इंजीनियरिंग में, संघर्ष की स्थितियों से बचा नहीं जा सकता है, और उनके साथ असंतोष, उन्हें सफलता के घटक के रूप में स्वीकार करने के बजाय, अपरिपक्व डेवलपर का संकेत है।

परिपक्व डेवलपर्स मानसिक जाल के बारे में जानते हैं

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

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

विकिपीडिया में जाल की एक विस्तृत सूची है । डेवलपर्स मुख्य रूप से निम्नलिखित से प्रभावित होते हैं:

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

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

प्रतिरूपण प्रोग्रामिंग की दस आज्ञाएँ

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

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

शुरुआत से विशेषज्ञ तक

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

नवागंतुक

• नियमों का पालन;
• स्थिति की संकीर्ण धारणा;
• निर्णय की कमी (या उनकी सीमाएँ)।

उन्नत शुरुआत

• उचित रूप में नियमों की व्याख्या;
• स्थिति की सीमित धारणा।

सक्षम

• जानबूझकर योजना बना;
• मानक, परिचित कार्य।

विशेषज्ञ

• एक पूरे के रूप में स्थिति की धारणा, और अलग-अलग पहलुओं के एक सेट के रूप में नहीं;
• सामान्य मॉडल से विचलन के बारे में जागरूकता;
• संदर्भ-संवेदी सिद्धांतों का उपयोग।

विशेषज्ञ

• नियमों पर भरोसा नहीं करता;
• स्थिति के बारे में सहज जागरूकता;
• विश्लेषणात्मक दृष्टिकोण का उपयोग केवल नई स्थितियों में किया जाता है।

रिपोर्ट कहती है:

शुरुआती नियमों और ज्ञान के आधार पर कार्य करते हैं। वे सब कुछ सोचते और विश्लेषण करते हैं, इसलिए वे धीरे-धीरे काम करते हैं, निर्णय लेते हैं और निर्णय लेते हैं।

(यानी, newbies निजी कानूनों पर अत्यधिक निर्भर हैं)

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

(अर्थात विशेषज्ञ परिस्थितियों के अनुसार कार्य करते हैं)

मैं स्तरों के ऐसे स्पष्ट पृथक्करण से बिल्कुल सहमत नहीं हूँ। यह मुझे लगता है, वास्तव में, सब कुछ कुछ अधिक धुंधला है। लेकिन, फिर भी, इस तरह के एक सरलीकृत वर्गीकरण भी उपयोगी हो सकता है।

अनुवादक से: मैं एन। एन। नेप्येवोडा "ज्ञान और कौशल के स्तर" से इंटरनेट पर एक दिलचस्प काम नहीं पा सकता, अगर कोई भी इसे पाता है, तो कृपया टिप्पणियों में पोस्ट करें।

सनसनी: परिपक्व डेवलपर्स मानवीय भावनाओं के महत्व से अवगत हैं। (यकीन नहीं होता!)

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

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

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

उदाहरण के तौर पर कि कैसे लोग निर्णय लेते हैं, कुछ के बारे में कुछ होलीवर पढ़ते हैं।

"यह आश्चर्यजनक है कि आप क्या हासिल कर सकते हैं यदि आप योग्यता के बारे में नहीं सोचते हैं"

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

यह विचार हमें स्वतंत्र कर देगा, और जैसे ही हर कोई इसे समझता है और इसे आत्मसात करता है, प्रगति और उन्नत सोच की दुनिया पनपती है, इंजीनियरों को व्यक्तिगत कैरियर की सफलता के साथ अपने काम की बराबरी करने की चिंता नहीं होगी।

यह अंत नहीं है

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

अनुवाद करने में उनकी मदद के लिए सरोगा और रेनैट का धन्यवाद। मेरे आकाओं, एंड्री और सर्गेई के लिए धन्यवाद, जो हर दिन मुझे दिखाते हैं कि "लीडर" और एक होने का क्या मतलब है।