यदि आप किसी वरिष्ठ डेवलपर से सलाह लेना बुरा मानते हैं, तो आप कैसे बताएंगे? [बन्द है]


266

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

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

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

मेरा सवाल यह है कि अगर किसी वरिष्ठ डेवलपर की सलाह अच्छी, बुरी या शायद अच्छी हो, लेकिन आज के संदर्भ में पुरानी हो गई है तो मैं बेहतर जज का क्या कर सकता हूं? और अगर यह बुरा / पुराना है, तो मैं इस बात का इस्तेमाल कैसे कर सकता हूं कि मैं अपने 'दबाव' के बावजूद इसे इस तरह से लागू नहीं कर पाऊं कि मैं उन्हें एक वरिष्ठ के रूप में सम्मान दूं?


26
आप सफलताओं से ज्यादा गलतियों से सीखते हैं।
स्टुपेरयूज़र

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

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

6
@peterallenweb, वास्तव में सलाह की गुणवत्ता की परवाह किए बिना 3 बार पूछा जाना बुरा है। मुझे लगता है कि यहां की टिप्पणियों से मुझे लगता है कि विभिन्न टीमों में काम करने के संदर्भ में मुझे बहुत कुछ सीखना है। :)
learnjourney

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

जवाबों:


233

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

  1. निर्णय को समझने के लिए कनिष्ठ के पास सारी जानकारी नहीं होती है क्योंकि इसे बनाया गया है। कुछ मामलों में, थोड़ा स्पष्टीकरण डेवलपर को अतीत की चिंता को दूर करने और एक विषम परिस्थिति से निपटने में मदद कर सकता है।
  2. जूनियर को बीएडी की जानकारी है। यह मत भूलो कि तुम वास्तव में एक कनिष्ठ हो। यह सॉफ्टवेयर के संदर्भ में एक किशोर होने के बराबर है। मुझे यकीन है कि आपके पास बहुत सारे शानदार विचार हैं, लेकिन यह संभव है कि आप सब कुछ नहीं जानते। मुझे लगता है कि सबसे प्रतिरोधी जूनियर डेवलपर्स वे हैं जो दृढ़ता से मानते हैं कि वे जानते हैं कि कोड, कंपनी, दुनिया के लिए सबसे अच्छा क्या है। विनम्रता प्राप्त करके इन डेवलपर्स को बेहतर सेवा दी जाती है।
  3. कुछ विशेष करने का निर्णय वरिष्ठ के सिर के ऊपर किया गया था। वरिष्ठ अभी भी अंत में किसी और के लिए काम करता है। कुछ करने के लिए वास्तव में एक बेहतर तरीका हो सकता है, कुछ लिखने के लिए एक अधिक कुशल तरीका, या बेहतर सॉफ्टवेयर / हार्डवेयर काम करने में मदद करेगा। व्यापार हालांकि अभी भी निर्णय लेता है। व्यवसाय प्रबंधक, निदेशक, वीपी, आदि अक्सर निर्णय लेते हैं जो विकास प्रक्रिया को प्रभावित करते हैं। ये सीनियर के नियंत्रण से परे हैं, और जब जूनियर्स इसके बारे में शिकायत करते हैं, तो वे जो कुछ कर रहे हैं वह सीनियर के तनाव में शामिल हो जाता है।
  4. वरिष्ठ सिर्फ फ्लैट आउट करने के लिए इसे ध्यान में रखने का समय नहीं है। समय-सीमा है, और कभी-कभी बदलते पैटर्न, प्रथाओं और मिडस्ट्रीम व्यवहार उस समय सीमा तक महंगा है। चूँकि यह चॉपिंग ब्लॉक पर उसकी गर्दन है, इसलिए उत्पाद को कार्यात्मक रूप से प्राप्त करने के लिए और "पूरी तरह से लिखे गए" की तुलना में समय पर अधिक महत्वपूर्ण है।

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

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

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

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


47
@Joel अच्छा जवाब, लेकिन "एक तरफ टॉस" चिंताओं से सावधान रहें। चिंताओं को हमेशा स्वीकार किया जाना चाहिए भले ही वे अमान्य हों, भले ही आपके पास सबसे अच्छी प्रतिक्रिया है "मैं आपकी चिंता समझता हूं, लेकिन अभी हमें वाई की वजह से एक्स करना है"। बयाना विचारों की पूर्णविराम बर्खास्तगी एक नैतिक हत्यारा है और अंततः संस्कृतियों के सबसे स्वस्थ को भी नष्ट कर सकता है।
रीइन हेनरिक

