खामियों का सामना करना और इससे अपमानित होना [बंद]


84

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

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

धन्यवाद।


17
शायद डिजाइन सही था, बस एक अलग प्रणाली के लिए; ;-) अपने कोड / डिजाइन में अपने अहंकार का निवेश न करें, स्नेह की उम्मीद करने के लिए बहुत सारे कारक हैं; अपनी इच्छा, ईमानदारी (विशेष रूप से आत्म-ईमानदारी), और टीमवर्क सीखने की इच्छा के बजाय निवेश करें। डिजाइन दिन 1 पर बिल्कुल सही हो सकता है, और आवश्यकताओं को 2 दिन बदल जाता है! इससे सीखें और आगे
बढ़ें

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

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

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

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

जवाबों:


177

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

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

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

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


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

1
आपका अधिकार जिसे लोग भूल जाते हैं। मैंने एक बार बॉटेड डीबी अपग्रेड पर एक बार आधे दिन के लिए कंपनी को नीचे ले जाने में मदद की। वह एक भयानक दिन था, लेकिन मैं इसके ऊपर हूं और मुझे लगता है कि बाकी सभी भी हैं।
19atz में क्रेट्ज

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

1
@BiAiB उपाध्यक्ष- usally का अर्थ है "कमांड में दूसरा"।
जोनाथन हेंसन

2
@Greg H: "bizzarely detached?" नहीं, केवल तर्कसंगत। कोई अच्छा काम करने की कोशिश करता है जो गलती करता है, उस गलती से सीखता है। उस व्यक्ति को प्रतिस्थापित करने के बाद , जब वे बेहतर सीख गए, तो किसी और के साथ, जिनके पास अनुभव नहीं है , एक बुरा निर्णय है। वे नए आदमी के पास एक साफ रिकॉर्ड हो सकता है, लेकिन केवल इसलिए कि उसने कभी भी कुछ दिलचस्प करने की कोशिश नहीं की।
ज़ैन लिंक्स

33

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

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

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

  1. टीम को ठीक करने का प्रयास करें
  2. एक नई टीम खोजें (या तो आंतरिक रूप से या किसी नए नियोक्ता के लिए)।

20

जहां तक ​​मुझे पता है, मैं हमेशा मौलिक रूप से रक्षात्मक रहा हूं । यह मौलिक रूप से सही होने के समान नहीं है । अक्सर निर्णय 'x' लेने के समय के बीच परिस्थितियाँ बदल जाती हैं और जिस समय यह स्पष्ट हो जाता है कि 'x' एक गलत निर्णय था

यह आपके अमेरिकी आयकरों को तैयार करने जैसा है। बहुत सारे लोग सोचते हैं कि इसका उत्तर होना चाहिए। वहाँ नहीं है आपकी अपनी राय है; आपके कर एकाउंटेंट की अपनी राय है; IRS की अपनी राय है।

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

जहाँ तक गलतियों को स्वीकार करने की बात है, मुझे लगता है कि क्षमता और अनुभव हासिल करने के लिए यह आसान हो जाता है। मेरे अनुभव में, आप जितना नया डिजाइन और विकास करेंगे, आप उतनी ही कम गलती स्वीकार करेंगे।

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

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


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

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

8

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

"अपमान" कभी नहीं होना चाहिए। यह किसी व्यक्ति के प्रदर्शन में सुधार की संभावना नहीं है।

यहां मेरी कंपनी में हमने उन लोगों के लिए सम्मान की संस्कृति विकसित की है, जो अभी भी कठिन फैसलों पर अपनी गर्दन को छड़ी करने के लिए तैयार हैं, लेकिन गलत होने पर स्वीकार कर सकते हैं और जरूरत पड़ने पर अपने व्यवहार को समायोजित कर सकते हैं।


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

6

क्या आपने हमेशा प्रस्तावित सॉफ्टवेयर डिजाइन में मौलिक रूप से सही हैं?

