वरिष्ठ प्रोग्रामर का पुनः विश्वास हासिल करना [बंद]


21

मेरे बॉस को पता चला कि मैं उतना स्मार्ट नहीं हूँ जितना उसने सोचा था।

मेरे अनुभव से एक उदाहरण:

मैं एक जूनियर प्रोग्रामर हूं, और मैं दो, मेरे बॉस (वरिष्ठ प्रोग्रामर) और खुद की टीम में काम करता हूं।

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

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

इस उदाहरण को देखते हुए मेरा प्रश्न यह है:

यदि आपका एक वरिष्ठ प्रोग्रामर और अपने जूनियर प्रोग्रामर की क्षमता में विश्वास खो चुका है, तो आत्मविश्वास वापस पाने के लिए आप अपने जूनियर से क्या देखना चाहेंगे?

संपादित करें : महान जवाब और सहायक प्रतिक्रिया के लिए आप सभी को धन्यवाद!


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

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

5
@ jmort253, नहीं, लेकिन वह कुछ नया सीखने के लिए परेशान था।
fbynite

17
लाल झंडा! ® ... वह कुछ नया सीखने के बारे में परेशान था। मैं 1973 से इस खेल में हूं और मुझे लगता है कि मुझे हर महीने औसतन एक नई तकनीक और / या टूल सीखना होगा । मैं मूल रूप से एक सर्वर आदमी हूं, लेकिन पिछले 3 महीनों में मुझे पूरी तरह से पुनर्विचार करना पड़ा है कि मैं बूटस्ट्रैप, एन्यो, और "सिंगल पेज ऐप" फ्रेमवर्क जैसी परियोजनाओं के कारण जेएस को कैसे आगे बढ़ाता हूं, और यह प्रभावित करता है कि मैं कैसे सोचता हूं सर्वर उनका समर्थन करता है।
पीटर रोवेल

3
आपने यहां अच्छा किया है, लेकिन आपको सिर्फ "बैकबोन.जेएस" विकसित करने की आवश्यकता है। कुछ "वरिष्ठ" प्रोग्रामर क्या सोचते हैं, इसके बारे में देखभाल करना बंद करें।
काज

जवाबों:


27

यदि वह आपके द्वारा निर्मित उत्पाद को पसंद करता है, लेकिन आपके बैकबोन के उपयोग पर अटक गया है, तो आप दोनों को वांछित तकनीक स्टैक के बारे में बातचीत करने की आवश्यकता है।

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

तथ्य यह है कि उन्होंने शुरुआत में उत्पाद का आनंद लिया था यह पर्याप्त सबूत है कि आपने अच्छा किया और पर्याप्त "स्मार्ट" हैं।

tl; dr तुमने अच्छा किया। अपने वरिष्ठ से बात करें और देखें कि वह आपसे क्या अपेक्षा करता है।


15

वह मुझे बहुत "वरिष्ठ" नहीं लगता है कि इस तरह से एक स्नैप निर्णय कॉल करें। मैं हमेशा "स्क्वायर व्हील को फिर से लागू करें" विरोधी पैटर्न के बजाय एक उचित ढांचे का उपयोग करता हूं। यदि वह वास्तव में वरिष्ठ होता तो वह एक अच्छे ढांचे के मूल्य को समझता और जानता होता। सबसे अच्छा मैं उनसे एक और MVC जावास्क्रिप्ट ढांचे पर Backbone.js पसंद पर सवाल करना चाहूंगा और इस प्रक्रिया में बहुत पहले। वह एक कनिष्ठ के रूप में आप पर ठीक से सलाह लेने और जाँच करने में विफल रहा और उचित विकास पथ (उसके दिमाग में) के साथ आपकी मदद करता है।

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


5

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

अपने प्रश्न का उत्तर देने के लिए कि मैं एक वरिष्ठ के रूप में क्या देखना चाहूंगा:

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

पुनश्च: मुझे यह उल्लेख करना चाहिए कि मैं एक वरिष्ठ हूँ जो पेशेवर स्तर पर गलत साबित होना पसंद करता है क्योंकि यह मुझे कुछ नया सीखने का अवसर देता है। और मुझे यह जानकर अच्छा लगता है कि मेरी टीम के अन्य लोग किस तरह से चीजें करते हैं ताकि स्प्रिंट / टास्क के अंत में कोई कम / आश्चर्य न हो।