42
@ जॉयल: बहुत सारे अच्छे अंक, लेकिन यह थोड़ा सा कृपालु है: "यह सॉफ्टवेयर शब्दों में एक किशोर होने के बराबर है।" एक सम्मान जो जूनियर डेवलपर्स से कमाता है वह लगातार अच्छे निर्णय लेने से जीता है - उम्र या वरिष्ठता के मात्र तथ्य से नहीं।
नील जी

26
यह जवाब देने के करीब नहीं आता है कि आप कैसे जानते हैं कि एक वरिष्ठ डेवलपर "अच्छा" है या नहीं। यहाँ कहा गया उत्तर ऐसा प्रतीत होता है, "इससे कोई फर्क नहीं पड़ता कि वह क्या कहता है।" मैं यह नहीं कह रहा कि गलत सलाह है; मैं सिर्फ यह कह रहा हूं कि यह सवाल का जवाब नहीं देता है। क्या यह लायक है के लिए मुझे लगता है कि एकमात्र सही उत्तर है, आपको पता चल जाएगा कि क्या वह 5 साल में अच्छा है जब आप एक वरिष्ठ हैं।
केविन

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

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

35

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

कहा जा रहा है, अपनी चिंताओं को प्रस्तुत करने में संकोच न करें, जब आप पहले से ही एक समस्या का सामना करते हैं।

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


29
ओपी - आप दोनों पेशेवर हैं, भले ही आपके पास कम अनुभव हो, इसलिए आपके साथ उन चीजों के बारे में एक पेशेवर चर्चा करें जिनसे आप सवाल करते हैं। अगर वह इस बारे में बात करने को तैयार नहीं है यही कारण है कि उसके निर्देशों का है, वह एक संरक्षक के ज्यादा नहीं है।
डेवई

10
+1 के लिए "वह आपके द्वारा की गई परियोजना की सफलता के लिए अधिक है"। यह कितना सच है। मुझे पता है कि आप जूनियर डेवलपर्स की सराहना नहीं करते हैं कि आप कितने भाग्यशाली हैं कि आपके ऊपर उस तरह का तनाव नहीं है क्योंकि मुझे यकीन है कि जब मैं एक जूनियर डेवलपर नहीं था। अब मेरे लॉन से निकलें!
maple_shaft

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

4
@DaveE: लगता है जैसे वे पहले ही चर्चा कर चुके हैं और ओपी के पास अभी पर्याप्त संदर्भ नहीं है कि वर्तमान में वरिष्ठ के ज्ञान को समझ सकें। कभी-कभी केवल इतना ही होता है कि आप समझा सकते हैं कि बाकी को अनुभव से आने की आवश्यकता होगी।
मार्टिन यॉर्क

2
@ निफ़रा: संभव। लेकिन अधिक सटीक जानकारी के बिना मैं यह मानने के लिए अधिक इच्छुक हूं कि यह सिर्फ एक भोली शिक्षार्थी है जिसे वह जितना सोचता है उससे कम जानता है। अधिकांश वरिष्ठ वास्तव में जानते हैं कि वे क्या कर रहे हैं (आप एक वरिष्ठ इंजीनियर नहीं बनते हैं यदि आप बेवकूफ हैं जो आप इसके बजाय प्रबंधन में जाते हैं)।
मार्टिन यॉर्क

24

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

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

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


4
बातचीत करने के लिए +1। वरिष्ठ डेवलपर विभिन्न चिंताओं को संतुलित करने के लिए बेहतर (और जिम्मेदार) हो सकता है, लेकिन उसे अपने कारणों की व्याख्या करने में सक्षम होना चाहिए। अपने आप को जूनियर्स को समझाते हुए, इसलिए वे सीख सकते हैं, एक वरिष्ठ होने का एक बड़ा हिस्सा है। और यदि आप एक जूनियर के रूप में ऐसा महसूस नहीं करते हैं कि आप सीख रहे हैं, तो शायद नौकरियों को बदलने का समय आ गया है।
जाप

सबसे अच्छा एक पर एक के लिए +1। असहमति का समय बंद दरवाजों के पीछे है। जब दरवाजा खुलता है और चर्चा खत्म हो जाती है तो कोई तोड़-फोड़ नहीं होनी चाहिए, कोई कमतर नहीं, कोई रोना नहीं होना चाहिए। जब तक आप उस बिंदु तक नहीं पहुंचते, तब तक दरवाजा न खोलें। यदि आप अभी भी असहमत हैं, तो वरिष्ठ को उसके चेहरे को बताएं कि आप उसे अपने पर्यवेक्षक को बुलंद करना चाहते हैं।
माइकल रिले - AKA Gunny

