अगर आपके जूनियर ने आपके सुझाव को नहीं अपनाया तो आपको क्या करना चाहिए? [बन्द है]


30

मैं 3-4 जूनियर डेवलपर्स की टीम का नेतृत्व कर रहा हूं। मेरा काम-- कोड लिखने के अलावा-- जूनियर्स के लिए पर्यवेक्षण और मार्गदर्शन प्रदान करना है।

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

जब वे मेरे पास आते हैं, तो कभी-कभी मुझे समस्या को हल करने के लिए एक पूरी तरह से अलग एल्गोरिथ्म का प्रस्ताव करना होगा क्योंकि उनका एल्गोरिदम पर्याप्त मजबूत नहीं है (याद रखें, मैं वरिष्ठ हूं और मैंने उनसे अधिक देखा है)। निश्चित रूप से मैं इसे अच्छे तरीके से समझाऊंगा ताकि उनकी भावनाओं को ठेस न पहुंचे, और मैं धीरे-धीरे यह बताऊंगा कि मेरा समाधान उनकी तुलना में कैसे बेहतर है, कोई कृपालु स्वर या निंदा शब्द नहीं।

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

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


9
प्रोग्रामर अभिमानी हैं। क्या आप आश्वस्त हैं कि आपका समाधान बेहतर है क्योंकि यह है या क्योंकि आपने इसे विकसित किया है? यदि आपने वास्तव में कनिष्ठ डेवलपर्स को उनकी विधि के लिए कारण दिया है तो यह संभवतः "यह मेरा तरीका है" परिदृश्य बन जाना चाहिए।
रिग

6
हाय ग्रेविटन, इस तरह के सामान्य कार्यस्थल के मुद्दे यहां विषय पर नहीं हैं: आप एक आगामी साइट प्रस्ताव, व्यावसायिक मामलों में रुचि रख सकते हैं , जहां इस तरह के सामान्य पेशेवर प्रश्न ऑन-विषय होंगे।

27
@MarkTrapp: क्या आप अपने तर्क पर विस्तार से विचार करेंगे कि आप प्रोग्रामर के टीम नेतृत्व को विषय के रूप में क्यों मानते हैं? शायद इस सवाल को बंद करने के बजाय अगर एक आम सहमति है तो इसे स्टैकऑवरफ्लो में स्थानांतरित किया जा सकता है, या जब यह उपलब्ध हो जाता है तो खुले और बाद में व्यावसायिक मामलों में माइग्रेट किया जाता है। IMHO, मुझे लगता है कि यह एक सॉफ्टवेयर डेवलपर के रूप में रुचि का विषय है, और दिए गए प्रबंध प्रोग्रामर प्रोग्रामिंग के लिए अद्वितीय है, मैं इस विषय पर निश्चित रूप से मानता हूं। धन्यवाद।
S.Robins

35
ऐसा क्यों है कि सबसे दिलचस्प सवाल बंद हो जाते हैं?
थॉमसएक्स

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

जवाबों:


28

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

यह दृष्टिकोण निम्नलिखित कारणों से महत्वपूर्ण है:

  • आप चाहते हैं कि वे ठोस व्यवसाय / तकनीकी कारणों की वजह से बदलाव लाएं। यह स्पष्ट होना महत्वपूर्ण है कि ये क्या हैं (कोई भी याद रखें कि आप भी गलत हो सकते हैं, इसलिए विनम्र रहें ...)।
  • आप वास्तव में अपने सुझाव के पीछे तर्क देना चाहते हैं - इस तरह प्राप्तकर्ता भविष्य में इसी तरह की समस्याओं को हल करना सीख जाएगा। यदि आपके कनिष्ठों को लगता है कि वे आपसे कुछ अच्छी अंतर्दृष्टि सीख रहे हैं, तो आपके पास एक बेहतर संबंध होगा।
  • यदि आप अपनी वरिष्ठता का उपयोग करते हैं तो आप सम्मानित नहीं होंगे और यह प्रदर्शित नहीं कर सकते कि आपके पास वास्तव में अच्छे कारण हैं।
  • आपका बॉस निश्चित रूप से आश्वस्त होना पसंद करेगा कि आप अपने जूनियर्स के समय का उपयोग उन चीजों पर प्रभावी ढंग से कर रहे हैं जो वास्तविक मूल्य पैदा करती हैं, न कि केवल इसके लिए "ऐसा करने से मेरा रास्ता"।

