आपके कोड की "रचनात्मक" आलोचना किस बिंदु पर हो रही है?


39

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

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

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

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

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

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


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

4
@Job: ठीक है, अगर कोड आधार बकवास है तो यह बेहतर होना चाहिए, इसलिए आपके कमिट का उच्च स्तर होना आवश्यक है। अन्यथा यह और भी भद्दा हो जाएगा, है ना? :)
मैके

@ मारकस, आप सही हैं, लेकिन क्या सच में सहायक होगा यदि नियमों को स्पष्ट रूप से कहा गया था, और सभी के लिए समान नियम लागू होते हैं। इसके अलावा, कुछ कोड मानकों में सम्मिश्रण के बारे में भी कहा जाना चाहिए, जैसा कि पूछने वाले ने उल्लेख किया है। मैंने देखा है कि एक जूनियर व्यक्ति को बलि का बकरा बना दिया गया। प्रबंधन ने शिकायत की कि इंजीनियरों ने कई कीड़े पैदा किए। इंजीनियर एक अच्छा काम नहीं कर सकते थे क्योंकि प्रबंधन उन्हें निश्चित समय सीमा देता है। इसलिए, जब कुछ गलत हो जाता है, तो हमेशा दोष और जाने देने के लिए सबसे अधिक पेंच वाले कनिष्ठ व्यक्ति होता है। en.wikipedia.org/wiki/Dedovshchina
नौकरी

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

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

जवाबों:


41

एक मौका है कि आप एक महिला के रूप में एकल हो रहे हैं, लेकिन यह भी संभव है कि आप सिर्फ एक जूनियर डेवलपर हों और नौकरी के लिए नया हो।

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

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

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


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

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

@Anna, अनुरूप कोड के महत्व पर सहमत हैं। मैंने पढ़ा है कि लाइनस थोरवाल्ड्स के लिए गैर-अनुरूपता कोड पर्याप्त है ताकि ऐन मौके पर लिनक्स के लिए एक प्रस्तुत पैच को अस्वीकार कर दिया जाए (लेकिन मैं अभी इसका पता नहीं लगा सकता)।

@ अन्ना / थोरबॉर्न - कभी-कभी आपको बस वही करना होता है जो ग्राहक चाहता है, हालांकि यदि कोई समय सीमा है। आपके ग्राहक को बहुत समझ नहीं होगी यदि वह $ 15,000 का व्यापार राजस्व खो देता है क्योंकि आप केवल पूंजीकरण त्रुटियों को साफ करना चाहते हैं। दुर्भाग्य से, 100% तकनीकी ऋण को खत्म करने की कोशिश करना हमेशा संभव नहीं होता है। यह एक बंधक को बाहर निकालने के बजाय अपने सपनों का घर खरीदने के लिए पर्याप्त नकदी बचाने के लिए 40 साल की प्रतीक्षा करने के समान होगा। निश्चित रूप से, आप स्वतंत्र और स्पष्ट होंगे, लेकिन आपने अपना पूरा जीवन छायादार जमींदारों के साथ बिताने में व्यतीत किया होगा।
jmort253

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

25

ऐसा लगता है कि आप इस सामान को थोड़ा बहुत व्यक्तिगत रूप से ले रहे होंगे। मत करो; इस तरह की बात हर समय होती है।

आपके चेक-इन (वैरिएबल नामकरण, टिप्पणी की गुणवत्ता, कॉन्फ़िगरेशन स्थान) को अस्वीकार करने के कारण मुझे बहुत मानक लगते हैं।

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

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


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

14

अन्य उत्तरों के अतिरिक्त:

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

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

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

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

इसलिए ...

.. यह हो सकता है कि आप अधिक प्रतिक्रिया प्राप्त कर रहे हैं क्योंकि आपके पास कुछ बनाने की क्षमता है। :)


यह बहुत सारे अच्छे अंक बढ़ाता है।
sevenseacat

13

यह पूरी तरह से संभव है कि आप एकल हो रहे हैं क्योंकि ... आप एक जूनियर डेवलपर हैं।

आपके विवरण से, ऐसा लगता है कि आपने मानक का पालन नहीं किया क्योंकि टीम लीड इसे मानती है

