क्या किसी के पास जूनियर प्रोग्रामर को सलाह देने के बारे में कोई सुझाव है? यदि आपने किसी को सलाह दी है तो क्या आपने किसी भी प्रक्रिया का पालन किया है या यह काफी अनौपचारिक था?जूनियर प्रोग्रामर को सलाह देने के लिए कैसे करें
यदि आपको अतीत में सलाह दी गई है कि आपको किस तरह की चीजें सबसे उपयोगी मिलती हैं?
दिन में 30-60 मिनट के बीच एक साथ अपने कोड की समीक्षा करने के लिए सेट करने का प्रयास करें। यदि आप ऐसा नहीं कर सकते हैं, तो जब भी वे कोड प्रतिबद्ध करते हैं, तब तक उनके कोड की समीक्षा करने के लिए एक साथ आने का प्रयास करें, जब तक कि यह बहुत बुनियादी न हो। उन्हें समझाएं कि उन्होंने दूसरों के बदले उन्होंने जो दृष्टिकोण लिया, वह क्यों चुना। इस तरह की एक प्रक्रिया एक महान रिश्ते को स्थापित करने में मदद करती है, साथ ही वास्तव में छात्र को स्वयं को सोचने के लिए प्रोत्साहित करती है और अपने फैसलों की रक्षा करने में सक्षम होती है। छात्र न केवल किसी ऐसे व्यक्ति के साथ समाप्त होता है जिस पर वे भरोसा कर सकते हैं, लेकिन आप कोड की गुणवत्ता और तर्क में तुरंत सुधार करेंगे।
संपादित करें: इसके अलावा, यदि आप अपने जूनियर के साथ सह-समीक्षा करने में इतना समय नहीं दे पा रहे हैं, तो शायद आपको उन्हें सलाह नहीं देनी चाहिए और इसके बजाय देखें कि किसी और के पास ऐसा शेड्यूल है जो इसे अनुमति देगा। सलाह देने का पूरा बिंदु छात्र के व्यावसायिक विकास में सक्रिय रूप से सहायता करना है, और यदि वे उचित ध्यान और मार्गदर्शन नहीं देते हैं तो वे ज्यादा सीखने वाले नहीं हैं।
आश्चर्यजनक प्रतिक्रिया !!! – traditional
मैं जूनियर होगा, मुझे लगता है :) मुझे लगता है कि मुझे एक अनौपचारिक दृष्टिकोण की कीमत होगी। यह शायद आपके और आपके mentee के पात्रों पर बहुत निर्भर करता है, लेकिन मैं कहूंगा कि अगर आप रास्ते में अहंकार नहीं रखते हैं तो आप सबसे अच्छा सीखते हैं। बर्फ तोड़ें, सुनिश्चित करें कि दोनों दिशाओं में प्रतिक्रिया है। कोड समीक्षा (दोनों तरीकों से) जैसी चीजें और कभी-कभी जोड़ी प्रोग्रामिंग काम कर सकती है, और यदि कोई अच्छा मैच है, तो यह भी बहुत मजेदार हो सकता है!
मैंने पहले मेरे तहत कई जूनियर लोगों को सलाह दी है। मेरा दृष्टिकोण थोड़ा अलग व्यक्ति के आधार पर थोड़ा अलग था कि उन्होंने कैसे सीखा।
संक्षेप में, मैंने जूनियर लोगों को छोटे, आत्मनिर्भर परियोजनाएं दीं जब मैं कर सकता था और उन्हें कार्य को पूरा करने के लिए अपेक्षाकृत निश्चित समय दिया था। एक बार कार्य पूरा होने के बाद, मैं उनके दृष्टिकोण, कोड और समाधान की समीक्षा करूंगा और सुधार के लिए सुझाव या समस्या को संभालने का एक बेहतर तरीका सुझाऊंगा। मुझे लगता है कि इस तरह वे बहुत बड़ी परियोजना का हिस्सा होने से अभिभूत महसूस नहीं करते हैं।
उम्मीद है कि यह थोड़ा सा मदद करता है।
मुझे एक छोटी सॉफ्टवेयर कंपनी में एक इंटर्न (दो में से एक) के रूप में काम करने का मौका मिला था और उनके पास "लगभग नई" परियोजना पर काम करने का अवसर था। उन्होंने मुझे सबकुछ जरूरी चीजों के साथ स्थापित किया और मुझे वास्तव में प्रोजेक्ट क्या था (मूलभूत सामान जैसे आवश्यकताओं आदि) में एक परिचय दिया।
सबसे पहले हमें परियोजनाओं से संबंधित चीजों की खोज करने जैसे मामूली कार्यों को करना पड़ा (उन्होंने हमें विषयों की एक सूची दी थी)। यह, मुझे लगता है कि यह देखने के लिए कि हम खुद को कितना संभाल सकते हैं, क्योंकि जिन चीज़ों को हमें देखने और शोध करने की आवश्यकता थी, वह छोटा नहीं था और इसमें 2 सप्ताह या उससे भी अच्छा समय लगा (इसके लिए हमें बनाए जाने वाले बुनियादी डेमो को गिनना) । वह परीक्षण चरण वास्तव में वास्तव में 'कोचिंग' के बिना किया गया था।
हालांकि, उस अवधि के बाद हम वास्तविक परियोजना पर ही काम कर सकते थे। यह वह क्षण भी था जब हमने एक ही शैली में pair programming पर एक साथ शैली शुरू की, सिवाय इसके कि हम में से तीन (2 इंटर्न और 1 'कोच') थे।
हमने उससे बहुत कुछ सीखा, लेकिन यह एक अनौपचारिक तरीके से था, और उसने 'सब-जानकार-सुनने-मुझे' लड़के की तरह काम नहीं किया। जब हमारे पास सुझाव थे तो वह हमारे साथ सुनकर सोचता था कि वे अच्छे थे या नहीं। या इस बारे में अपना विचार दें कि इस तरह से एक विचार क्यों नहीं किया जाना चाहिए ...अब जब मैं इसके बारे में सोचता हूं, तो उसने हमें सक्रिय रूप से सुझाव देने के लिए प्रोत्साहित किया, और चीजों को करने के बेहतर तरीकों के बारे में सोचने के लिए, बस वहां से 'ऑर्डर लेने' की बजाय, जो शायद जानता है कि आपको बेहतर क्या करना है।
संक्षेप मेंतो:
यह अच्छा है। सलाह देने में मैंने जो समस्याएं देखी हैं उनमें से एक यह है कि आपके पास कुछ लोग हैं जो गेंद के साथ भागेंगे, और कुछ जो नहीं करेंगे। मैं वर्तमान में इस राय का हूं कि आपको सफल होने के लिए अधिक गेंद धावकों की आवश्यकता है। – EvilTeach
मैं आपके पास वास्तविक असाइनमेंट के कुछ हिस्सों को देने शुरू करने की सलाह दूंगा और सबकुछ अपने कोड का उपयोग करने में सक्षम होगा। दूसरे शब्दों में उसे अपने लिए प्रतिस्थापन के रूप में प्रशिक्षित करें।
इस तरह आप जूनियर के साथ काम करने के लिए समय आवंटित करने के लिए प्रतिबद्ध होंगे और वह "वास्तविक जीवन" देख पाएंगे। वास्तविक असाइनमेंट पर काम करके और जीवंत प्रतिक्रिया सुनकर वह तेजी से गति प्राप्त करने में सक्षम हो जाएगा।
इस दृष्टिकोण का दोष यह है कि यह संभव है कि यह आपके विशेष परियोजना पर बहुत संकीर्ण ध्यान केंद्रित करे। इसलिए प्रशिक्षु संभावित विकल्पों को दिखाना सुनिश्चित करें और अपने व्यावसायिक क्षितिज को विस्तारित करने के लिए व्यापार-बंद विश्लेषण को प्रोत्साहित करें।
कुछ साल पहले मैंने एक छोटी कंपनी के लिए काम किया था, जहां पहले दिन मुझे पूरा करने के लिए छोटे कार्य की एक सूची दी गई थी - कोड में कुछ छोटे बदलाव करें, परियोजना में एक छोटी सी बग को ढूंढें और ठीक करें। यह वास्तव में मुझे अपने सलाहकार से सही प्रश्न पूछने और पर्यावरण, कोड बेस के साथ परिचित कराने में मदद करता है। इन कार्यों को पूरा करना आसान था, इसलिए बड़े कार्यों में जाने से पहले, मुझे थोड़ा आत्मविश्वास था।
सलाह देने का यह तरीका वास्तव में मेरे साथ बहुत अच्छा काम करता है, इसलिए मैं अपने नए सहयोगी के साथ ऐसा करने की योजना बना रहा हूं।
इंटर्नशिप डब्ल्यू/एक बड़ी कंपनी के दौरान जिसमें बहुत सारे घर आईटी थे, मुझे डब्ल्यू/एक सलाहकार जोड़ा गया। तकनीकी कौशल और व्यावसायिक कौशल के संदर्भ में, अभ्यास ने निश्चित रूप से अपने करियर के विकास की सहायता की।
क्योंकि मैं समझाने के लिए क्यों मैं सह सेशन के लिए अपने साक्षात्कार के दौरान (पैसे की जरूरत के अलावा) चाहती थी, मेरे प्रबंधक यकीन है कि मेरी पहली परियोजना मुझे मैं क्या कमजोर क्षेत्रों के रूप में पहचान की थी पर काम करने की अनुमति बनाया: बहुत कम लिनक्स अनुभव (मैंने एक लिनक्स-केवल आर & डी टीम चुना है, इसलिए मुझे सीखने के लिए मजबूर होना होगा), एक उपयोगी टेक्स्ट एडिटर (मैं वास्तव में वीम सीखना चाहता था) नहीं जानता, और कैसे एक और प्रोग्रामिंग भाषा सीखना है (बहुत अलग दृष्टिकोण जब आप प्रोग्राम करना सीखते हैं तो भाषा सीखने से)। उसने मुझे बताया कि मुझे थोड़ी देर के लिए अध्ययन करने के लिए भुगतान किया जा रहा था।
मैं, पढ़ने पुस्तकों से सबसे अच्छा सीख रहे हैं ताकि से अधिक यूनिक्स Dummies (आहा! मेरे अलावा कोई और सोचा कि यह कभी कभी अस्पष्ट और knuckleheaded था नहीं था) के लिए मुँह दबाकर हँसती के बाद मैं संक्षेप और Sobell के दशक में यूनिक्स के साथ शुरू लिनक्स कमांड के लिए प्रैक्टिकल गाइड। उसके बाद मैंने विम प्रलेखन मुद्रित किया और इसके माध्यम से जाना शुरू कर दिया। तब मैंने अपनी पहली परियोजना की भाषा पाइथन पर कुछ किताबें देखीं। मुझे इन चीजों के बारे में सहज महसूस करने के लिए हर समय दिया गया था (जो वास्तविक समस्या थी, जैसा कि अब मैं समझता हूं) और फिर पिछले सह-सेप की परियोजना में कार्यक्षमता जोड़ने शुरू कर दिया।
मुझे एहसास है कि अब कोड समीक्षा के लिए हर दिन या दो से मिलने के लिए यह बहुत ही अच्छा होगा, क्योंकि कामिकज़ मर्सनरी ने कहा।
यहाँ मेरी संक्षिप्त सूची होगा:
जोड़ी प्रोग्रामिंग - यह, बहुत सी बातें के लिए उपयोगी है विभिन्न विचारों और प्रथाओं मजबूत की तरह। Resharper के लिए उपयोग करना बहुत आसान होता है जब आप किसी ऐसे व्यक्ति के साथ जोड़ते हैं जो अक्सर इसका उपयोग करता है।
अनौपचारिक चैट - यह वह जगह है जहां हम एक पेय पीते हैं, धूम्रपान करने के लिए किसी के लिए बाहर जाते हैं, एक साथ दोपहर के भोजन के लिए जाते हैं, आदि। डेस्क से दूर होने पर, चर्चा तुरंत काम से संबंधित हो सकती है या यह अमूर्त दार्शनिक सामान हो सकता है जो किसी के खेल को एक या दो तक लाने में मदद कर सकता है। विभिन्न आने वाली प्रौद्योगिकियों या आने वाले बदलावों के बारे में बात करना रोमांचक हो सकता है और बॉन्ड भी मदद कर सकता है।
प्रतिक्रिया और सुझाव - यह उपरोक्त दोनों मामलों में हुआ है। डेल कार्नेगी द्वारा "हाउ टू विन फ्रेंड्स एंड इंफ्लुएंंस पीपल" जैसी किताबें विभिन्न मानव रिश्तों की गतिशीलता को समझने में मदद कर सकती हैं, जबकि यह काफी तकनीकी लगता है, वास्तव में यह है कि विभिन्न तरीकों से किसी और को कैसे प्रेरित किया जाए। यहां एक महत्वपूर्ण बिंदु यह जानना है कि कुछ अभ्यासों को चुनने के लिए ब्रेडक्रंब का निशान कैसे छोड़ना है, जैसे उत्तर देने के बजाय कुछ के बारे में संकेत देने के बाद संकेत देना। मेरे पास विभिन्न गणित शिक्षकों के पास इस के लिए एक उपहार था कि मैंने इस कौशल में से कुछ कैसे विकसित किए।
तो इसका हिस्सा केवल दूसरे व्यक्ति को प्रेरित करना और उन्हें मार्गदर्शन करने की कोशिश कर रहा है क्योंकि जब कोई स्वयं के लिए कुछ समझता है तो यह एक सशक्त और प्रबुद्ध अनुभव हो सकता है। , "मैंने किया! यह सही है, मोई, तुम्हारा सचमुच!" जब ऐसा होता है तो आत्म-बात की तरह काफी अच्छा होता है।
किसी के मार्गदर्शन में मेरे अनुभव में सलाहकार के लिए वास्तव में और अधिक जानना बहुत महत्वपूर्ण है।
कभी भी चम्मच उन्हें खिलाओ। इसके बजाय उन्हें मूल्य की चीजों की ओर इंगित करें और उन्हें उन नई परियोजनाओं का उपयोग करें जो वे उन परियोजनाओं में सीख रहे हैं जिनका उपयोग वे कर रहे हैं। यदि अभ्यास में नहीं रखा जाता है तो ज्ञान बेकार है। तो कोड, कोड, कोड के लिए अपने mentoree को प्रोत्साहित करें।
रोज़गार की मेरी पहली जगह पर यह वास्तव में रोगी दोस्त था जो हमेशा मुझे अपनी तत्काल समस्या हल करने में मदद करेगा, और फिर मुझे कुछ महत्वपूर्ण अंतर्निहित सिद्धांत सिखाएगा। मुझे यह पसंद आया क्योंकि वह मुझे बेहतर प्रोग्रामर बनने के तरीके के दौरान उत्पादक बने रहने में मदद करेगा।
उनसे पूछें कि वे कार्य को पूरा करने के आगे क्या प्रयास करेंगे। यह "मुझे नहीं पता कि" क्या करना है "से कहां से एक विचार दे सकता है" ठीक है, मैं कोशिश करता हूं लेकिन ... "श्रेणी वे अपने विचार रखने के मामले में हैं जो शुरुआती बिंदु के लिए उपयोगी हो सकती है ।
एक त्वरित नज़र डालें कि वे क्या करना चाहते हैं और संकेत प्रदान करते हैं ताकि वे समस्या का पता लगा सकें। इसका जवाब देने के बजाय, "कोड की इस पंक्ति को बाहर निकालें," सुझाव देते हैं कि वे क्या देखते हैं और क्या यह आवश्यक है
सबसे उपयोगी: एक लुढ़का हुआ समाचार पत्र –
@ स्टीवन ए लोवे: आप जब मैंने अपने कुत्तों को प्रशिक्षित किया तब से कई यादें वापस लाईं। :) –