18

जिस तरह से आप अक्सर बताते हैं वह एक सामान्य ज्ञान दृष्टिकोण के माध्यम से है। ध्यान रखें कि वरिष्ठ डेवलपर परियोजना के बारे में अधिक जान सकता है, लेकिन चीजों को करने के सही तरीके के बारे में अधिक नहीं जान सकता है। आपको यह बताना होगा कि वह आपसे क्या करने के लिए कहता है - वह आपको बुरी सलाह दे रहा है यदि वह कहता है कि उसके दांव क्या हैं, तो वह उड़ता है (यानी लोग उससे अधिक वरिष्ठ हैं; जरूरी नहीं कि आपकी कंपनी में ... मैं बात कर रहा हूं; प्रसिद्ध "सेलिब्रिटी" डेवलपर्स जो अक्सर सॉफ़्टवेयर विकास करने के सही तरीके के बारे में या बहुत कम उद्योग-स्वीकृत व्यवसाय प्रथाओं में किताबें पोस्ट या लिखते हैं)।

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

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

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

अत्यंत पक्षपाती दृष्टिकोण के लिए पूरी तरह से डाउनवोट / असहमति की उम्मीद करना।


मुझे स्वीकार करना होगा कि मैं वास्तव में हैरान हूं कि मेरे पास सात अपवोट्स हैं (अब के रूप में) और कोई डाउनवोट्स नहीं हैं। मैंने सोचा होगा कि मेरा रवैया / निराशावादी नज़रिया / भद्दी आवाज़ लोगों के साथ अच्छी तरह से नहीं बैठती होगी :)
वेन मोलिना

स्लैशडॉट पर, यह घोषणा करते हुए कि आपको उम्मीद की जाती है कि आप नीचे दिए गए कर्म-वेश्याओं में एक आजमाई हुई तकनीक है।
कार्सन63000

मुझे कोशिश करनी होगी कि अधिक बार जम्मू / कश्मीर :)
वेन मोलिना

11

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

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

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

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


11

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

अधिकांश डेवलपर्स कॉलेज छोड़ने पर पढ़ना बंद कर देते हैं। आपने ऐसा नहीं किया है, इसलिए आप पहले से ही शीर्ष 10% में हैं। इन दिनों काफी अवसर है। यदि आपके शहर में कोई नौकरी का बाजार नहीं है, तो एक बेहतर शहर की तलाश करें।


9
ब्लाइंडली केवल यह कहने के लिए "हमें उद्योग को सर्वोत्तम अभ्यास करने की आवश्यकता है" एक चर्चा खोलने का सबसे अच्छा तरीका नहीं हो सकता है। अन्य लोगों की तुलना में कुछ और करने का बहुत अच्छा कारण हो सकता है।

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

2
@PeterAllenWebb, "सक्षम होना चाहिए", हां, लेकिन आप जरूरी नहीं कि घंटे के बारे में बहस करने के बाद विस्तार से बताएं कि आपने किसी दिए गए अभ्यास को आपके लिए बुरा क्यों माना है। कभी-कभी, "क्यों?" का उत्तर "क्योंकि" के साथ दिया जा सकता है।

@ थोरबजर्न रावन एंडरसन: मैं मानता हूं, जब तक यह सामयिक है।
पीटरअलेनवेब

11

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


मैं आपकी सोच की सराहना करता हूं, लेकिन मैं भविष्य और सट्टा से डरता हूं क्योंकि अधिक कठिन परिस्थितियां हो सकती हैं, जिसमें मंचों पर पोस्ट करने से मदद नहीं मिल सकती है। तब मुझे क्या करना चाहिए?
डेवलेपर

4
किताबों में खोदो और गहराई से सीखो। इंटरनेट सीखने का एकमात्र तरीका नहीं है। एक स्थानीय डेवलपर समूह में शामिल हों और अधिक वरिष्ठ लोगों के साथ संपर्क बनाएं जिन्हें आप संरक्षक के लिए प्राप्त कर सकते हैं।
HLGEM

यह अच्छा है।
डेवलेपर

9

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

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


6
एक जूनियर डेवलपर के रूप में इस प्रकार की तानाशाही मुझे पागल कर देती है। मैंने डाउन-वोट किया, सॉरी।
kizzx2