समाधान सरल है:

  • यदि यह मानक है, तो इसका पालन करें।
  • यदि आप मानक नहीं समझते हैं, तो स्पष्टीकरण के लिए पूछें।
  • यदि मानक या निर्देशों की आपकी व्याख्या टीम लीड से अलग है, तो स्पष्टीकरण के लिए पूछें

इससे बाहर लड़ाई मत करो; यदि आप टीम को "गलत" बनाने का प्रयास करते हैं तो भी अगर आप जीत जाते हैं, तो आप हार जाते हैं। उचित सबक सीखें और आगे बढ़ना जारी रखें।


1
"टी" के लिए कुछ "मानक" का पालन करने की कोशिश कर रहा है जब कोई डॉर्क के साथ काम कर रहा है जैसे वह बताता है कि यह बहुत अच्छा नहीं होगा। यह परिभाषाओं और शब्दार्थों पर एक अंतहीन तर्क होगा।
3

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

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

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

1
मुझे लगता है कि वह अपनी टिप्पणी में एक वाक्यांश के रूप में "Laziness और imcompetent" का इस्तेमाल करते हुए Woot4Moot के बारे में बता रही है। मुझे लगता है कि आपका उत्तर ठीक है क्योंकि यह ओपी को कुछ संभोग और कमरा देता है ताकि वह वास्तव में क्या हो रहा है उसकी व्याख्या के आधार पर कार्रवाई कर सके।
jmort253

10

लेखक का नोट

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

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

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

यह महत्वपूर्ण है कि आप भरोसा करें कि आपकी टीम लीड पुरुषों और महिलाओं को समान रूप से व्यवहार करती है। यदि वह सबूत नहीं है, तो वह पुरानी कहावत लागू होती है: अपना वातावरण बदलें या अपना वातावरण बदलें।

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

अब आपके द्वारा उठाए गए मुद्दों पर:

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

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

यदि आपकी टीम ने कोडिंग दिशानिर्देश लिखे हैं, तो उनका अनुसरण करें। यदि वे नहीं करते हैं, तो आपकी भाषा के लिए कुछ प्रकार के सामुदायिक सम्मेलन होने चाहिए (For .NET और C #, Microsoft का एक मानक है जिसे बहुत सारी कंपनियां अनुसरण करती हैं)।

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

यदि वह आपके साथ उचित व्यवहार कर रहा है, तो वह यह देखेगा और यह उसकी चीजों की सूची में सबसे ऊपर होना चाहिए। यदि वह आपके साथ उचित व्यवहार नहीं कर रहा है, तो आपके पास गोला-बारूद है यदि ऐसा होता रहता है।

"मैं इसे बाद में प्राप्त करूंगा" कहना बुरा है। बाद में कभी नहीं होता। सही समय पर करें। प्रोग्रामिंग में बाद में नहीं है।

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


1
मैं "बाद में इसे प्राप्त करूंगा" के बारे में दूसरी टिप्पणी करूंगा। अगर मुझे हर बार ऐसा लगता है कि मैंने सुना है, तो मैं इस टिप्पणी में यहाँ नहीं लिखूंगा। :-)
एरिक किंग

.Net के लिए स्टाइल कॉप है। इसे चालू करें, ताकि जब तक स्टाइलकॉप खुश न हो, तब तक कोड का निर्माण नहीं होगा। यह मानव विषय को दूर करता है कार्य-बल बदमाशी है। आप देखते हैं, यह जानने में तकनीक आपकी मदद कर सकती है कि माइकल फेल्प्स # 1 या # 2 थे। फिगर स्केटिंग में, हालांकि ... figureskating.about.com/od/famousskaters/tp/scandals.htm एक टीम का नेतृत्व होने के नाते बिजली ट्रिपिंग के बारे में नहीं होना चाहिए। एक टीम में [dis-] पसंदीदा नहीं होना चाहिए। यह सुनिश्चित करने के लिए सावधान रहना चाहिए कि इस तरह का इंप्रेशन न बने। ऐसा करने का एक अच्छा तरीका नियमों को चालू करना है जो कोड की जांच करेगा और आपको निष्पक्ष उत्तर देगा।
नौकरी

3

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

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

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

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

कृपया बिना कुछ लिए लिंग कार्ड खेलना बंद करें । मुझे लगता है कि यह अविभाजित है और लैंगिक समानता की अवधारणा को कमजोर करता है।


1

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

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

यह काम करो इसे सही बनाओ यह जल्दी करो

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

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

