মেন্টরিং সম্পর্কিত সচরাচর জিজ্ঞাসিত নানা প্রশ্নের সংগ্রহ
মেন্টর হওয়ার জন্য কী যোগ্যতা দরকার?
আমি এখনও যে ভাষা শিখছি, তাতে কি মেন্টরিং করতে পারি?
আমি কি একাধিক ভাষায় মেন্টরিং করতে পারি?
কিউতে থাকা প্রতিটি সমাধানে কি মেন্টরিং করার চেষ্টা করা উচিত?
কোনো সমাধান যদি দিনের পর দিন, এমনকি সপ্তাহের পর সপ্তাহ কিউতে পড়ে থাকে?
কোনো সমাধান নিয়ে বলার মতো কিছু না থাকলে কী করব?
যে অনুশীলনী কখনও সমাধান করিনি, তাতে কি মেন্টরিং করা উচিত?
যে অনুশীলনী সমাধান করেছি, তবে অন্য ভাষায়, তাতে কি মেন্টরিং করা উচিত?
কোনো সমাধান একবার দেখে ফেললে কি তা মেন্টরিং করা বাধ্যতামূলক?
আমি বারবার কোনো কিছু বোঝানোর পরও শিক্ষার্থী না বুঝলে কী হবে?
আমার পরামর্শ নিয়ে শিক্ষার্থী যদি রক্ষণাত্মক হয়ে পড়ে তবে কী উত্তর দেব?
আমি ভুল মনে করলেও কি শেষ কথা শিক্ষার্থীরই থাকা উচিত?
পরামর্শ সবচেয়ে ভালোভাবে কীভাবে বলব?
ফরম্যাটিং, কমেন্ট আর নেমিং কনভেনশন কি জোর করে প্রয়োগ করা উচিত?
কোনো ভাষায় মেন্টরিং করতে হলে সেই ভাষার বিশেষজ্ঞ হওয়ার দরকার নেই। আপনি যে ব্যক্তিকে মেন্টরিং করছেন, তার চেয়ে একটু কম নতুন হলেই যথেষ্ট। কোনো সমাধানে এমন কিছু থাকলে যা আপনি মনে করেন ভিন্নভাবে করা যেত, আপনি তা প্রস্তাব করতে পারেন। সেটি যে ভালো উপায় হতে হবে তা নয়, শুধু একটি রীতিসম্মত বিকল্প হলেই চলে। এতে প্রস্তাবটি ব্যবহার করবেন কি না, সেই সিদ্ধান্ত শিক্ষার্থীর কাছেই থাকে; তবে অন্তত শিক্ষার্থীর কাছে বেছে নেওয়ার জন্য আরও বিকল্প থাকে।
আদর্শগতভাবে, কোনো ভাষা শেখা কখনও থামানো উচিত নয়, এমনকি যে ভাষা আপনি ইতিমধ্যে জানেন সেটিও নয়। কিছু ভাষা কয়েক সপ্তাহ বা মাস পরপর একটি নতুন সংস্করণ প্রকাশ করে। শেখার জন্য নতুন ফিচার তো থাকতেই পারে, আবার আগে থেকেই থাকা এমন কিছু ফিচারও থাকতে পারে যা সম্পর্কে আপনি জানেন না। কখনও কখনও শিক্ষার্থী এমন একটি ফিচার ব্যবহার করতে পারে যা আপনি জীবনে প্রথমবার দেখছেন। তাই মেন্টরিং কোনো ভাষা সম্পর্কে আরও জানার একটি ভালো উপায় হতে পারে।
আপনি যতগুলো ভাষায় স্বাচ্ছন্দ্য বোধ করেন, ততগুলোতেই মেন্টরিং করতে পারেন। যে একাধিক ভাষায় আপনি নিজেকে শক্তিশালী মনে করেন, সেইসাথে এখনও যে ভাষা শিখছেন, সবগুলোতেই মেন্টরিং করা ঠিক আছে।
কোনো সমাধান নিয়ে সেই মুহূর্তে বলার মতো গুরুত্বপূর্ণ বা গঠনমূলক কিছু না পেলে, সেই মেন্টরিং রিকোয়েস্টটি অন্য একজন মেন্টরের জন্য রেখে দেওয়াই শিক্ষার্থীর জন্য ভালো হতে পারে, যদিও উত্তর পেতে সেই শিক্ষার্থীকে আরও বেশি সময় অপেক্ষা করতে হয়।
শিক্ষার্থী যদি নির্দিষ্ট কোনো প্রশ্ন করে যা আপনি উত্তর দিতে পারেন না, তবে তার প্রশ্নের উত্তর দিতে পারে এমন কারও জন্য সেটি রেখে দিতে চাইতে পারেন।
নাহলে, সমাধানটি এমন কোনো অনুশীলনীর হতে পারে যা আপনার কাছে কঠিন ছিল, যা হয় আপনি সমাধান করেননি, অথবা করেছিলেন কিন্তু ভালোভাবে করতে পারেননি বলে মনে হয়েছিল। সেক্ষেত্রে, আপনি সমাধানটি একবার দেখে নিতে পারেন, তাতে শেখার মতো কিছু আছে কি না। কিছু থাকলে, তাদের সমাধান থেকে আপনি ঠিক কী শিখলেন, সে জন্য শিক্ষার্থীকে ধন্যবাদ জানাতে পারেন।
অথবা আপনি চাইতে পারেন যে শিক্ষার্থী নিজের সমাধানটি আপনার কাছে ব্যাখ্যা করুক। এটা এক ধরনের "উল্টো মেন্টরিং", তবে অনেক শিক্ষার্থী ভদ্রভাবে ও সম্মানের সাথে অনুরোধ করলে নিজের সমাধান ব্যাখ্যা করতে খুশিই হয়। এরপর আপনি জিজ্ঞেস করতে পারেন, তারা অন্য কোনো পদ্ধতির কথা ভেবেছিল কি না এবং কেন এই পদ্ধতিটিই বেছেছিল।
অথবা, সামগ্রিকভাবে সমাধানটি আপনার এখনও বুঝতে না-ও পারে, তবুও কিছু বিষয় চোখে পড়তে পারে যা নিয়ে কথা বলা যায়।
উদাহরণস্বরূপ, যদি তারা শুধু 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-এর মতো অনুশীলনী দিয়ে এসব বিষয়ে ভাবতে শুরু করুক। অথবা আপনি হয়তো উপযুক্ততার সব বিবেচনা দিয়ে একজন নতুন শিক্ষার্থীকে ভয় দেখাতে চাইবেন না। অন্যদিকে, আরও উন্নত অনুশীলনী করছে এমন শিক্ষার্থীরা হয়তো কনভেনশনগুলো আগেই জানে, তবুও হাতের কাজে মন দিতে গিয়ে সেগুলো এড়িয়ে যায়। কনভেনশন নিয়ে বারবার জোর দেওয়া তাদের কাছে খুঁটিনাটি ধরার মতো অপছন্দের মনে হতে পারে। কোনো ভাষায় এক বা একাধিক ফরম্যাটার বা লিন্টার থাকলে, সেগুলো পরিচয় করিয়ে দেওয়ার জন্য একটি অনুশীলনী বেছে নেওয়া ভালো হতে পারে। নাহলে, কোনো নির্দিষ্ট কনভেনশন ভাঙা সত্যিই খারাপ হলে, যেখানেই তা ঘটুক সেটি তুলে ধরতে চাইতে পারেন। মেন্টরদের মধ্যে মতভেদ হতে পারে কোনটিকে "সত্যিই খারাপ" ধরা হবে সেই বিষয়ে।