9

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

मुझे संदेह है, वह नहीं जानता। उसी समय, वह मुझे यह दिखाने की कोशिश करता है कि अहंकार इसलिए हो सकता है कि मैं उसे सवालों के लिए ज्यादा नहीं बताता।

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

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

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

हालाँकि, वह केवल मेरे कोड की समीक्षा करता है, और उसकी अधिकांश टिप्पणियां कोडिंग दिशानिर्देशों से संबंधित हैं

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

ऐसी स्थिति में मुझे क्या करना चाहिए?

मैंने इस स्थिति के बारे में अपने प्रबंधक को सूचित किया है, और मैंने उनसे अपनी लीड बदलने का अनुरोध किया है, हालांकि वह हर बार "हाँ" बताता है, लेकिन वह कोई गंभीर कार्रवाई नहीं करता है।

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

यहाँ कुछ सुझाव दिए गए हैं।

  1. अपनी स्थिति का पीछा न करें - आग से परीक्षण, जबकि मज़ेदार नहीं है, आपको अपने कैरियर में बाद के लिए कुछ महत्वपूर्ण शोध कौशल सिखाता है।
  2. अधिक शामिल होने के लिए अपने नेतृत्व को आगे बढ़ाना शुरू करें। इसे ध्यान से और सम्मानपूर्वक करें । धक्का देना जारी रखें और तब तक लगातार रहें जब तक वह अंदर न दे (यह वास्तव में जीवन में बहुत सारी स्थितियों के लिए काम करता है)।
  3. यदि आपकी लीड शामिल नहीं होगी , तो देखें कि क्या ऐसे अन्य लोग हैं जो आपकी मदद कर सकते हैं। जब तक आप एक पसीने की दुकान में काम कर रहे हैं, जो केवल दूध देने के घंटों से संबंधित है, तब आपकी कंपनी किसी अन्य डेवलपर को अधिक अनुभव नहीं देगी, जो आपको कुछ रस्सियों को दिखाएगा और आपके कोड की समीक्षा करेगा।
  4. किसी नए काम के लिए नज़र रखना शुरू करें। मैं यह नहीं कहूंगा कि आप "स्थिति को छोड़ दें" स्थिति में हैं, लेकिन यह आपके कैरियर को एक ऐसी जगह पर चोट नहीं पहुंचाएगा जो एक प्रोग्रामर के रूप में आपके विकास को गंभीरता से लेता है ।

बहुत बहुत धन्यवाद, आपके अंक वास्तव में अच्छे और विचारशील हैं। आप के लिए Upvote
डेवलेपर

धन्यवाद, मैंने आपका उत्तर चुन लिया है, क्योंकि यह सबसे अच्छा है।
डेवलपर १२

7

यदि आपके पास किसी विशेष समस्या को हल करने का एक बेहतर तरीका है, तो बस इसे करें

अपने कोड / समाधान को अपना सर्वश्रेष्ठ तर्क दें। अन्यथा आपको जो बताया गया है उससे चिपके रहें।

इसका स्पष्ट उदाहरण

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


11
@maple_shaft: कोड (और इसे बनाए रखने वाले) को वरिष्ठ देव भावनाओं की रक्षा करने के लिए किस तरह की टीम है?
जाप

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

2
यदि उसे पहले से ही इसे बदलने के लिए कहा गया है तो यह कोड समीक्षा में विफल रहा है। बस इसे फिर से जमा करने की कोशिश करने का मतलब है कि वह यह बताएगा कि यह पहले ही विफल हो गया है।
मार्टिन यॉर्क

2
@darknight, यह मानते हुए कि यह कोई छोटी बात नहीं है, मौजूदा कोडबेस पर प्रतिमान बदलने से कुछ गंभीर गड़बड़ी हो सकती है। इस तरह की बहसों के बारे में जब मेरे मन में विचार आता है तो वह होता है डेटाबेस स्ट्रक्चर। इस तरह से परिवर्तन सबसे निश्चित रूप से सराहना नहीं की जाएगी।
मॉर्गन हेरलॉकर

1
यह केवल बहुत छोटी इकाइयों के लिए लागू होता है। मान लें कि आपने दो सप्ताह तक काम किया है, और कोड को अस्वीकार कर दिया गया है - आप उन दो सप्ताह के लिए धन कैसे प्राप्त करेंगे?

7