अच्छा जवाब है, लेकिन आपने उल्लेख नहीं किया कि वह विकास का नेतृत्व करने में असफल रहा (कोई कोड समीक्षा नहीं?)
B butовић

@ B @овиЈ - धन्यवाद। - मैंने इसलिए नहीं किया क्योंकि मेरा मानना ​​है कि सिर्फ सीनियर होने से ही आप एक्टिंग नहीं करते। यदि कोई जूनियर विकास में कुछ 'नेतृत्व' की उम्मीद करता है, या इसकी कमी को नोटिस करता है, तो उन्हें इसे वरिष्ठ के ध्यान में लाना चाहिए। यदि वरिष्ठ तब 'नेतृत्व' प्रदान नहीं करने का निर्णय लेते हैं तो वे उस पद और वेतन के लायक नहीं हैं जो उन्हें दिया गया है। : पी
डेविड 'गंजा अदरक'

3

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

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

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

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

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


3

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

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

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

तीसरा, जब वे अपने सिर को पॉप में देखते हैं कि आप कैसे कर रहे हैं, तो उन्हें अपने कोड को देखे बिना न जाने दें।

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


2

आपको बल्ले से सही पता लगाने की ज़रूरत है कि क्या वह निराश है क्योंकि आप अपनी पसंद के ढांचे का व्यापक बचाव नहीं कर सकते हैं, या यदि आप एक रूपरेखा का उपयोग करते हैं तो।

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

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

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

सिर्फ इसलिए कि वह वरिष्ठ प्रोग्रामर है वह उसे अचूक नहीं बनाता है।


2

आपके अनुवर्ती टिप्पणी ने कहा कि बॉस परेशान है कि उसे कुछ नया सीखना है ...।

जब तक इसमें और कुछ भी नहीं है जिसका आपने उल्लेख नहीं किया है, मुझे HIM पर गुस्सा आ रहा है।

नई तकनीकों को सीखना हमारी नौकरी का एक बड़ा हिस्सा है और प्रत्येक टीम को सीखने और आत्म सुधार को गले लगाना चाहिए।

लेकिन, प्रबंधन के पास चिंता करने के लिए अन्य चीजें हैं। उनके पास मिलने की समय सीमा है, उनके पास सीमित या कोई प्रशिक्षण बजट नहीं है।

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

और अब पिछले BUT पर एक BUT ....... यह आपके बॉस की गलती है। यदि आप नए और जूनियर हैं, तो उसे कम से कम कुछ मार्गदर्शन देना चाहिए। कुछ हद तक, आप तकनीक पर मार्गदर्शन के साथ-साथ उपयोग करने के लिए कह सकते थे।


2

यदि आप एक वरिष्ठ प्रोग्रामर हैं और अपने जूनियर प्रोग्रामर की क्षमता में विश्वास खो चुके हैं, तो आत्मविश्वास वापस पाने के लिए आप अपने जूनियर से क्या देखना चाहेंगे?

यह देखते हुए कि आपने कहा है कि वह आपके द्वारा उपयोग किए गए ढांचे का उपयोग करना नहीं सीखना चाहता, मुझे लगता है कि प्रश्न यह होना चाहिए: " यदि आप एक वरिष्ठ प्रोग्रामर हैं और आपने अपने सीखने की क्षमता खो दी है जूनियर प्रोग्रामर, आपको खुद को छाँटने के लिए क्या करना चाहिए? "

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

अपने वरिष्ठ डेवलपर पर वापस जाएं। आपने कहा " वह कुछ नया सीखने के बारे में परेशान था ", और मेरी राय में वह कुछ बहुत ज़ोर से बजने वाली खतरे की घंटी है।

मैं हमेशा सीख रहा हूं। जबकि मैं वास्तव में अपने नियोक्ता को हर साल अपना शिक्षा बिल लेने के लिए पसंद करता हूं, यह दुर्लभ है कि वे कुछ भी खर्च करते हैं जो मुझे लगता है कि मुझे वास्तव में ज़रूरत है, फिर भी मुझे पता है कि मुझे रोजगार योग्य रहना चाहिए इसलिए मैं £ 2000 के क्षेत्र में कहीं खर्च करता हूं हर साल मेरी खुद की शिक्षा पर GBP (लगभग $ 3000 USD)।

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.