अगर आप होशियार हैं, तो आप उनसे सिर्फ सवाल पूछकर जवाब देने के लिए भी आ सकते हैं । सही किया, आपका जूनियर खुद सही निष्कर्ष पर आएगा (और इसलिए इसे लागू करने के लिए बहुत अधिक तैयार है)। उदाहरण प्रश्न:

  • आपका कोड उत्पादन डेटाबेस तक पहुँच मानता है। हम इसे कैसे बदल सकते हैं ताकि यह अभी भी काम करेगा और डिस्कनेक्ट किए गए विकास के माहौल में JUnit द्वारा सही तरीके से परीक्षण किया जा सके? (संभावित उत्तर: आह! हमें निर्भरता इंजेक्शन का उपयोग करना चाहिए ....)
  • यदि आपके ऑनलाइन डेटा प्रविष्टि फॉर्म में किसी हमलावर ने जानबूझकर निर्मित चतुराई से SQL भेजा है तो क्या होगा? (संभावित उत्तर: आह! शायद हम इंटर्नेट से असत्यापित पाठ को संक्षिप्त करके SQL स्टेटमेंट का निर्माण नहीं करना चाहिए)

संपादित करें : यदि आप अपने जूनियर को यह समझाने में सफल होते हैं कि आपके सुझाव का पालन करना सही है, लेकिन वे अभी भी अनिच्छुक हैं, तो कुछ अतिरिक्त सलाह हैं:

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

जब मैंने अपना टाइप करना शुरू किया तो मुझे आपका उत्तर नहीं मिला! तो मेरे से +1, क्योंकि आपने जो कुछ भी मेरे बारे में लिख रहा था, उसका सार पकड़ लिया है, केवल अधिक सुरुचिपूर्ण ढंग से और संक्षिप्त रूप से। ;-)
S.Robins

@ मायिकरा, वे सहमत हैं कि मेरा समाधान बेहतर है, बस, वे पुराने कोड को छोड़ने और नए कोड में निवेश करने के लिए अनिच्छुक हैं।
ग्रेविटन

कोई काला या सफेद नहीं है। लोग मामूली बातों के बारे में समझ सकते हैं। वे इंसान हैं, रोबोट नहीं। इसलिए यद्यपि मैं सहमत हूं कि स्पष्ट रूप से और अपनी बात को स्पष्ट रूप से व्यक्त करना महत्वपूर्ण है, राजनयिक होने का प्रयास करें। लोगों को रिझाने के लिए पूरा साहित्य है। यह अपने आप में एक विज्ञान है। एक en.wikipedia.org/wiki/How_to_Win_Friends_and_Influence_People
siamii

8

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

स्वतंत्रता और समय सीमा के बीच एक व्यापार होना चाहिए। आपके पास समय सीमा बढ़ाने का विलास नहीं है और आप अपने जूनियर्स को इसे भंग नहीं करने दे सकते। आपको उनके साथ विनम्र लेकिन दृढ़ रहना चाहिए कि एक बार जब वे अपने एल्गोरिथ्म की कोशिश कर चुके हैं और काम नहीं कर रहे हैं, तो उनका कर्तव्य है कि वे आपकी बात सुनें। उदाहरण के लिए साबित करें कि आप अपना सामान जानते हैं। लेकिन, उतना ही महत्वपूर्ण है उन्हें सीखना, न उन्हें सिखाना।


5

यदि यह एक आवश्यकता है, तो इसे उस रूप में नोट करें। यदि यह केवल एक सुझाव है, जैसा कि आप ध्यान दें, तो उन्हें ऐसा करने के लिए स्वतंत्र होना चाहिए। कुछ प्रश्न मैं पूछूंगा:

  • क्या आपके पास विशिष्ट समाधानों के लिए धक्का देने का अधिकार है?
  • उस प्राधिकरण के लिए क्या सीमा है?
  • क्या समाधान बुरा है या सिर्फ अलग है?