बेशक एक अनुभवहीन डेवलपर के रूप में, मैं गलत हो सकता हूं और उसका तरीका बेहतर हो सकता है, इसलिए मेरा सवाल यह है कि मैं बेहतर जज करने के तरीके क्या कर सकता हूं अगर एक वरिष्ठ डेवलपर की सलाह अच्छी या बुरी / पुरानी हो।

आप एक अनुभवी डेवलपर बन सकते हैं। जब तक आप ऐसा नहीं करेंगे, तब तक आप न्याय करने के लिए बीमार होंगे कि एक जूनियर के रूप में आपका अंतर्ज्ञान सही था या नहीं, और तब तक कोई फर्क नहीं पड़ेगा।

इस बीच, जोएल एथरटन का जवाब पढ़ें।


7

मैं दृढ़ता से सुझाव देना चाहूंगा कि "इसे अपने तरीके से लागू न करें"।

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

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


6

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


4

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

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

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


3

वरिष्ठता के कारण वरिष्ठ लोगों पर भरोसा न करें। जितनी बार संभव हो, प्राधिकरण को चुनौती दें। एक सक्षम अधिकारी को किसी भी प्रश्न का उत्तर देने में सक्षम होना चाहिए। यही कारण है कि उसे पहली जगह में एक अधिकार है, है ना?

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

कभी खराब समीक्षा का डर नहीं। क्या आप किसी अंधे आदमी पर रंग का भरोसा करेंगे?


5
अधिकांश प्रबंधकों को सब कुछ चुनौती देने वाले जूनियर देव के लिए बहुत धैर्य नहीं होगा। यदि तुम्हारा है, जाओ Cthulhu के सम्मान में एक चिकन का बलिदान, 'क्योंकि तुम एक महान मालिक मिल गया है! अन्यथा, जब तक आप एक को नहीं पा लेते तब तक बहुत कुछ करने के लिए तैयार रहें।

2

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

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

यदि वरिष्ठ की भूमिका संरक्षक की है, तो वह बताएगा कि क्यों कहा जाता है।


2

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

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

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


सकारात्मक भागों को इंगित करने के लिए, एचएलजीईएम और जारोद का धन्यवाद।
डेवलेपर

1

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

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

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

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


1

मैं अपने व्यक्तिगत अनुभव से कुछ सामान प्रदान करना चाहूंगा, जिसे यहां jzd द्वारा पोस्ट किए गए एक पूरक उत्तर के रूप में माना जाना चाहिए ...

  1. किसी अन्य वरिष्ठ डेवलपर से पूछें,
  2. अपने आप से अनुसंधान करें।

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

यह बहुत अच्छा होगा अगर मैं गलत था, क्योंकि मैं अपना व्यवहार बदल दूंगा, लेकिन मैं नहीं था।


5
अज्ञानता और / या इसे करने की अनिच्छा को छोड़कर उद्योग की सर्वोत्तम प्रथाओं को अनदेखा करने का लगभग कोई वैध कारण नहीं है। वे एक कारण के लिए "सर्वश्रेष्ठ" अभ्यास कर रहे हैं, और जो लोग उनके साथ आते हैं वे दस गुना अधिक चतुर हैं और यहां तक ​​कि वरिष्ठ डेवलपर की तुलना में अधिक वरिष्ठ हैं जो अनदेखी या उनसे अनजान हैं।
वेन मोलिना

@Wayne M: ठीक कहा।
जिम जी

6
@Wayne, आपको अभी भी यह समझने की आवश्यकता है कि वे सर्वोत्तम अभ्यास क्यों हैं। यदि आप आँख बंद करके कहते हैं "यह सबसे अच्छा अभ्यास है, तो हमें इसे करने की आवश्यकता है!" बिना जाने क्यों, आप खुद बेहतर नहीं हैं।

मैं कहूंगा कि वेन ने अपने जवाब में एंडरसन के खंडन में पर्याप्त जगह छोड़ दी।
सी जॉनसन

@ Thorbjørn रावन एंडरसन, @learnjourney - सभी टिप्पणियों और उत्तरों में से, Thorbjørn की टिप्पणी शायद सबसे महत्वपूर्ण और प्रासंगिक सलाह का टुकड़ा है। आपको उन समस्याओं को समझना चाहिए जो किसी दिए गए सर्वोत्तम अभ्यास को रोकने या हल करने की कोशिश कर रही थी अन्यथा आप कभी नहीं जान पाएंगे कि क्या वे समस्याएं अभी भी लागू होती हैं। संक्षेप में, आपको यह समझना चाहिए कि यह सबसे अच्छा अभ्यास क्यों है। यह है कि आप विकल्प कैसे सुझाते हैं: उन समस्याओं पर रोशनी डालकर जो सबसे अच्छा अभ्यास हल करती हैं। जैसा कि मैट्रिक्स से मेरोविंगियन ने कहा, "बिना" क्यों "आपके पास कुछ भी नहीं है।"
थॉमस

