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