मुझे यकीन है कि आप अधिक पूछ सकते हैं, लेकिन पहले दो अपने अधिकार पर ध्यान केंद्रित करते हैं और आखिरी यह कि क्या मुद्दा वास्तव में धक्का देने लायक है।

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


मेरे पास अधिकार है, लेकिन मैं इसका उपयोग नहीं करना पसंद करता हूं
Graviton

प्राधिकरण निश्चित रूप से दोधारी तलवार है। अपनी नाराजगी की तुलना में अपने साथियों का समर्थन करना बेहतर है। एक समावेशी प्रक्रिया में संलग्न होने में विफलता अक्सर आपके अधिकार की चुनौतियों का कारण बनती है, और यदि आप अपने अधिकार को शामिल करने के लिए अपने स्वयं के प्रबंधक को शामिल करने की आवश्यकता के साथ फंस गए हैं, तो आपने भविष्य को उलझाने का कोई भी मौका खो दिया है इसी तरह की परिस्थितियों में अपने जूनियर्स के साथ।
S.Robins

1
"निम्नलिखित उत्तर"। उत्तर किसी विशेष क्रम में दिखाए जाने की उम्मीद नहीं की जा सकती। एक URL पाने के लिए "लिंक" लिंक का उपयोग करें जिसे आप अपने उत्तर में संदर्भित कर सकते हैं।

4

सीखना वास्तव में केवल वही होता है जहाँ असफलताएँ होती हैं, क्योंकि असफलता प्रेरक होती है और भविष्य में याद रखने के लिए स्मृति संकेत प्रदान करती है। यह अनिवार्य रूप से जिसे हम अनुभव कहते हैं, और कार्यस्थल में अच्छा अनुभव विफल होने और असफलताओं से सीखा होने से आएगा। यदि आपके जूनियर्स पहली बार सब कुछ सही करने में सक्षम थे, या तो वे कुछ भी नहीं सीख रहे होंगे, या वे जूनियर नहीं होंगे।

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

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

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

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

हां, समय कई बार कीमती होता है, हालांकि जब आप जूनियर्स को लेने के लिए चुनते हैं, तो आपको यह स्वीकार करने की आवश्यकता होती है कि आप अपने पेशेवर विकास में निवेश करने और पोषण करने की जिम्मेदारी ले रहे हैं, और आपको यह स्वीकार करने की आवश्यकता है कि परिणामस्वरूप यह थोड़ी देर के लिए होगा कम से कम आप समय खर्च करते हैं।


4

यदि आप वास्तव में आपके सुझाव को इस तरह से प्रस्तुत कर रहे हैं तो मैं सवाल करूंगा कि आप कृपालु नहीं हैं। जब आप वाक्यांशों का उपयोग कर रहे हैं जैसे:

मेरा समाधान उनके मुकाबले काफी बेहतर है

तथा

मेरे दिल में गहराई से मुझे पता है कि मेरा एल्गोरिथ्म उनकी तुलना में बहुत बेहतर है और उन्हें बस इसे अपनाना चाहिए।

यह मुझे लगता है कि आप "मेरा रास्ता बेहतर है" के दृष्टिकोण के साथ आ सकते हैं। किसी भी व्यक्ति को यह रवैया पसंद नहीं है। जब मैंने इसे अतीत में प्राप्त किया है, तो मैं सक्रिय रूप से व्यक्ति को गलत साबित करने के लिए एक अलग एल्गोरिथ्म का उपयोग करने के लिए अपने रास्ते से बाहर चला गया हूं। यह हो सकता है कि आपके जूनियर ऐसा ही कर रहे हों।

एक बेहतर तरीका यह होना चाहिए कि वह व्यक्ति के साथ बैठकर उनके एल्गोरिथ्म पर चर्चा करे। इंगित करें कि आपको क्यों नहीं लगता कि यह काम करेगा, और उन उत्तरों को सुनें जो वे आपको खुले दिमाग से देते हैं। देखें कि उनके एल्गोरिथ्म को सही ढंग से काम करने के लिए संशोधित किया जा सकता है या नहीं।

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


3

सबसे पहले, क्या आप जानते हैं कि आपके जूनियर ने आपके सुझाव को क्यों नहीं अपनाया?

