मेंटरिंग के सुझाव

मेंटरिंग नोट्स

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

अगर आपको समझ नहीं आ रहा कि नोट्स कैसे शुरू करें, तो आपको exercism/website-copy/tracks के नीचे अपने ट्रैक के अभ्यास के लिए एक mentoring.md फाइल मिल सकती है। अगर वह मौजूद है, तो उसमें उचित हलों के उदाहरण हो सकते हैं, साथ ही आम सुझाव और आगे की चर्चा छेड़ने के लिए चर्चा के बिंदु भी। अगर वह नहीं है, तो हो सकता है कि आप उस अभ्यास के लिए अपनी नोट्स की फाइल बनाने के बाद जाकर एक बनाना चाहें।

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

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

मेंटरिंग नोट्स अलग-अलग मेंटरों के अलग-अलग हो सकते हैं, इसमें कोई बात नहीं। उन्हें व्यवस्थित करने का एक तरीका यहाँ दिया गया है, लेकिन यह इकलौता तरीका नहीं है।

अगर मेंटी ने टेस्ट पास कर लिए हैं, तो उसे बधाई दीजिए।

अगर अभ्यास कुछ दिनों से क्यू में पड़ा है, तो शायद कुछ ऐसा कहकर बात शुरू कीजिए:

क्षमा कीजिए, आपको जवाब देने में किसी को थोड़ा समय लग गया। इस समय Resistor Color Duo के लिए सक्रिय JavaScript मेंटरों की कमी है।

मेंटी के हल में आपको जो अच्छा लगा, उसे बिंदुवार लिखिए। जैसे:

• मुझे यह हल संक्षिप्त और पढ़ने में आसान लगता है।

• मुझे indexOf का उपयोग अच्छा लगता है।

• मुझे अच्छा लगता है कि इसमें संख्या से स्ट्रिंग और वापस स्ट्रिंग से संख्या में बदलने से बचने के लिए (first * 10) + second तरीका इस्तेमाल किया गया है।

• मुझे अच्छा लगता है कि इसमें लूप/इटरेशन का इस्तेमाल नहीं हुआ है।

• मुझे डीस्ट्रक्चर किया गया पैरामीटर पसंद है।

इसके बाद आपके अक्सर दिए जाने वाले सुझाव आ सकते हैं।

हालाँकि हम हल बता नहीं देना चाहते, लेकिन कभी-कभी मेंटी उदाहरण से सबसे अच्छा सीखता है। कोड के एक टुकड़े को बंद रहने वाले details सेक्शन में रखने से वह उदाहरण मिल जाता है, जिसे मेंटी खोलना चाहे तो खोल सकता है, वरना नहीं। जैसे:

<details><summary>स्पॉइलर उदाहरण</summary>

<pre>

export const decodedValue = ([firstColor, secondColor]) => COLORS.indexOf(firstColor) * 10 + COLORS.indexOf(secondColor)

</pre>

</details>

नोट्स के अंत की ओर आप एक प्रकाशित हल का लिंक डाल सकते हैं, जो इन सुझावों को पूरी तरह दर्शाता है।

अपने नोट्स के सबसे नीचे आप ऐसी विस्तृत व्याख्याएँ रखना चाह सकते हैं जो मेंटी कभी-कभी पूछते हैं। ये व्याख्याएँ अक्सर सामने नहीं आतीं, लेकिन जब आप इन्हें पहली बार इस्तेमाल करें, तब उन्हें दर्ज कर लेना अच्छा रहता है, ताकि अगली बार, जो कई हफ्तों या महीनों बाद हो सकती है, आपको व्याख्या शुरू से न बनानी पड़े। जैसे, कभी-कभी कोई मेंटी पूछता है कि अगर शुरुआत में आने वाले शून्य के लिए पहली पट्टी काली हो, तो Resistor Color Duo में गुणा वाला तरीका कैसे काम करेगा:

पहली पट्टी के लिए काला होना विचार करने लायक अच्छी बात है, तो चलिए इस पर विचार करते हैं। रेज़िस्टर का रंग रेज़िस्टर में ओम की मात्रा बताने के लिए होता है, और कई पट्टियों वाले रेज़िस्टर में शुरुआती शून्य का इस्तेमाल नहीं होगा। इसलिए काला पहली पट्टी नहीं होगा। इसके अलावा, parseInt या Number भी शुरुआती शून्य को हटा देते हैं।