1

मैंने पिछले कुछ वर्षों में कुछ देखा है, लगभग हर कंपनी जिस पर मैं काम कर रहा हूं, लगभग हर नए किराए (कौशल / अनुभव स्तर की परवाह किए बिना) कुछ 'अलग' करना चाहता है।

यह कोडिंग मानकों या समग्र वास्तुकला या भाषा या कार्यप्रणाली हो सकती है। लेकिन यह हमेशा कुछ है। बहुत बार, यह सिर्फ स्पष्ट है, 'हमारे अंत उपयोगकर्ताओं के लिए सब कुछ बेहतर दस्तावेज नहीं होना चाहिए?'

मेरी आपको सलाह यह है कि वह आदमी नहीं है

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

आम तौर पर बोलना, हालांकि, पुराने दृष्टिकोण के मुकाबले आधी टीम की तुलना में पुराने दृष्टिकोण के साथ हर किसी के पास होना बेहतर है, कुछ नए दृष्टिकोण के बाद टीम के 1/4 वें और टीम के 1/4 वें स्थान पर एक अत्याधुनिक विकसित करने की कोशिश कर रहा है। , नया दृष्टिकोण।


17
-1: मेरा एक बॉस है, जहां तक ​​मेरा सवाल है कि मेरा पूरा काम अपने बॉस को खुश करना है। यह मेरे पे-ग्रेड के बाहर किए गए दूसरे निर्णयों का अनुमान नहीं है। : आप मेरे लिए कभी काम नहीं करेंगे। मैं 'यस मेन' नहीं रखता। मैं चाहता हूं कि मेरी सीधी रिपोर्ट रचनात्मक आलोचना की पेशकश करे जब मैं एक उप-विषयक निर्णय लेने वाला हूं। अगर मैं उनकी राय को महत्व नहीं देता, तो मैं उन्हें पहले स्थान पर नहीं रखता।
जिम जी

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

6
@Jim जी के साथ सहमत होना है "स्मिथर्स" होने का रवैया सबसे खराब चीज है जो आप कर सकते हैं; आपका प्रबंधक हमेशा सही है यह सोचना एक भयानक बात है क्योंकि अक्सर वे सही नहीं होते हैं। @CodeninjaTim से भी सहमत हैं - एक नए भाड़े के पास अक्सर बेहतर सुझाव होते हैं क्योंकि उनके पास वैसा ही दृश्य नहीं होता जैसा कि लंबे लोगों के पास होता है, इसलिए वे "यथास्थिति" का पालन करने की संभावना कम रखते हैं
वेन मोलिना

4
@ जिम जी: ऐसा लगता है कि ओपी ने पहले से ही अपनी चिंता बढ़ा दी है "यह 2--3 सप्ताह में तीसरी बार है।" - मैं कल्पना नहीं कर सकता कि आप किसी ऐसे व्यक्ति को नियुक्त करना चाहते हैं, जो अपनी राय देने के बाद यह समझाए कि A, B से बेहतर है (भले ही वह असहमत हो) वह बदलाव करने से इनकार कर देता है। उस बिंदु पर, वह वास्तव में आपके लिए काम नहीं कर रहा है।
रोब पी।

3
@Wayne M - मैं वकालत नहीं कर रहा हूँ हम मानते हैं कि हमारे प्रबंधक हमेशा सही होते हैं। मैंने उचित तरीके से उनकी चिंताओं को उठाने का सुझाव दिया। लेकिन कुछ हफ्तों की अवधि में 3 बार कुछ करने के लिए कहा जाने के बाद, ओपी इसे सही तरीके से नहीं संभाल रहा है। हर तरह से, अपनी चिंताओं को आवाज़ दें, लेकिन महसूस करें कि आप (जब तक आप नहीं हैं - तब इस पर ध्यान न दें)। आप मुआवजे के कुछ स्तर के बदले किसी और के लिए काम करने को तैयार हो गए हैं। तथ्य यह है कि आपके पास एक बॉस है एक अपेक्षा का अर्थ है कि आप जैसा कि आपको बताया जाता है, वैसा ही करते हैं। सही या गलत, यही आपने एक कर्मचारी के रूप में साइन अप किया है
रोब पी।

