एक जूनियर को कैसे सही करें, लेकिन उसे खुद के लिए सोचने के लिए प्रोत्साहित करें? [बन्द है]


54

मैं एक छोटी टीम का नेतृत्व कर रहा हूं, जहां हर किसी को एक साल से कम का सॉफ्टवेयर विकास का अनुभव है। मैं किसी भी तरह से अपने आप को सॉफ्टवेयर गुरु नहीं कहूंगा, लेकिन मैंने कुछ वर्षों में कुछ चीजें सीखी हैं जो मैं सॉफ्टवेयर लिख रहा हूं।

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

हालांकि वे शायद ही कभी असहमत हैं या क्यों पूछते हैं। और हाल ही में मैं अधिक स्पष्ट संकेत दे रहा हूं कि वे मेरे बयानों पर आंख मूंदकर सहमत हैं और अपनी राय नहीं बना रहे हैं।

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

संपादित करें: यहां इन स्पष्ट संकेतों में से एक का उदाहरण दिया गया है कि वे अपनी राय नहीं बना रहे हैं:

Me: मुझे एक्सटेंशन विधि बनाने का आपका विचार पसंद है, लेकिन मुझे यह पसंद नहीं है कि आपने एक बड़े जटिल लैम्बडा को एक पैरामीटर के रूप में कैसे पारित किया। लैम्बडा दूसरों को विधि के कार्यान्वयन के बारे में बहुत अधिक जानने के लिए मजबूर करता है।

जूनियर (मुझे गलत समझने के बाद): हां, मैं पूरी तरह से सहमत हूं। हमें यहां एक्सटेंशन विधियों का उपयोग नहीं करना चाहिए क्योंकि वे अन्य डेवलपर्स को कार्यान्वयन के बारे में बहुत अधिक जानने के लिए मजबूर करते हैं।

एक गलतफहमी थी, और इससे निपटा गया है। लेकिन उनके बयान में तर्क का एक भी हिस्सा नहीं था! उसने सोचा कि वह मेरे तर्क को मेरे पास वापस कर रहा है, यह सोचकर कि जब वह ऐसा कह रहा था तो उसका कोई सुराग नहीं था।


संबं धत
ल ं क

4
मैं en.wikipedia.org/wiki/Siscal_method का उपयोग करके यह सुनिश्चित करूँगा कि यह केवल प्रोग्रामिंग से संबंधित नहीं है
jk।

10
इस सवाल को बंद करने के बारे में: जबकि यह केवल पहलू नहीं हो सकता है - मुझे लगता है कि यह कुछ ऐसे लोगों का सामना करना है। यह एक वास्तविक प्रश्न है। मैं इसे खुला रखने के लिए दृढ़ता से वोट देता हूं।
दीपन मेहता

3
शायद अधिक प्रासंगिक सवाल: "आप अपने वरिष्ठ को कैसे ठीक करते हैं?"
विलियम पर्ससेल

2
@WilliamPursell अच्छा लगा। अगर वे मुझे ठीक करते तो मुझे अच्छा लगेगा।
फिल

जवाबों:


37

संक्षिप्त जवाब:

उन्हें संलग्न करें (उनके दिमाग में पहेली डालें), उन्हें सशक्त बनाएं (उनके उत्तरों पर भरोसा करें)।


यह सवाल है जो हमें ड्राइव करता है! - आव्यूह।

आम तौर पर, मेरी टिप्पणियों में, जूनियर्स की अपनी दुनिया है - उनका खुद का सीमित दृष्टिकोण है कि वे कैसे सोचते हैं और किसी हिस्से में चीजों के बारे में उनका अपना उत्साह / पसंदीदा / राय है।

उन्हें गलत बताने के बारे में कुछ भी गलत नहीं है - आप गलत हैं - लेकिन सबसे अच्छा है कि आप उन्हें सोचें। क्यों? क्या कोई अन्य तरीके हैं? क्या एक ही काम करने के बेहतर तरीके हैं? मेरे द्वारा उपयोग किए गए उपाख्यानों में से एक है - "मुझे इस समस्या के लिए तीन समाधान दें!"

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

सामान्य तौर पर, बहुत छोटे बच्चे तकनीकी मुद्दों (जैसे कि डिजाइन पैटर्न बेहतर काम करता है) से संबंधित अधिक संवेदनशील होते हैं, प्रक्रिया के मुद्दों पर, लेकिन समय के साथ जब आप उन्हें कोच करते हैं, तो यह काम करता है।


हालांकि वे शायद ही कभी असहमत हैं या क्यों पूछते हैं। और हाल ही में मैं अधिक स्पष्ट संकेत दे रहा हूं कि वे मेरे बयानों पर आंख मूंदकर सहमत हैं और अपनी राय नहीं बना रहे हैं।

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

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

