किसी को मेंटर बनने के लिए क्या योग्यता चाहिए?
क्या भाषा सीखते-सीखते भी उसकी मेंटरिंग की जा सकती है?
क्या एक से अधिक भाषाओं की मेंटरिंग की जा सकती है?
क्या कतार के हर हल की मेंटरिंग करने की कोशिश करनी चाहिए?
अगर कोई हल कतार में कई दिनों, यहाँ तक कि हफ्तों तक पड़ा रह जाए तो क्या करें?
अगर किसी हल के बारे में सुझाव देने के लिए कुछ न हो तो क्या करें?
क्या ऐसे अभ्यास की मेंटरिंग करनी चाहिए जिसे कभी हल न किया हो?
क्या ऐसे अभ्यास की मेंटरिंग करनी चाहिए जिसे हल किया हो, पर किसी दूसरी भाषा में?
क्या कोई हल देख लेने के बाद उसकी मेंटरिंग करना ज़रूरी है?
अगर कई बार समझाने के बाद भी छात्र को समझ न आए तो क्या करें?
अगर छात्र मेरे सुझावों पर बचाव की मुद्रा में आ जाए तो कैसे जवाब देना चाहिए?
अगर मुझे लगे कि छात्र गलत है, तो भी क्या अंतिम बात छात्र की ही मानी जाए?
सुझाव को सबसे अच्छे ढंग से कैसे कहा जाए?
क्या फॉर्मेटिंग, टिप्पणी और नामकरण की परंपराओं को लागू कराना चाहिए?
किसी को मेंटर बनने के लिए क्या योग्यता चाहिए?
किसी भाषा की मेंटरिंग के लिए उस भाषा के विशेषज्ञ होना ज़रूरी नहीं है।
आपको बस उस व्यक्ति से थोड़ा कम नौसिखिया होना है जिसकी आप मेंटरिंग कर रहे हैं।
अगर किसी हल में कोई चीज़ ऐसी लगे जिसे आपके ख्याल से किसी और तरीके से किया जा सकता है, तो आप उसका सुझाव दे सकते हैं।
यह ज़रूरी नहीं कि वह बेहतर तरीका ही हो, वह बस भाषा के अनुरूप एक और विकल्प हो सकता है।
इससे यह फैसला छात्र पर ही छूट जाता है कि सुझाव अपनाना है या नहीं, लेकिन कम से कम चुनने के लिए उसके पास और विकल्प तो होते हैं।
क्या भाषा सीखते-सीखते भी उसकी मेंटरिंग की जा सकती है?
आदर्श रूप से, किसी भाषा को सीखना कभी बंद नहीं होता, चाहे वह भाषा आपको पहले से आती हो।
कुछ भाषाएँ हर कुछ हफ्तों या महीनों में नया संस्करण जारी करती हैं।
सीखने के लिए भाषा के नए फीचर तो हो सकते ही हैं, ऐसे फीचर भी हो सकते हैं जिनसे आप अब तक परिचित न हों।
कभी-कभी कोई छात्र ऐसा फीचर इस्तेमाल कर सकता है जिसे आप पहली बार देख रहे हों।
इसलिए किसी भाषा के बारे में और ज़्यादा जानने का अच्छा तरीका मेंटरिंग हो सकती है।
क्या एक से अधिक भाषाओं की मेंटरिंग की जा सकती है?
आप जितनी भाषाओं में सहज महसूस करते हैं, उतनी की मेंटरिंग कर सकते हैं।
जिन भाषाओं में आप खुद को मज़बूत मानते हैं, उन सबकी मेंटरिंग करना ठीक है, और उस भाषा की भी जिसे आप अभी सीख रहे हैं।
क्या कतार के हर हल की मेंटरिंग करने की कोशिश करनी चाहिए?
अगर उस समय किसी हल के बारे में कुछ ठोस या काम का कहने को न सूझे, तो छात्र के लिए बेहतर यही होगा कि आप वह मेंटरिंग अनुरोध किसी दूसरे मेंटर के लिए छोड़ दें, भले ही उसे जवाब के लिए और ज़्यादा इंतज़ार करना पड़े।
अगर कोई हल कतार में कई दिनों, यहाँ तक कि हफ्तों तक पड़ा रह जाए तो क्या करें?
अगर छात्र ने कोई खास सवाल पूछा है जिसका जवाब आपके पास नहीं है, तो भी बेहतर होगा कि आप उसे किसी ऐसे व्यक्ति के लिए छोड़ दें जो उसके सवाल का जवाब दे सके।
वरना यह भी हो सकता है कि वह हल ऐसे अभ्यास का हो जो आपके लिए कठिन रहा हो, जिसे आपने या तो हल ही न किया हो, या किया हो पर लगा हो कि ठीक से नहीं किया।
ऐसे में आप उस हल को देख सकते हैं कि उससे सीखने लायक कुछ है या नहीं।
अगर हाँ, तो आप छात्र को धन्यवाद दे सकते हैं कि उसके हल से आपने यह खास बात सीखी।
या आप चाह सकते हैं कि छात्र आपको अपना हल समझाए।
यह एक तरह की "उलटी मेंटरिंग" है, लेकिन कुछ छात्र विनम्रता और सम्मान के साथ पूछे जाने पर अपना हल समझाने में खुशी महसूस कर सकते हैं।
इसके बाद आप पूछ सकते हैं कि क्या उन्होंने कोई और तरीका सोचा था, और उन्होंने जो तरीका चुना वह क्यों चुना।
या फिर, पूरा हल आपको अब भी समझ न आए, लेकिन कुछ ऐसी बातें दिख जाएँ जिन पर आप चर्चा कर सकें।
उदाहरण के लिए, अगर छात्र ने सिर्फ n या m इस्तेमाल किए हों, तो आप सुझा सकते हैं कि फंक्शन के पैरामीटर के लिए अर्थपूर्ण नाम रखने पर विचार करें।
अगर इनमें से कोई भी काम करने में आप सहज न हों, तो अनुरोध को बिना जवाब छोड़ देना भी ठीक है।
मेंटरिंग स्वैच्छिक है।
किसी भाषा की मेंटरिंग करने का यह मतलब नहीं कि उस भाषा के हर अभ्यास की मेंटरिंग करनी ही पड़े।
अगर किसी हल के बारे में सुझाव देने के लिए कुछ न हो तो क्या करें?
किसी हल में जो बात आपको अच्छी लगी हो, उसे कह देना ठीक है।
वास्तव में, किसी हल में अपनी पसंद की खास बात बताना किसी भी मेंटरिंग बातचीत की अच्छी शुरुआत होती है।
ऐसा करने के बाद, अगर अभ्यास को करने के किसी और तरीके का सुझाव आपके पास न हो, तो छात्र से बस "शाबाश!" कह देना ठीक है।
अगर छात्र ने एक से अधिक इटरेशन जमा किए हैं, तो आप बता सकते हैं कि सबसे नया इटरेशन किन तरीकों से बेहतर है।
क्या ऐसे अभ्यास की मेंटरिंग करनी चाहिए जिसे कभी हल न किया हो?
कभी-कभी छात्र का हल देखकर आपको खुद वह अभ्यास हल करने की प्रेरणा मिल सकती है, खासकर अगर हल में अपनाया गया तरीका अभ्यास को उन तरीकों से आसान बनाता दिखे जिन्हें आप पहले सोच चुके हैं।
अभ्यास हल करने के बाद, अगर जिस मेंटरिंग अनुरोध से आपको प्रेरणा मिली थी वह अब उपलब्ध न हो, तो कम से कम अगली बार के लिए आप तैयार रहेंगे।
क्या ऐसे अभ्यास की मेंटरिंग करनी चाहिए जिसे हल किया हो, पर किसी दूसरी भाषा में?
चूँकि एक भाषा में जो स्वाभाविक है, वह दूसरी भाषा में स्वाभाविक नहीं हो सकता, इसलिए बेहतर यही होगा कि अभ्यास उसी भाषा में हल किया गया हो जिसकी मेंटरिंग हो रही है।
अगर दो भाषाओं के हल बहुत मिलते-जुलते हैं, और आप दोनों भाषाएँ इतनी अच्छी तरह जानते हैं कि पता हो कि किस भाषा में क्या स्वाभाविक है, तो एक भाषा के हल को दूसरी भाषा में ढालने में ज़्यादा समय नहीं लगेगा।
हल ढालने के बाद अगर मेंटरिंग अनुरोध अब उपलब्ध न हो, तो कम से कम अगली बार के लिए आप तैयार रहेंगे।
क्या कोई हल देख लेने के बाद उसकी मेंटरिंग करना ज़रूरी है?
कोई हल देखकर आप महसूस कर सकते हैं कि आप उसकी मेंटरिंग नहीं करना चाहते, और इसके कई कारण हो सकते हैं, जैसे:
- छात्र ने ऐसा सवाल पूछा हो जिसका जवाब आपको न पता हो।
- कोड इतना लंबा और/या उलझा हुआ हो कि आपको समझ न आए कि आलोचना कहाँ से शुरू करें।
- कोड से लगे कि छात्र बिल्कुल शुरुआती है और उसे ढेर सारे बुनियादी मार्गदर्शन की ज़रूरत होगी, जिसके लिए आपके पास न समय है न धैर्य।
- छात्र की टिप्पणी से लगे कि उससे बात करना अप्रिय या कष्टदायक हो सकता है।
अगर आपको लगता है कि कोई खास मेंटरिंग अनुरोध आपके लिए नहीं है, तो "Start mentoring" बटन पर क्लिक करने की कोई बाध्यता नहीं है।
अगर कई बार समझाने के बाद भी छात्र को समझ न आए तो क्या करें?
कभी-कभी छात्र आपकी समझाइश समझने में लगभग जान-बूझकर ज़िद करता दिख सकता है।
अगर आपको लगे कि समझाने के अपने सारे तरीके आप आज़मा चुके हैं, तो आप यह सुझाव देकर बातचीत खत्म कर सकते हैं कि छात्र अपना मेंटरिंग अनुरोध दोबारा भेजे, ताकि उसे कोई और मेंटर संभाल सके, जो उन मुश्किल बिंदुओं को शायद बेहतर ढंग से समझा पाए।
अगर छात्र मेरे सुझावों पर बचाव की मुद्रा में आ जाए तो कैसे जवाब देना चाहिए?
कभी-कभी छात्र कहता है कि उसने ज़रूरत से ज़्यादा मेहनत वाला तरीका इसलिए अपनाया ताकि भाषा के किसी फीचर के बारे में और जान सके, भले ही वह फीचर उस अभ्यास के लिए सबसे उपयुक्त न हो।
चूँकि Exercism सीखने का प्लेटफॉर्म है, प्रतिस्पर्धी कोडिंग की साइट नहीं, यह एक उचित कारण है कि सबसे सुंदर या सबसे कुशल तरीका न अपनाया जाए।
अगर आपको लगे कि वे अपना तरीका और स्वाभाविक ढंग से लागू कर सकते थे, तो आप उस तरीके को इस्तेमाल करने के बारे में कुछ सुझाव दे सकते हैं।
किसी भी हाल में, आप सुझाव दे सकते हैं कि वे फीडबैक के आधार पर एक और इटरेशन जमा करें, या मेंटरिंग स्लॉट खाली करने के लिए बातचीत खत्म कर दें।
कोई छात्र ऐसे प्रोग्रामिंग पैराडाइम पर चल सकता है जो उस भाषा या अभ्यास के लिए सबसे उपयुक्त न हो।
उदाहरण के लिए, वे हमेशा ऑब्जेक्ट-ओरिएंटेड पैराडाइम ही इस्तेमाल करना चाहें, और एक अपेक्षाकृत सरल और सीधे हल को ढेरों क्लासों में बिखेर दें, जिनमें कई मेथडों से गुज़रने वाला उलझा हुआ कंट्रोल फ्लो हो।
जहाँ तक छात्र उस पैराडाइम का कट्टर अनुयायी है, वहाँ उसे किसी अलग तरीके के लिए मनाने की कोशिश आमतौर पर बेकार जाती है।
आप कोशिश कर सकते हैं, और हो सकता है वे आपके सुझाव पर विचार करें, लेकिन अगर छात्र अपनी बात पर अड़ जाए, तो आगे बढ़ जाना ही बेहतर है।
छात्र किसी सुझाव को सीधे नकार भी सकता है।
उदाहरण के लिए, आप map और join की जगह reduce इस्तेमाल करने का सुझाव दे सकते हैं, क्योंकि reduce में सिर्फ एक इटरेशन होता है, जबकि map के लिए एक और join के लिए दूसरा इटरेशन लगता है।
लेकिन छात्र इसे नकार सकता है, क्योंकि उसे map और join पढ़ने में ज़्यादा आसान लगते हैं।
इस बात से सहमत हो जाना ठीक है कि map और join, reduce से पढ़ने में ज़्यादा आसान हो सकते हैं।
आप सुझाव दे सकते हैं कि थोड़े और समय में अभ्यस्त होने के बाद वे reduce के साथ ज़्यादा सहज हो जाएँगे, और map और join इस्तेमाल करने में कोई गलती नहीं है।
जहाँ तक छात्र सही है वहाँ उससे सहमत हो जाना ठीक है, और छात्र की किसी भी भ्रांति या बढ़ा-चढ़ाकर कही गई बात को ठीक करने की कोशिश करना भी ठीक है।
अगर मुझे लगे कि छात्र गलत है, तो भी क्या अंतिम बात छात्र की ही मानी जाए?
उदाहरण के लिए, आप सुझाव दे सकते हैं कि छात्र Clock अभ्यास हल करते समय 60 और 24 जैसी मैजिक नंबर इस्तेमाल न करे, बल्कि उन्हें अर्थपूर्ण नामों वाले कॉन्स्टेंट के रूप में परिभाषित करे।
छात्र जवाब दे सकता है कि संदर्भ को देखते हुए यह साफ़ है कि 60 और 24 किसके लिए हैं।
आपने अपना सुझाव दे दिया और छात्र ने उसे खारिज कर दिया।
इस पर बहस करने से शायद कुछ हासिल न हो, और सद्भावना भी खो सकती है।
सुझाव को सबसे अच्छे ढंग से कैसे कहा जाए?
किसी चीज़ को ऐसे विकल्प के रूप में सुझाने के लिए, जो ज़रूरी नहीं कि बेहतर हो, आप इस तरह शुरुआत कर सकते हैं: "एक और तरीका यह हो सकता है..."
उदाहरण के लिए, "एक और तरीका यह हो सकता है कि includes के साथ every इस्तेमाल किया जाए।"
अगर आप कोई ऐसा भाषा फीचर बता रहे हैं जो छात्र ने हल में इस्तेमाल नहीं किया (जैसे every या includes),
तो बेहतर होगा कि उसे समझाने वाले किसी दस्तावेज़ का लिंक दे दें।
सुझाव शुरू करने का एक और तरीका यह हो सकता है: "शायद इस पर विचार करें..."
उदाहरण के लिए, "शायद split() की जगह स्प्रेड सिंटैक्स इस्तेमाल करने पर विचार करें।"
अगर आपको दृढ़ता से लगता है कि छात्र को कोई विकल्प इस्तेमाल करना ही चाहिए, तो आप "शायद" हटाकर "विचार करें..." से शुरू कर सकते हैं।
उदाहरण के लिए, "डिफ़ॉल्ट आर्गुमेंट इस्तेमाल करने पर विचार करें।"
सुझावों की एक श्रृंखला के लिए आप चाहेंगे कि हर सुझाव को अलग तरीके से शुरू करें।
किसी हल में अपनी पसंद की बातें गिनाने का बुलेट पॉइंट एक असरदार तरीका है।
लेकिन सुझाव गिनाते समय बुलेट पॉइंट कम दोस्ताना लग सकते हैं।
सुझाव अनौपचारिक, बातचीत के ढंग से देने पर छात्र के लिए उन पर विचार करना और उन्हें मान लेना आसान हो जाता है।
सुझाव देते समय जिस एक शब्द का इस्तेमाल शायद सबसे अच्छा नहीं है, वह है "चाहिए"।
उदाहरण के लिए, "आपको डिफ़ॉल्ट आर्गुमेंट इस्तेमाल करना चाहिए।"
"चाहिए" या "अवश्य" जैसे शब्द दबंग लग सकते हैं।
क्या फॉर्मेटिंग, टिप्पणी और नामकरण की परंपराओं को लागू कराना चाहिए?
मेंटरों में इस पर मतभेद होना स्वाभाविक है कि कोड की फॉर्मेटिंग, टिप्पणी और नामकरण की परंपराओं जैसी बातें कब और कितनी सख्ती से उठाई जाएँ।
एक तरफ, आप चाहेंगे कि छात्र Two Fer जैसे अभ्यासों में ही इन बातों के बारे में सोचने लगे, इससे पहले कि उसकी बुरी आदतें पड़ जाएँ।
या आप एक शुरुआती को औचित्य के इतने सारे विचारों से डराना नहीं चाहेंगे।
दूसरी तरफ, ज़्यादा उन्नत अभ्यास करने वाले छात्रों को ये परंपराएँ पहले से पता हो सकती हैं, लेकिन सामने पड़े काम पर ध्यान देते हुए वे उन्हें जान-बूझकर नज़रअंदाज़ कर सकते हैं।
वे परंपराओं पर बार-बार ज़ोर देने को व्यर्थ की औपचारिकता समझकर बुरा मान सकते हैं।
अगर किसी भाषा में एक या अधिक फॉर्मेटर या लिंटर हों, तो यह चुनना अच्छा हो सकता है कि उनसे परिचय किस अभ्यास में कराया जाए।
वरना, अगर किसी खास परंपरा का उल्लंघन वाकई गंभीर हो, तो आप उसे जहाँ भी देखें वहीं बताना चाहेंगे।
मेंटरों में मतभेद यहाँ हो सकता है कि किसे "वाकई गंभीर" माना जाए।