कभी-कभी आप जानते हैं, एक जूनियर वास्तव में नए दृष्टिकोण और सीएस शिक्षा की तारीख के कारण अपने वरिष्ठ से बेहतर कुछ लिख सकता है। यद्यपि एक वरिष्ठ के रूप में आपने वास्तविक दुनिया के और उदाहरण देखे होंगे। लेकिन एक बुरा जाल मैं अक्सर अपने सीनियर्स को देखता हूं कि कभी-कभी यह भूल जाता है कि समय के साथ सर्वोत्तम अभ्यास बदल सकते हैं। मुझे यकीन है कि यह आपके लिए लागू नहीं होता है, क्योंकि आप इन जैसी साइटों पर खुद को अपडेट कर रहे हैं। ;)

मैं सुझाव दूंगा कि आप अपने जूनियर्स को बिना किसी (या थोड़ा) वरिष्ठ के "आभा" के पास जाने की कोशिश करें, उनके साथ स्तरीय शब्दों में बात करने की कोशिश करें, उनके द्वारा लिखे गए कोड में उत्सुकता दिखाएं। सवाल पूछें, उनकी प्रतिक्रियाएं सुनें। ऐसे तरीके से मत पूछिए:

"आपका कोड बहुत अचूक है, आपको इसे इसे बदलने की आवश्यकता है ..."

इसके बजाय पूछें

"मैं बस सोच रहा था, क्या होगा अगर कोई था ... क्या आपका कोड इसे संभालने का प्रबंधन करता है? ... मुझे लगता है कि एक रणनीति पैटर्न यहां मदद कर सकता है। आपको क्या लगता है?"

यह मुझे विश्वास है कि आप एक प्रोफेसर / व्याख्याता की तरह उनके साथ अधिक स्वस्थ वार्तालापों को उलझाने में उनकी मदद करेंगे जो उन्हें यह सब जानते हुए भी पसंद कर रहे हैं। यह आपको उनके तर्क और दृष्टिकोण को बेहतर ढंग से देखने में भी मदद करेगा।


2

क्या आप रिपॉजिटरी में पुश एक्सेस को नियंत्रित करते हैं?

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

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

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

यदि आप उनकी कोडिंग तकनीकों के बारे में कंबल बयान कर रहे हैं, तो एक बहुत अच्छा मौका है कि आप उनकी पसंद के पीछे के तर्क को पूरी तरह से नहीं समझ पाएंगे। बस आपके सवाल का स्वर आपको अभिमानी बनाता है। युवा डेवलपर्स पर अपने दृष्टिकोण को आगे बढ़ाकर आप क्या हासिल / त्याग करते हैं?

अपने आप से पूछने के लिए महत्वपूर्ण प्रश्न यह है कि क्या आपके सुझाव कोडबेस की गुणवत्ता को बनाए रखने / सुधारने या अपने साथियों पर अपने प्रभुत्व / श्रेष्ठता को बनाए रखने के लिए तैयार हैं? पूर्व सरल गुणवत्ता नियंत्रण है और इस तरह से उचित ठहराया जा सकता है, सीढ़ी टीम के लिए हानिकारक है कि क्या आपका अधिकार है या नहीं।

किसी भी तरह से, यदि आप अपने समाधान को अपने साथियों पर धकेलना चाहते हैं तो आपके पास ठोस सबूत होना चाहिए कि यह वास्तव में श्रेष्ठ है। प्रदर्शन में वृद्धि में सुधार करने के लिए पर्याप्त आसान होना चाहिए, कुछ भी कम प्रयास के लायक नहीं है (प्रदर्शन महत्वपूर्ण अनुप्रयोगों को छोड़कर)। अपनी व्यक्तिगत समझदारी को सही ठहराने के लिए दूसरों पर अपना काम करने के लिए मजबूर करने से आप समाप्त हो जाएंगे, क्योंकि वे 'क्रोचेटी ओल्ड मैन' के रूप में गाए जाएंगे।

नोट: सबसे अच्छा और सबसे प्रतिभाशाली प्रोग्रामर जो मैंने वर्षों से सामना किया है, हमेशा ऐसा लगता था कि वे पीछे की कहानी को रोकने और समझाने के लिए तैयार थे जहां उन्होंने अपना दृष्टिकोण उत्पन्न किया।