1

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

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

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


1

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

(कार्यों के लिए थोड़ा संपादित किया गया।)

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

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


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

@learnjourney: मैं मानता हूं कि यदि आप पूछ रहे हैं कि उत्तर क्यों और क्यों नहीं मिल रहा है तो एक समस्या है। मैं फिर भी यह सलाह दूंगा कि आप इस बात से अवगत रहें कि यह दूसरी तरफ से कैसा दिख सकता है, लेकिन यदि यह वरिष्ठ डेवलपर आपकी मदद नहीं कर सकता है, तो दूसरा ढूंढें और उनके सामने समस्या रखें, बस मूल के साथ "उन्होंने कहा <कारण>, क्या आप बता सकते हैं कि यहाँ कैसे लागू होता है? ", और कोई भेदभाव नहीं। यदि वह काम नहीं करता है, तो मैं कुछ अन्य उत्तरों को देखूंगा जो वैसे भी परिवर्तन करने के लिए कहते हैं, लेकिन अपने संस्करण और कारणों को संभाल कर रखें। किसी भी तरह से इसे सीखना सुनिश्चित करें।
कालेब हित्त - cjhuitt

1

कुछ विचार:

1 / क्या यह काम करता है? उसके काम करने का तरीका है या नहीं? क्या कोई ऐसा वस्तुनिष्ठ कारण है जिससे उसका रास्ता हीन होगा?

वस्तुनिष्ठ कारण से, मेरा मतलब कुछ ऐसा है जिसे अस्पष्टता के बिना मापा जा सकता है (प्रदर्शन, बग, कोड की लंबाई ...) यदि उसका समाधान काम करता है और कोई उद्देश्य मीट्रिक नहीं है जो इंगित करता है कि यह एक खराब समाधान है, तो इसे अपने तरीके से करें। उसका तरीका बेहतर है ... क्योंकि यह संभवतः बाकी कोडबेस के साथ अधिक सुसंगत है और क्योंकि इससे आपके लिए उसका उपयोग / पुनः उपयोग करना आसान हो जाएगा। आप इसे पसंद नहीं कर सकते हैं, लेकिन यह ऐसा नहीं है जो इसके बारे में है, क्या यह है?

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

2 / स्टार प्रोग्रामर कहते हैं ... क्यों एक लानत दे? आप कई बुनियादी विषयों जैसे कि योजना, डिजाइन, ओओपी बनाम प्रक्रियात्मक, इकाई परीक्षण, अपवादों से निपटने, स्रोत नियंत्रण, पर और पर और एक-दूसरे के साथ गहराई से प्रसिद्ध प्रोग्रामर पाएंगे।

यदि 2 समाधानों के बीच कार्य-क्षमता में एकमात्र अंतर यह है कि कौन इसका पक्षधर है, तो इसे छोड़ दें। आप एक ऐसे प्रतिमान में काम करने के लिए आवश्यक मानसिक कसरत से लाभान्वित हो सकते हैं जो आपको पसंद नहीं है


1

इस विचार के आधार पर कि आपको केवल उन लोगों से सलाह लेनी चाहिए जिन्हें आप बनना चाहते हैं, इसका उत्तर यह है कि यदि आप उसके जैसा बनना चाहते हैं तो वरिष्ठ सलाह अच्छी है।


1

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

ऐसी स्थिति में मुझे क्या करना चाहिए?

सच कहें तो, यह बहुत सारी तकनीकी नौकरियां हैं। आपको एक स्वयं-स्टार्टर होने की आवश्यकता है जो आपके द्वारा मुश्किल समस्याओं को हल कर सकता है (यदि इंटरनेट हो तो इसकी मदद से) और यदि आप इसे अस्वीकार करते हैं)।

कोड समीक्षाओं को प्राप्त करने और वास्तुशिल्प डिजाइनों की मदद लेने के दृष्टिकोण से, जब मेरे पास अच्छे प्रबंधक थे, तब भी मैंने कभी भी कोड की समीक्षा नहीं की, "स्थिर चर से परे एक s_ उपसर्ग होना चाहिए"।

सीखने और सीखने का अवसर लेने का अवसर लें; वे कौशल होंगे जो आप भविष्य में उपयोग कर सकते हैं।


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

1

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

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

प्रबंधन की बुद्धि को कम मत समझना ...

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

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