एक जूनियर के रूप में लोगों को एक कंपनी कोडबेस में रास्ता निकालना मुश्किल है।

सर्वश्रेष्ठ: दस्तावेजित कोडिंग मानक हैं - और आप उम्मीद करेंगे कि उन पर पकड़ बनाई जाएगी।

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

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

और यह एक और (अंतिम) सलाह की ओर जाता है: लड़के स्काउट नियम का पालन करें !

हमेशा एक बेहतर स्थिति में कोडबेस को छोड़ दें, जितना वह था। यहां तक ​​कि अगर आप जिस आसपास के कोड के साथ काम कर रहे हैं, वह बुरा है, तो आप को साफ करें - और यदि आपके पास समय है तो परिवेश को ठीक करें।


0

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

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

दूसरी ओर एक त्रिशंकु सहकर्मी त्रुटि संदेशों की सत्यता की देखभाल करने के लिए बहुत अधिक दोषी हो सकता है ... इसलिए सोमवार की सुबह आपका कोड करने के लिए सही समय हो सकता है :-p

दफ्तर या कार्यस्थल में व्यक्तित्व की चर्चा सचमुच होती है। उम्मीद है कि आप सीख सकते हैं कि किसे बचना है और कब उनसे बचना है। अपने आप पर बहुत कठिन मत बनो :-) आप हमेशा नौकरी छोड़ सकते हैं और दूसरी नौकरी पा सकते हैं!


1
नौकरी छोड़ने से पहले खोजें, यदि आप नियोजित नहीं हैं, तो बहुत सारे काम पर रखने वाले प्रबंधक भी साक्षात्कार नहीं करेंगे।
वूट 4Moo

-2

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

मैं यह नहीं कह रहा हूं कि क्लीन कोड और मानक महत्वपूर्ण नहीं हैं, लेकिन ग्राहक और उत्पाद समयरेखा को किसी ऐसी चीज़ में वर्तनी की त्रुटि के कारण पीड़ित नहीं होना चाहिए, जिसे कोई भी गैर-तकनीकी व्यक्ति, ग्राहक या कार्यकारी कभी देखने वाला नहीं है।

उस के साथ, ऐसा लगता है कि आप ऐसे वातावरण में काम कर रहे होंगे जहाँ अपेक्षाएँ स्पष्ट नहीं हैं, या आप आवश्यकताओं को पूरी तरह से नहीं समझते हैं, जो भी कारण हो।

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

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

प्रत्येक संगठन यह ड्रैकुअन नहीं है, और आप अपने व्यक्तित्व, शैली और संचार आवश्यकताओं के लिए अन्य काम के वातावरण को अधिक अनुकूल पा सकते हैं।


2
यह "ड्रैकोनियन" नहीं लगता है; स्थिरता बनाए रखने में एक महत्वपूर्ण घटक है, गुणवत्ता में स्थिरता एक महत्वपूर्ण घटक है और गुणवत्ता सॉफ्टवेयर में समय पर और 'समझौता कोड' की तुलना में कम लागत पर शिपिंग की अधिक संभावना है। यह उत्साहजनक हो सकता है कि 80% सॉफ़्टवेयर कंपनियां गुणवत्ता से समझौता करने और परिणामों को भुगतने के लिए उत्सुक हैं, इसलिए "गैर-ड्रैकियन" रोजगार के अवसरों की कोई कमी नहीं है। :)
weberc2

1
मैं ऐसे माहौल में काम नहीं करना चाहता जहाँ बुनियादी परंपराएँ लागू न हों । यदि कोई परियोजना अपने कोडिंग दिशानिर्देशों का बचाव करती है, तो यह लंबे समय में अप्राप्य हो जाता है। विशेष रूप से चर नामकरण एक छोटी सी बात नहीं है: एक निश्चित मैट्रिक्स को कितना मौजूदा कोड कहा जाता है A, इससे कोई फर्क नहीं पड़ता , मैं कभी भी एक प्रतिबद्ध नहीं मानता जो किसी अन्य मैट्रिक्स Bको स्थिरता के लिए कहता है । बेशक, मुझे नहीं पता कि ओपी का मतलब "नकल" [...] कहीं और इस्तेमाल किया गया "ठीक है, हालांकि, मैंने जो कुछ कोड की गुणवत्ता को देखा है, वह इन पंक्तियों के साथ हो सकता है।
सेमीस्टर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.