क्या बग को हल करने में तेज़ होने का कोई तरीका है? मैंने अभी-अभी अपने बॉस से चेतावनी दी है [बंद]


129

मुझे बस मेरे बॉस द्वारा बताया गया है कि मुझे सोमवार को एक नकारात्मक प्रदर्शन की समीक्षा मिलेगी। वह मुझसे बात करना चाहता है कि मैं इतना धीमा क्यों हूं और मेरी बग फिक्स दर इतनी कम क्यों है।

मुझे प्रोग्रामिंग और समस्याओं को हल करना बहुत पसंद है लेकिन मुझे वास्तव में अपनी नौकरी वास्तव में बहुत कठिन लगती है।

मैं वास्तव में लगभग 10 वर्षों के लिए एक प्रोग्रामर रहा हूं। लेकिन यह मेरा पहला मल्टीथ्रेडिंग एम्बेडेड लाइनक्स जॉब है - मुझे यहां आए 2 साल हो गए हैं और यह सभी के लिए स्पष्ट है कि मैं अभी भी संघर्ष कर रहा हूं। और मुझे लगता है कि मैं इतना हतोत्साहित हो गया हूं और इतना हाशिए पर महसूस कर रहा हूं कि मैंने नौकरी की शुरुआत में बहुत आग खो दी है।

क्या कभी कोई ऐसी ही स्थिति में है और आप अपने बग फिक्स रेट को कैसे बढ़ाते हैं?


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

एक और अपडेट

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

फिर भी एक और अद्यतन

मैं इसे यहां पर रखने में संकोच कर रहा हूं, क्योंकि मुझे चिंता है कि मैं भविष्य के नियोक्ताओं को अपने स्टैकओवरफ्लो प्रोफाइल में संदर्भित नहीं कर पाऊंगा ... लेकिन वैसे भी, यह इस प्रश्न को पढ़ने वाले किसी व्यक्ति के लिए रुचि का हो सकता है, लेकिन मैं वास्तव में अपना खो गया हूं कुछ हफ्ते पहले नौकरी। मैं उन सभी कौशलों पर अमल करने के बीच में हूँ - मुझे यहाँ दी गई सलाह से बहुत कुछ हासिल करना है।


170
अपने बॉस को बताएं कि जब उसने देखा कि यह एक समस्या थी, तो उसका उल्लेख करने के बजाय अपनी समीक्षा के लिए उसे बचाना उसके लिए अच्छा था।
ब्लरफ्ल

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

40
यदि आपको यह अनुमान लगाना है कि आपके प्रदर्शन के कारण आपको घेर लिया जा रहा है, तो प्रबंधन कुछ गलत कर रहा है। इसी तरह, अगर आप अपने अंडरपरफॉर्मेंस के बारे में पहली बार 2 साल बाद सुनते हैं, तो प्रबंधन कुछ गलत कर रहा है।
माइकल शॉ

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

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

जवाबों:


80

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

