क्या मुझे एक दिवंगत सहकर्मी को उनके "सेव 1" दोष के बारे में बताना चाहिए? [बन्द है]

Question

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

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

इस तरह की स्थिति के लिए सामान्य प्रोटोकॉल क्या है?

Comments

यदि आप अन्यथा इसके बारे में काफी दिलचस्प हैं, तो आप इसके बारे में एक ब्लॉग पोस्ट बना सकते हैं

— शाफ़्ट सनकी

मैं कहूंगा कि इसे अकेला छोड़ दो। आपके कोलीग की संभावना को परवाह नहीं है कि उसके जाने के बाद क्या हुआ है। आप उसे उसकी गलतियों से बताने के कारण कुछ भी नहीं देते हैं, क्योंकि उसकी गलतियाँ आगे बढ़ रही हैं, आपकी समस्या नहीं है।

— रामधुन

इसे codinghorror.com पर भेजें। उसे नाम न दें, लेकिन जब वह उसे पढ़ता है तो उसे उसके काम के रूप में पहचानने के लिए उसके पास पर्याप्त विवरण शामिल करें।

— user16764

क्या किसी ने यह सुनिश्चित करने के लिए ओपी के प्रोफाइल को देखा कि यह उन्हें नहीं था? या यह सिर्फ मैं था ...

— एडम वी

@ user16764 - मुझे लगता है कि आपका मतलब है डेली डब्ल्यूटीएफ ?

— तेंदुआस्किलपबॉक्सहॉट 1

Answer 1

आप यह बताने के लिए कि उसने कोई गलती की है, एक पूर्व कर्नल का शिकार न करें। आप अपने दोस्त को बता सकते हैं कि उसने गलती की है।

चाहे वह एक दोस्त हो या एक पूर्व सहकर्मी आप पर निर्भर है।

Comments

इसके अलावा आप अपनी गलती के बारे में अपने दोस्त को बार-बार रिब कर सकते हैं - लेकिन फिर से इस बात पर निर्भर करता है कि वह कितना करीबी दोस्त है ...

— बिल के

बहुत गहरा और संक्षिप्त जवाब! काश, मैं आपको +1 से अधिक दे पाता!

— मैथअटैक

+1 लगता है कि हम भी ऐसा ही सोचते हैं। लेकिन आपने इसे बहुत बेहतर बताया।

— फैब्रिकियो अराजू

न केवल सबसे लोकप्रिय उत्तर, लेकिन जब मैं सवाल पूछ रहा था, तो मैं उसकी ओर झुक रहा था। धन्यवाद!

— नूह

Answer 2

कुछ मत करो।

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

Answer 3

यदि आप एक एनडीए के तहत हैं, तो यह किसी भी आईपी-संबंधित मुद्दों के बारे में आपकी कंपनी के बाहर किसी से बात करने के लिए कोई बड़ी संख्या नहीं है, चाहे वे पूर्व कर्मचारी हों या नहीं।

यदि आप एक एनडीए के तहत नहीं हैं, तो मैं यह कहने के लिए उद्यम करूंगा कि वह परवाह नहीं करेगा।

उस तरफ, क्या वह व्यक्ति असंतुष्ट था? क्या यह कुछ ऐसा था जो वास्तव में जानबूझकर किया जा सकता था?

Comments

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

— ब्रायनह

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

— कैफीक जुने

क्या पूर्व कर्मचारी अभी भी एनडीए के अधीन नहीं होगा?

— ब्लूराजा - डैनी पफ्लुगुफ्ट

Answer 4

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

Comments

काश मैं छोड़ते समय मस्तिष्क को बंद कर सकता था।

— कैफीक जुने

@ मैं नहीं कर सकता, मैं कार में और काम से अपने सबसे अच्छे काम करता हूं। हालाँकि जब मैं सोने जाता हूँ ...

— dararak

@daramarak तुम सोते हो? मैं बस एक अवचेतन कोडिंग स्थिति दर्ज करता हूं। ;)

— यमिकुरोन्यू

@ यमिकुरोन्यू, हाहा, अच्छा। मुझे वह वाक्यांश याद रखना होगा।

— कैफ़ीक गेन

Answer 5