2

अच्छी तरह से यह युवा प्रोग्रामर के साथ दिलचस्प और बहुत स्वाभाविक लगता है, जो उनके द्वारा लिखे गए कोड से बहुत जुड़ा हुआ है, हो सकता है कि उन्होंने उसी समय पहुंचने में काफी समय बिताया हो या उन्होंने इसे किसी अच्छी साइट से लिया हो (इसलिए वास्तव में, अरे जॉन स्कीट ने इसे लिखा था। आदमी ! !)।

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

ध्यान रखें कि कुछ विफलताएं प्रख्यात हैं (किसी भी लगाव के लिए कुछ दिल टूटने की आवश्यकता है) लेकिन धीरे-धीरे प्रयास से मुझे लगता है कि वे चारों ओर आएंगे और आपके प्रयासों को बेहतर ढंग से सराहना कर पाएंगे। थोड़ा समय और कुछ असफलताएं हैं जो मुझे लगता है कि आपको आवश्यकता होगी। यह उन पर मजबूर करने के लिए कुछ सफलता की कहानियों और फिर प्रलय और विद्रोह के दूसरे रास्ते होंगे।


2

हर किसी का अलग अंदाज होता है। यदि आप 10 अलग-अलग लोगों को ढूंढते हैं और उन्हें एक nontrivial समस्या के साथ पेश करते हैं, तो वे आपको 10 अलग-अलग "कोडिंग मानकों" शैलियों का उपयोग करके 10 अलग-अलग दृष्टिकोण देने जा रहे हैं।

बात यह है: सामान है कि मायने रखती है उठाओ। यदि कोई चीज आपके लिए एक कनिष्ठ द्वारा प्रस्तुत की जाती है जो सही समाधान का उत्पादन नहीं करता है, तो क्या यह अत्यधिक अक्षमता है (परिमाण का +1 क्रम, यहां या वहां कोई निर्देश नहीं), या एक सुरक्षा छेद बनाता है, फिर अपना मुद्दा और क्यों समझाएं। यदि यह "मैंने यह" टिप्पणी की है, तो यह बहुत अच्छा है, आपने "वह" किया होगा और उसने "कुछ और" किया होगा, लेकिन समस्या अभी भी पर्याप्त रूप से हल हो गई है (उपरोक्त बिंदुओं को देखें)। अगली सुविधा पर जाएं या ठीक करें।

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

संपादित करें: सुनिश्चित करें कि आपके सुझाव वास्तविक हैं और न कि नक्काशीदार आवश्यकताएं। एक सुझाव सिर्फ यह है कि एक ऐसा सुझाव, जिसका पालन करने के लिए कोई स्वतंत्र है या नहीं। यदि यह एक आवश्यकता है, तो इसे इस तरह से बताएं।


2

जैसा कि कुछ अन्य लोगों ने बताया है, यदि आप वास्तव में कनिष्ठ डेवलपर्स को सुझावों के साथ साबित कर रहे हैं और वे इस तरह से काम कर रहे हैं, तो आप वास्तव में उन पर नाराज होने के लिए बहुत आधार नहीं रखते हैं यदि वे इसका पालन नहीं करते हैं क्योंकि वे हो सकते हैं ऐसा करने के लिए ज्यादा कारण नहीं देखें। इसी तरह, आप वास्तव में उन्हें अपने सुझाव का पालन नहीं करने के लिए एक बार नहीं जा सकते क्योंकि वे चीजों को एक निश्चित तरीके से करने के लिए वास्तविक दिशा नहीं हैं।

कनिष्ठ डेवलपर्स को चीजों को करने की कोशिश करने के संबंध में जैसा कि आप उन्हें करना पसंद करेंगे:

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

2

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

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


2

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

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

आदेश दीजिए। नतीजों के साथ जिएं। अनुभव से सीखें। सम्मान एक दो तरफा सड़क है। आप इसे प्रदर्शित कर रहे हैं और वे नहीं कर रहे हैं।


मैं इसे एक लाख बार बढ़ाऊंगा।
एचएलजीईएम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.