हाँ, मैं एक अलौकिक हूँ! खैर, बिल्कुल नहीं।

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

नहीं! अगर ऐसा होता है, तो टीम भावना के साथ कुछ गड़बड़ है।

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

पहली गलतियाँ बुरा लग सकता है, लेकिन आपके द्वारा उनमें से सैकड़ों बनाने के बाद, यह नौकरी के हिस्से की तरह है।


4

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

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

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

  1. मान लिया आपने गलती की
  2. इसे ठीक करने के लिए एक योजना बनाएं
  3. सुनिश्चित करें कि आपकी योजना वास्तव में काम करेगी
  4. फिर से सुनिश्चित करें।
  5. इसे ठीक करो!

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

एक आखिरी बात, आराम करो! गलतियां सबसे होती हैं। बहुत कम लोगों को यह पहली बार परफेक्ट लगता है


3

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

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


3

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

यदि पूर्व, तो बुरा महसूस करने का कोई कारण नहीं है और भविष्य में आपके साथियों पर आपको संदेह करने का कोई कारण नहीं है।

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

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

जल्दी पहचानी गई गलतियाँ ठीक करना आसान और सस्ता है। जब तक आप एक ही गलतियों को बार-बार नहीं दोहरा रहे हैं, तब तक उन्हें बहुत क्षमा मिलनी चाहिए। सहकर्मी की समीक्षाओं से गलतियों को जल्दी पकड़ना आसान हो जाता है।

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


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

एक वरिष्ठ संसाधन के रूप में मुझे उन चीजों को जानना चाहिए था। मुझे यकीन है कि मेरी टीम भी यही सोचती है।
user20358

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

3

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

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

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


3

जब तक वे " मंडे मॉर्निंग क्वार्टरबैक " नहीं हो जाते । मेरे पास किसी ऐसे व्यक्ति के लिए कोई उपयोग नहीं है जो सभी डिजाइन चर्चाओं के माध्यम से बिना कुछ कहे केवल दावा करता है कि वे जानते थे कि यह तथ्य के बाद काम नहीं करेगा। रचनात्मक संदर्भ में न रखे जाने पर भी आपको आलोचना करने में सक्षम होना चाहिए।

संभवतः एसओ साइट की सबसे अच्छी विशेषताओं में से एक जोखिम लेने और प्रस्ताव और अनिश्चित समाधान करने में सक्षम होना है। यह आप कैसे सीखते हैं। अपने सिर में बकवास का एक गुच्छा के साथ जीवन के माध्यम से जाना जो गलत है, लेकिन आपको कभी भी इसके बारे में नहीं बताया गया है, यह अज्ञानता है।

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


2

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

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


1

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


1

ऐसा अक्सर होगा। हमारा उद्योग इतनी तेजी से बदल रहा है, कभी भी गलत नहीं होने की संभावना प्रभावी रूप से शून्य है।

हालांकि, क्या आपने उनकी आपत्तियों पर उनके डिजाइन को खराब किया है? यही कारण है कि वे ओवररिएक्ट कर रहे हैं।

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

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

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


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

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

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

0

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

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


0

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


0

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

खुद को सही ठहराने या रक्षात्मक होने की कोशिश मत करो। गलती को स्वीकार करें और आगे बढ़ें।


0

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

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

यह हर जगह समान है: यह एक सामाजिक व्यवहार है, चाहे वह किसी भी तरह की समस्या हो।

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


0

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

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


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


मैं कोई
जोंक

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

मुझे सीखने में कोई आपत्ति नहीं है। यह सिर्फ प्रतिष्ठा यू खो देता है, भले ही आप हर बार अलग-अलग होते हैं। इसके आसपास के सभी लोगों को अभी भी ऐसा लगता है कि आपने कई गलतियाँ की हैं। हर बार एक नया नहीं, जिससे आप सीखे और बेहतर बने।
user20358
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.