मेंटरिंग नोट्स में रखने लायक जानकारी की एक वैकल्पिक श्रेणी यह है: अलग-अलग हलों या तरीकों के बेंचमार्क का रिकॉर्ड।

बेंचमार्किंग

मेंटियों की एक आम चिंता यह होती है कि उनका हल कितना तेज़ है। यह खास तौर पर C, C++, Go और Rust जैसी "निचले स्तर की" भाषाओं में देखने को मिलता है। अपना कोड अपनी भाषा की शैली के कितना अनुरूप है, इसके साथ-साथ दूसरी भाषाओं के मेंटी अक्सर अपने कोड की दक्षता को लेकर भी चिंतित रहते हैं।

Go बेंचमार्किंग के लिए खास तौर पर अनुकूल ट्रैक है, क्योंकि बेंचमार्क अक्सर टेस्ट फाइल में ही शामिल होते हैं। दूसरी भाषाओं में यह पता लगाने के लिए कुछ खोजबीन करनी पड़ सकती है कि आपके लिए कौन-सा तरीका सबसे अच्छा काम करेगा। जैसे, अगर आप सिर्फ ऑनलाइन एडिटर इस्तेमाल करते हैं, तो आपको ऑनलाइन बेंचमार्क चलाने की कोई जगह ढूँढनी होगी। उदाहरण के लिए, JSBench.me JavaScript के लिए एक ऑनलाइन बेंचमार्किंग टूल है।

अगर आप कोड अपनी मशीन पर ही चलाते हैं, तो आपके पास बेंचमार्किंग सॉफ्टवेयर डाउनलोड करने का विकल्प है, जिसे आप अपनी मशीन पर चला सकते हैं। जैसे, Rust Criterion इस्तेमाल कर सकता है, या benchmark tests के साथ cargo bench।

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

ऐसे मेंटरिंग नोट्स जो किसी खास अभ्यास से जुड़े नहीं हैं

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

जब मेंटी का कोई सवाल हो

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

अगर आपको जवाब नहीं आता लेकिन आप उसे ढूँढना चाहते हैं, तो बेहतर होगा कि जवाब जान लेने तक मेंटरिंग अनुरोध न उठाएँ। अगर तब तक वह अनुरोध किसी और के पास चला गया हो, तो कम से कम आपने कुछ सीखा तो है और मेंटी से इंतज़ार नहीं कराया।

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

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

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

फेल होता कोड

कोड या तो इसलिए फेल हो सकता है कि वह सारे टेस्ट पास नहीं करता, या इसलिए कि वह कंपाइल नहीं होता या इंटरप्रेटर को संतुष्ट नहीं करता।

फेल होते कोड से निपटने की रुझान और/या धैर्य अलग-अलग मेंटरों में अलग-अलग होगा, जो कुछ हद तक इस पर निर्भर कर सकता है कि वह कैसे पेश किया गया है, क्योंकि फेल होता कोड हमेशा एक ही तरह से पेश नहीं किया जाता।

कभी-कभी कोई मेंटी कहता है कि उसने कोई दूसरा तरीका आज़माया और वह काम नहीं आया, और वह पूछता है कि वह क्यों काम नहीं आया। कोड शायद दिया ही न हो, या इटरेशन में देने के बजाय किसी लगभग अपठनीय कमेंट में डाला गया हो।

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

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

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

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

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

अंत में, फेल होते कोड को ठीक करना मेंटर की ज़िम्मेदारी नहीं है, लेकिन मेंटर चाहे तो मेंटी को सुझाव दे सकता है कि वह इसे खुद कैसे ठीक कर सकता है।

क्यू की निरंतरता से निपटना

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

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

अगर एक ही अभ्यास के कई अनुरोध हैं, तो ध्यान बनाए रखने के लिए आप उन्हें एक ही अभ्यास के समूहों में निपटाना चाह सकते हैं, बजाय अभ्यास A से अभ्यास B और फिर वापस अभ्यास A पर जाने के।

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