यह सहकर्मी आपका FRIEND है जिसे आप छोड़ने के बाद निकट संपर्क जारी रखते हैं? यदि हाँ, तो इस बारे में बात करें कि क्या / जब आप बार पर बियर ले रहे हैं।

नहीं तो परेशान क्यों?

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

अगर बात छोड़ने के 3 साल बाद होती है तो आप अलग होंगे और आप ऐसी बातें बताएंगे जो उसे आपके अलावा जानने की जरूरत नहीं होगी ...

Comments

WRT NDA, एक रहस्य होगा। क्या नूह अपने पूर्व सहयोगी पर भरोसा कर सकता है कि हर कोई यह नहीं बताएगा कि नूह ने एनडीए का उल्लंघन किया है? यह नूह का बड़ा रहस्य है ।

— एमोरी

अगर सिर्फ एक सहकर्मी है, तो उसके बारे में बात करना क्यों परेशान करता है ? एक करीबी दोस्त जो नौकरी छोड़ देता है, वह एक और कहानी है।

— फैब्रिकियो अरुजो

Answer 6

यह इस बात पर निर्भर करता है कि यह व्यक्ति कैसे चला गया और उससे आपका रिश्ता कैसा है।

इसके अलावा, आप क्या परवाह करते हैं? मैं देखता हूं कि आप उसे "त्रुटि से सीखने" में मदद करना चाहते हैं, लेकिन क्या आप वास्तव में हैं? क्या आप उसे लॉग * और स्टैक ट्रेस * दिखाने जा रहे हैं? क्या आप उसे समस्या के निदान के लिए उठाए गए कदमों को दिखाने जा रहे हैं? क्या आप उसे स्रोत दिखाने जा रहे हैं * ताकि वह देख सके कि समस्या कहाँ थी?

यदि नहीं, तो आप शायद उसका समय और तुम्हारा बर्बाद कर रहे हैं।

* क्या आप किसी गैर-कर्मचारी को कंपनी की संपत्ति / डेटा का खुलासा करने के लिए मुसीबत में हैं?

Comments

इस मामले में यह उतना ही सरल है जितना "आप Map.put (K, V) कहते हैं और कभी Map.remove (K) या Map.clear ()" नहीं कहा जाता है - और संभवतः कैश कार्यान्वयन / कॉन्फ़िगरेशन किस प्रकार के बारे में चर्चा करते हैं। उपयोग।

— नूह

@ बेनज़ - यह एक ईमानदार गलती की तरह लगता है। मैं इस बारे में बात करने लायक गलती भी नहीं करूंगा। अधिक दिलचस्प सवाल यह है कि उत्पादन प्रक्रिया पर प्रकाशित होने से पहले आपकी प्रक्रिया इस बग को पकड़ने में विफल रही।

— रामहाउंड

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

— नूह

Answer 7

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

Answer 8

शायद ऩही

लगता है कि ज्यादातर मेरे लिए, चाहे दोस्त हों या सहकर्मी। और, कुछ परिस्थितियों में, संभवतः उनके लिए हानिकारक, आपके लिए, और उनके साथ आपके रिश्ते के लिए।

हम सभी कभी-कभार गलतियाँ करते हैं।

वास्तव में, एकमात्र कारक जो मुझे बताना चाहता है कि सहकर्मी यह है: क्या यह एक गलती है जो मुझे पता है कि वे आमतौर पर ऐसा नहीं करेंगे / ऐसी स्थिति जो मुझे पता है कि वे जानते हैं कि कैसे संभालना है?

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

यदि जवाब नहीं है, तो एक दायित्व हो सकता है (इसे "पेशेवर" नहीं कहेंगे, हालांकि) उन तक पहुंचने और उनकी त्रुटि को समझने में मदद करने के लिए।

इसे व्याव्हारिक रखें

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

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

कानूनी?

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

सकारात्मक सोचो

अंत में, मुझे लगता है कि जिन परिस्थितियों में मैं पूर्व सहकर्मी के पास पहुंचा, उन पर चर्चा करने के लिए एक कोडबेस वे पीछे छोड़ गए थे:

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

---

उनकी गलतियों से सीखें

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

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

Answer 9

किसी को बताना कानूनी नहीं हो सकता है। जब तक कोड खुला स्रोत न हो, तब तक सोने वाले कुत्तों को झूठ बोलने दें।