यहां एक और संभावित परिदृश्य है, लीड ए किसी महत्वपूर्ण व्यक्ति के करीबी दोस्त हैं। वह राजनीतिक रूप से बहुत गर्म है,

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

निश्चित रूप से इसका कारण यह है कि इस तरह के संगठन में प्रबंधक बुरी प्रतिभा से निपटने के लिए हमेशा अल्पावधि से बेहतर होता है ताकि दीर्घकालिक समस्याओं को दूर किया जा सके जो इस प्रकार के लोग संगठन में ला सकते हैं।

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


जवाब के लिए धन्यवाद और सोच और उनके दृष्टिकोण के प्रबंधन पक्ष में लाना। आप के लिए Upvote
डेवलपर १२

0

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

यह पिछले सप्ताहांत। एक व्यक्ति ने मुझे एकल के बारे में तर्क / असहमति दी। मैंने कहा कि वे अच्छे नहीं हैं और उन्हें कभी भी इस्तेमाल नहीं किया जाना चाहिए और उन्हें इस्तेमाल करने का कोई कारण नहीं है। मैंने उसे http://www.gmannickg.com/?p=24 से जोड़ा और अधिक गहराई से लेख में इसे लिंक कियातर्क के कुछ दिनों बाद। एक अन्य प्रोग्रामर (DudeB) के दिन का उल्लेख है कि वह केवल एकल का उपयोग करता है जब इसके उपयुक्त (जो मैंने 'कभी नहीं' के साथ जोड़ा)। DudeB ने इस बारे में कुछ नहीं कहा, लेकिन DudeB ने कहा कि DudeB एक ऐसी परियोजना थी जिसमें स्मृति विवाद था क्योंकि सभी सूत्र सिंगलटन को एक्सेस कर रहे थे। इसका उल्लेख करने के बाद, लेख को दिखाते हुए और स्मृति विवाद का उल्लेख करते हुए मैंने कहा कि हम असहमत होने के लिए सहमत होंगे जिस पर मैं सहमत था क्योंकि मुझे एकल के बारे में बात करना पसंद नहीं है (फिर भी मैं यह डीओ लिख रहा हूं)

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


1
पुन: "शायद किसी ने टिप्पणी में मेरे साथ
एकल के

0

इस पर मेरी पूरी तरह से अलग / विवादास्पद राय है।

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

कंपनी के प्रत्यक्ष परिणामों पर बहुत कम प्रभाव डालने के बारे में जानने के लिए लोग बहुत ही अप्रत्यक्ष मिनट की चीजों को पकड़ सकते हैं।

यदि आपको लगता है कि आप किसी चीज़ के बारे में सही हैं तो आपका सबसे अच्छा दांव यह दिखाना है कि कैसे बेहतर परिणाम मिलेंगे ।


-1: इतना हास्यास्पद। // आपकी "विवादास्पद" राय की क्रूरता इस तथ्य पर टिकी हुई है कि ओपी को minutiae या तुच्छता में पकड़ा गया है। तुम्हें पता नहीं है कि! प्रश्न को अंकित मूल्य पर लें।
जिम जी

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

0

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


5
-1: एक वरिष्ठ n00b के लिए 2+ वर्ष क्यों काम कर रहे हैं?
जिम जी

@ जिम - 6 महीने के बाद नौकरी करना आपके सीवी पर अच्छा नहीं लगता। यदि आप कहीं और जाते हैं और सीनियर इससे भी बदतर है, तो आपके CV पर प्रभाव तेजी से खराब होता है! इसके अलावा आप यह महसूस करना सीख सकते हैं कि उन्होंने जो कुछ भी कहा वह गलत नहीं था या कम से कम इस तरह से करने का एक कारण था।
मैट विल्को

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

0

[रेपोस्ट: क्योंकि मैंने किसी तरह यहाँ पर एक दूसरा खाता बनाया]

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

आपको यह स्पष्ट होना चाहिए कि ये सुझाव या आदेश / निर्देश / निर्देश / जो भी हैं।

सुझाव = मुझे लगता है कि यह इस तरह से करना बेहतर है; लेकिन यह आपकी पसंद है।

आदेश / आदि। = मैं चाहता हूँ कि यह इस तरह से हो; और यह मेरी पसंद है।

यदि यह वास्तव में एक सुझाव है, तो जैसा आप चाहते हैं वैसा करें और अपने कोड को खड़े होने दें। यदि यह एक आदेश है (और इस संरक्षक का इस तरह से आप पर अधिकार है) - जैसा वे कहते हैं वैसा ही करें।

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