न केवल सॉफ्टवेयर में, बल्कि हर जगह अंततः केवल सबसे सशक्त टीम के साथी ही अकेले सवाल का जवाब देने की हिम्मत करेंगे ।


1
+1 - मुझे विशेष रूप से पसंद है "यह आमतौर पर एक परिणाम है कि आप उनके सुझाव लेते हैं लेकिन बाद में उन्हें खत्म कर देते हैं और वे आपके विचारों के बारे में समान रूप से असंबद्ध होते हैं; सिर्फ इसलिए कि आप वरिष्ठ हैं वे लड़ाई से बच रहे हैं!" जैसा कि मैं वर्तमान में महसूस करता हूं।
जेटी

1
हाँ, मैं वहाँ गया था। आपकी चिंताओं / मुद्दों को अधिक से अधिक नजरअंदाज कर दिया जाता है, इसलिए आप अंत में भाग लेने के लिए परेशान नहीं होते हैं, और फिर आप घड़ी को देखते हुए समाप्त होते हैं - दिन खत्म होने का इंतजार करते हैं। बॉस: बहुत सावधान रहें कि आप सफलता को प्रोत्साहित करते हैं और पहचानते हैं, और गलतियों को इंगित न करें!
जोंगो रेनहार्ड्ट

26

यदि आप चाहते हैं कि आपके जूनियर्स खुद के लिए सोचें, तो उन्हें ठीक न करें: उन्हें खुद को सुधारने के लिए प्राप्त करें ।

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

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


7

चूंकि आपके पास कई जूनियर डेवलपर्स हैं, जो समूह 1 नहीं 1 1 के रूप में कोड समीक्षा करते हैं।

समूह से पूछें "समस्या को और कैसे हल किया जा सकता है?", और अन्य जूनियर डेवलपर्स को पहले अपने कार्यान्वयन का सुझाव देने की अनुमति दें। टीम के अन्य सदस्यों के बोलने के बाद ही अपना कार्यान्वयन जोड़ें और यदि किसी ने आपके विचार के अनुरूप कुछ नहीं सुझाया है।

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

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


3
मुझे यकीन नहीं है कि यह सबसे अच्छा विचार है। सार्वजनिक रूप से एक समूह से पूछने के बजाय लोगों को अपनी गलतियों को बताने के लिए बेहतर है कि उनका कोड अच्छा क्यों नहीं है।
साठफुटेरसूड

1
@sixtyfootersdude मुझे लगता है कि जब एक समूह के रूप में यह टीम भर में ज्ञान के व्यापक प्रसार को बढ़ावा देता है तो कोड समीक्षाएं अधिक प्रभावी होती हैं।
डैन नीली

5

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

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

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

मुद्दा यह है कि अनुभव के बिना, वरिष्ठ सदस्यों के सुझाव हमेशा उनके लिए सही लगेंगे।


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

5

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

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

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

मुझे एक्सटेंशन विधि बनाने का आपका विचार पसंद है, लेकिन मुझे यह पसंद नहीं है कि आपने एक बड़े जटिल लैम्बडा को एक पैरामीटर के रूप में कैसे पारित किया। क्या आप देखते हैं कि यह जटिल लैंबडा दूसरों को विधि के कार्यान्वयन के बारे में बहुत कुछ जानने के लिए मजबूर करता है ?

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


5

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

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


4

जब मुझे इससे निपटना पड़ा, तो मैंने (ईमानदारी से) चीजों को कहा है:

तुम्हें पता है, यह वास्तव में रचनात्मक समाधान है जिसके बारे में मैंने कभी नहीं सोचा होगा। यह कैसे पैमाने पर काम करता है? / क्या आपको लगता है कि एक दृष्टिकोण हो सकता है जो वैचारिक रूप से सरल है, विकास को तेज या रखरखाव को आसान बनाने के लिए? / दुर्भाग्य से, मुझे नहीं लगता कि यह वास्तव में परियोजना की बाकी वास्तुकला के साथ फिट बैठता है। / क्या होगा कॉन्फ़िगरेशन जैसा दिखता है?

यह आमतौर पर लोगों को एक नई दिशा में इंगित करने के लिए पर्याप्त है।


2

ज़िम्मेदारी एक चीज़ है जो उनकी मदद कर सकती है।

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


1

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

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

यह उनके करियर में कुछ बिंदु पर एक अनिवार्य अनिवार्यता होगी। आप उन्हें अच्छी कोडिंग मानकों और प्रथाओं के लिए उपयोग करके एक महान सेवा कर रहे हैं। दुर्भाग्य से हममें से अधिकांश को कठिन रास्ता सीखना पड़ा।


1

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

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

यह उन्हें दोषों को देखने की अनुमति देता है कि वे क्या विकसित कर रहे हैं जबकि एक ही समय में उन्हें आवेदन में पेश की गई समस्या को हल करने का अवसर देता है।

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