सभी प्रकार के कारण हो सकते हैं, लेकिन यहाँ कुछ संभावित स्पष्टीकरण दिए गए हैं:

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

  2. आप बहुत पतले हैं। आपकी वही SO प्रोफ़ाइल दर्शाती है कि आपके प्रश्न इन पिछले 2 वर्षों (ग्राफिक्स, वेब, अजगर, सी ++, सी, लिनक्स, एम्बेडेड, थ्रेड्स, सॉकेट्स) पर प्रौद्योगिकियों के बहुत व्यापक सरगम ​​को कवर करते हैं। व्यक्तिगत रूप से, मुझे पता है कि जब मुझे अलग-अलग धाराओं की भीड़ में तल्लीन होने (या चाहने) की स्थिति में रखा गया है, तो मैं खुद को वास्तव में बहुत तेजी से तैरता हुआ पाता हूं (या, बल्कि, वास्तव में धीमा )। शायद जो आपको वास्तव में यहाँ चाहिए वो FOCUS है । और शायद प्राथमिकता की एक स्वस्थ खुराक । वैसे भी आप बैक बर्नर पर कम महत्वपूर्ण बर्तन को फिर से जमा कर सकते हैं और मुख्य डिश पर गर्मी को चालू कर सकते हैं?

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

  4. आप अपने क्षेत्र में नहीं हैं। माइकल जॉर्डन ने एक बहुत लंगड़ा बेसबॉल खिलाड़ी बनाया। (ठीक है, वह अभी भी मुझसे बेहतर था , लेकिन निश्चित रूप से एक मामूली-छलावा।) हो सकता है कि "एम्बेडेड लाइनक्स को मल्टीथ्रेडिंग" सिर्फ एक टमटम नहीं है। लेकिन सॉफ्टवेयर डेवलपमेंट एक व्यापक क्षेत्र है (जैसा कि आप अच्छी तरह से जानते हैं; cf # 2 ऊपर)। क्या आपकी कंपनी इतनी व्यापक है कि आप एक और जगह पा सकते हैं? अपनी पिछली नौकरी में मुझे एक एम्बेडेड एसडब्ल्यू देव के रूप में काम पर रखा गया था। (मुझे उस दायरे में कोई अनुभव नहीं था, लेकिन मैंने उन्हें बताया कि मैं एक "त्वरित शिक्षार्थी था।") मैं जल्दी से पत्थर की तरह डूब गया। लेकिन मैं कड़ी मेहनत कर रखा जाता है और समस्याओं है कि मैं की तलाश में रखा कियाउनके लिए हल करना जानते हैं। जैसा कि यह निकला, मैं धीरे-धीरे नई जिम्मेदारियों में स्थानांतरित करने में सक्षम था जिस पर मैं चमक सकता था, और जिसके लिए मैंने अंततः काफी प्रशंसा प्राप्त की। तो शायद आपको खुद को फिर से ब्रांड करने की आवश्यकता है।

मुद्दा यह है: यदि आप धीमे हैं, तो एक कारण है। लेकिन, हे - आप एक सॉफ्टवेयर इंजीनियर हैं, दोस्त! अपने आप को डीबग करें!


2
क्या शानदार जवाब है। मुझे लगता है कि अपने अंक के सभी मुझे (और # 1 के बारे में के लिए लागू कर रहे हैं, अच्छी तरह से शायद मैं कर रहा हूँ कम बुद्धिमान, मैंने सुना है कि खुफिया के विभिन्न प्रकार है कि -। तो शायद कि # 4 से संबंधित है शायद मैं कर रहा हूँ एक numbskull एम्बेडेड लिनक्स देव लेकिन शायद मैं वेब सामग्री पर बेहतर हूं ... और अब मैं इसके बारे में सोचता हूं, यह वास्तव में यथार्थवादी हो सकता है)। वैसे भी - तुम बहुत बोधगम्य हो।
बियांड

14
3 और 4 बड़े हैं (प्रोग्रामर के लिए) अधिकांश बॉस कल्पना कर सकते हैं। यदि किसी प्रोग्रामर का मनोबल कम है, तो वह काम पर ध्यान केंद्रित नहीं कर सकता है। एक प्रोग्रामर के लिए, मनोबल गति है और गति सब कुछ है।
तैमूर

7
बहुत बढ़िया जवाब। डिबग खुद एक महान वाक्यांश है, btw। काश मैं तुम्हें दूसरी बार बस के लिए upvote कर सकता।
कायोटिक

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

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

56

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

आइए, उन कुछ कारणों पर एक नज़र डालते हैं जो आपके बॉस अब ला सकते हैं:

संस्कृति और राजनीति

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

योग्यता

यह संभव है कि क्षमता बराबर नहीं है, जैसा कि आप कहते हैं कि वह खुले तौर पर कहा गया है। इस स्थिति में मैं क्या करूंगा:

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

यदि आपका प्रदर्शन धीमा है और वास्तविक अंतर के आधार पर है, तो उस अंतर को पहचानें और इसे बंद करने के उद्देश्य से अपने बॉस के साथ एक विस्तृत योजना बनाएं।

यह समीक्षा इस तथ्य को सामने लाने का एक अच्छा अवसर है कि आप खुश नहीं हैं। यह अच्छा है कि आपने पहचान लिया है कि आप इस नौकरी से प्यार नहीं करते हैं। लेकिन यह पता क्यों। आपकी नौकरी का कौन सा हिस्सा आपको पसंद है और क्या नहीं? हो सकता है कि यह नौकरी आपके लिए न हो ...


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

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

1
@ हाँ, मैंने विभिन्न तरीकों से लॉग फ़ाइलों को पार्स करने के लिए एक उपकरण बनाया है। मुझे बाद में पता चला कि किसी ने एक साल पहले ही बना लिया था।
बियांड

@Bee: आपका एक टूल बनाना कुछ आवश्यक पहल दिखाता है। जब आप परियोजनाओं के बीच संक्रमण करते हैं तो क्या कोई आपको विकास के माहौल का अवलोकन नहीं देता है? यदि उपकरण मौजूद हैं, तो यह निश्चित रूप से प्रतीत होगा कि प्रोजेक्ट लीड को आपको उनके बारे में बताना चाहिए था।
डंक

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

38

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

अपेक्षाओं और उनसे मिलने में मदद करने के लिए उपलब्ध कराए गए संसाधनों के बारे में आपको वास्तव में खुद के साथ ईमानदार होने की आवश्यकता है। समस्या आपको नहीं हो सकती है।

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

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

आपके लिए इसे बनाने के लिए जहाँ तक आपका मतलब है कि आपने कुछ सही किया है और आपके लिए कुछ किया है।

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

नौकरी छोड़ने से बेहतर है कि आप अपना जीवन बर्बाद कर दें।


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

31

सबसे पहले, ध्यान दें: यह उत्तर केवल कुछ क्षेत्रों पर लागू हो सकता है जहां किसी कर्मचारी को बिना विच्छेद के अवैध रूप से खारिज करना है। ने कहा कि...

यह कंस्ट्रक्टिव बर्खास्तगी का मामला हो सकता है और जो अवैध है।

जब तक वे नौकरी नहीं छोड़ते तब तक किसी कर्मचारी के आत्मसम्मान को कम करना और कम करना रणनीति है। यह कंपनी के लिए एक रास्ता है कि वह पैसे न बचाए, और न ही कर्मचारियों से टकराव होने और उन्हें आग लगाने की समस्या को हल करे।

वह मुझसे बात करना चाहता है कि मैं इतना धीमा क्यों हूं और मेरी बग फिक्स दर इतनी कम क्यों है।

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

यदि आप एक ठेकेदार हैं, और यह आपके अनुबंध में बताता है कि कीड़े के फिक्सिंग के लिए जिम्मेदार होगा, तो यह पूरी तरह से अलग कहानी है।

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

मुझे प्रोग्रामिंग और समस्याओं को हल करना बहुत पसंद है लेकिन मुझे वास्तव में अपनी नौकरी वास्तव में बहुत कठिन लगती है।

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

मैं वास्तव में लगभग 10 वर्षों के लिए एक प्रोग्रामर रहा हूं। लेकिन यह मेरा पहला मल्टीथ्रेडिंग एम्बेडेड लाइनक्स जॉब है - मुझे यहां आए 2 साल हो गए हैं और यह सभी के लिए स्पष्ट है कि मैं अभी भी संघर्ष कर रहा हूं।

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

और मुझे लगता है कि मैं इतना हतोत्साहित हो गया हूं और इतना हाशिए पर महसूस कर रहा हूं कि मैंने नौकरी की शुरुआत में बहुत आग खो दी है।

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

संदर्भ

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

प्रासंगिक तथ्यों के लिए बाहर देखो:

  • कठिन काम की परिस्थितियों के दौरान एक कर्मचारी को ठीक से समर्थन करने में विफलता
  • एक कर्मचारी की अत्यधिक अनुशासितता, कम सूचना पर कर्मचारियों के काम करने के स्थान में बदलाव का प्रस्ताव
  • वेतन या मजदूरी में कमी का आरोप

कानूनी प्रश्नोत्तर: रचनात्मक बर्खास्तगी

रचनात्मक बर्खास्तगी का दावा करने के कारण

विकिपीडिया

एक रचनात्मक बर्खास्तगी के तत्व


11
यह नकारात्मक प्रदर्शन की समीक्षा देने के लिए अवैध नहीं है, लेकिन वे करते हैं उद्देश्य होना चाहिए और काम के लिए संभव मापदंड सहमत हैं और आप समर्थन करते हैं।
pjc50

9
मुझे लगा, हो सकता है, जब मैं उस उत्तर को पोस्ट कर रहा हूं, लेकिन मैं इसे ओवररिएक्ट कर रहा हूं, लेकिन आपकी पोस्ट को पढ़कर यह मेरे स्वयं के अनुभवों से गूंजता रहा। बग फिक्सिंग एक प्रदर्शन संदर्भ के साथ मापा जा सकता है कि कुछ नहीं है। मैंने एक बग को ठीक करने के लिए 3 महीने का समय दिया है। आमतौर पर, स्मार्ट लोग वही होते हैं, जिन्हें कठिन कीड़े मिलते हैं।
रिएक्टगुलर

9
मैं नीचे मतदान कर रहा हूं क्योंकि मुझे कोई सबूत नहीं दिख रहा है कि आप एक वकील हैं और कानूनी सलाह देने का दावा कर रहे हैं। इसके अलावा, यदि अन्य कर्मचारी प्रति माह औसतन एक्स बग फिक्स कर रहे हैं, लेकिन ओपी एक्स / 10 को ठीक कर रहा है, तो यह बिल्कुल उद्देश्यपूर्ण और उचित है।
एंडी

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

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

26

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

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

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

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

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


3
यह एक शानदार प्रतिक्रिया है। मैं बहुत प्रभावित हूँ।
डैनियल हॉलिनरेके

26

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

आप इसके बारे में क्या कर सकते हैं?

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

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

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

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


4
"पहली जगह में कोड लिखने के रूप में डिबगिंग दोगुना कठिन है।" - ब्रायन कर्निगन (C, UNIX के पिता)
टिमजी

4
@ टीआईएमजी: और हर दूसरे प्रोग्रामर की तरह, कर्निगन मुश्किल को कम कर रहे थे।
म्यू

वाह, मैं यह बताना चाहता हूं कि यह वास्तव में एक कठिन सवाल है और मैं यहां इस तरह के एक अच्छे और व्यावहारिक जवाब को देखकर आश्चर्यचकित हूं। धन्यवाद।
maksymko

12

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

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

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


2
ended up getting micromanaged until I was terminated- वैसे मैंने अभी-अभी आपके SO प्रोफाइल को देखा है और आपने स्पष्ट रूप से उसी से वापस बाउंस किया है, इसलिए मुझे आपकी प्रतिक्रिया हार्दिक लगती है। मैं सोमवार को आपके पहले बिंदु के बारे में बात करने जा रहा हूं - मुझे बहुत ही विवादित क्षेत्रों से कीड़े प्राप्त हो रहे हैं।
बियाबान

10

नौकरी पर दो साल के बाद, यह सभी के लिए स्पष्ट होना चाहिए (आप, आपके बॉस, आपके सहकर्मी) जहां आप खड़े हैं। यानी, आपको कभी यह पता नहीं लगाना चाहिए कि आप साल में केवल एक बार खराब प्रदर्शन कर रहे हैं; एक आदर्श कार्य वातावरण निरंतर प्रतिक्रिया प्रदान करेगा।

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

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


2
हाँ, यह मेरा कोड नहीं है - यह एक विशाल फैला हुआ एंबेडेड सिस्टम है, जो पहली बार 10 साल पहले बना था। मुझे लगता है कि आप पैटर्न के बारे में सही हैं - मुझे मूल बातों पर वापस जाने की आवश्यकता है।
बियाबान

1
@BeeBand यह जानना अच्छा होगा कि आपको कैसे मिला है। आशा है कि चीजें बाहर काम करती हैं।
डैनियल हॉलिनरेक

10

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


यह जानना दिलचस्प होगा कि क्या बीबैंड ने पहले ही ऐसा किया है। टिप्पणियों और उत्तरों के माध्यम से पढ़ने से ऐसा लगता है कि यह काफी पर्यावरण के अनुकूल है।
डैनियल हॉलिनरेके

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

8

मुझे बस मेरे बॉस द्वारा बताया गया है कि मुझे सोमवार को एक नकारात्मक प्रदर्शन की समीक्षा मिलेगी। वह मुझसे बात करना चाहता है कि मैं इतना धीमा क्यों हूं और मेरी बग फिक्स दर इतनी कम क्यों है।

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

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

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

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


7

सबसे पहले, एक आत्मविश्वास को बढ़ावा:

क्यों भुगतना पड़ा? आप आसानी से एक नौकरी पा सकते हैं, जहां वे सोचेंगे कि आप "भगवान" हैं क्योंकि आप लिनक्स पर कुछ भी कर सकते हैं, चाहे आपकी बग फिक्स दर हो।

वैसे भी, बग का शिकार करने के लिए समय सीमा निर्धारित करना असंभव है। बग शिकार एक कौशल है, इसमें कोई संदेह नहीं है, और इसमें दक्षता अत्यधिक मूल्यवान है।

आप कुछ बुनियादी चाल को याद कर रहे होंगे, जिनके बारे में दूसरों को पता है, जो आपको धीमा बनाता है।

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

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

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


1
संगामिति के साथ सबसे बड़ी समस्या यह है कि बग-मुक्त कोड लिखना बहुत आसान है, क्योंकि यह बग कोड में बग को ठीक करता है। खासकर अगर कोड लगभग सही है। और बग आमतौर पर एक ही स्थान पर नहीं होते हैं, लेकिन कई के बारे में वितरित किए जाते हैं।
gnasher729

5

मैंने हाल ही में लिगेसी कोड के साथ वर्किंग इफ़ेक्टली किताब पढ़ी है और किसी भी कोडबेस में किसी मुद्दे से निपटने के दौरान इसने मुझे आत्मविश्वास को काफी बढ़ावा दिया है।

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

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


मैं वर्तमान में इसे आपकी सिफारिश पर पढ़ रहा हूं।
बीबंड

3

अपने श्रेष्ठ से पूछें कि बग को ठीक करने की आपकी गति क्या है और बग को ठीक करने की टीम की औसत गति क्या है। अधिक महत्वपूर्ण है, उससे पूछें कि कीड़े को ठीक करने की गति कैसे मापी जाती है ...

इस तरह की मीट्रिक वास्तव में एक मीट्रिक नहीं है; यदि यह होगा, तो यह LOC (हालांकि विभिन्न सामानों को मापने) की तुलना में अधिक अविश्वसनीय होगा। और उचित माप के बिना आप पर किसी भी चीज़ का आरोप लगाने का कोई कारण नहीं है।


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

3

यह पहचानें कि आप नियोक्ताओं और / या उनके साथ काम नहीं करते हैं। यह उल्लेख करने में संकोच न करें कि साक्षात्कार में, बस शुरू से ही सीधे रिकॉर्ड स्थापित करना है।

आप अपने छोटे से व्यवसाय में खुद के निवेश के साथ एक पेशेवर हैं।

आप काम करने के इच्छुक हैं, जबकि एक संघ का एक संगठन है जो आपको प्रत्येक दिन रैक से बाहर निकालता है।

यदि वह प्रणोदन लम्बे समय तक नहीं है, तो आगे बढ़ें।

आप एक नितंब नियोक्ता पर अपना समय और ऊर्जा बर्बाद कर रहे हैं जो आपकी रुचि को / कौशल को अद्यतन / असाइनमेंट को चुनौती देने और / या काम करने के लिए दिलचस्प नहीं रखता है। वह प्रबंधन का काम है। इसके अलावा वे शुद्ध उपरि हैं ....।

अपने जुनून को जारी रखें, क्योंकि यह महत्वपूर्ण है।


2

मैं ऐसी ही स्थितियों में रहा हूं क्योंकि मैं मदद मांगने से डरता था। इस टिप्पणी में आपने क्या कहा था उसे देखते हुए ...

"लेकिन निराशा की बात यह है कि कुछ उपकरण / युक्तियां / तरकीबें हैं जो मुझे केवल डेढ़ साल होने के बाद पता चली हैं। मुझे टीम से टीम में स्थानांतरित कर दिया गया है (मुझे लगता है कि मुझे पता था कि मैं अंडरपरफॉर्म कर रहा था) और मुझे पता चल रहा है। ये 'छिपे हुए' उपकरण हर बार। "

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

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


2

ओपी से क्या गायब है यह किसी भी दोहराने योग्य प्रक्रिया या विधि का उल्लेख है जिसे बग को हल करने के लिए किया जा रहा है।

इसलिए, पहले, उस प्रक्रिया का दस्तावेजीकरण करें जो आप अनुसरण करते हैं। दस्तावेज़ में यह सुनिश्चित करें कि प्रक्रिया के प्रत्येक चरण को प्राप्त करने के लिए क्या है।

आप इस तरह के कार्यों के रूप में इस प्रक्रिया को रेखांकित कर सकते हैं:

  1. सुनिश्चित करें कि आप वास्तव में समझते हैं कि समस्या क्या है जो रिपोर्ट की जा रही है।
  2. समस्या को पुन: उत्पन्न करने का प्रयास करें।
  3. समस्या को छोटे टुकड़ों में तोड़ना शुरू करें
  4. समस्या के संभावित कारणों के बारे में सोचें।
  5. उन परिकल्पनाओं का परीक्षण करें

यह जानना उपयोगी होगा कि क्या कीड़े लंबे समय से मौजूद हैं, या हाल के परिवर्तनों के साथ पेश किए जा रहे हैं। यदि बग को हाल ही में किए गए परिवर्तनों के साथ कोड समीक्षा और / या केवल उस कोड को पढ़ने के साथ पेश किया गया है जिसे लोग बना रहे हैं तो मदद कर सकता है।

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

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