किसी को बुरा प्रोग्रामर कब माना जाएगा? [बन्द है]


57

आप इस बात पर कैसे विचार करेंगे कि एक प्रोग्रामर जो कुछ कर रहा है उसमें वह खराब है?

यदि संभव हो तो ... उसे कैसे सुधार करना चाहिए?


3
क्योंकि कहा गया व्यक्ति प्रोग्रामिंग से संबंधित वेबपेज पर उत्तर स्वीकार नहीं करता है। किडिंग :-)
डैनियल

1
@EvanKroske: नहीं, यह सही नहीं है .... सामुदायिक विकी पदों के सहयोग को संपादित करने की अनुमति देने के लिए मौजूद है। इन्हें भी देखें: हमारा मेटा - टैग: समुदाय-विकी
तमारा विजसमैन

बहुत सारे प्रश्नों में, एक भी उत्तर को स्वीकार करना असंभव है। इन्हें भी देखें: हमारा मेटा - सर्च: स्वीकार करें
तमारा विजसमैन

प्रत्येक प्रश्न का उत्तर नहीं मिलता है जो वास्तव में समस्या का समाधान करता है।
लोरेन Pechtel

जवाबों:


134

जब वे अपनी गलतियों से और साथियों की समीक्षाओं से सीखने में असफल हो जाते हैं।

हम सभी कुछ बिंदु पर हरे हैं; हालाँकि, यदि आप बेहतर नहीं हो रहे हैं या बेहतर होने का प्रयास कर रहे हैं तो आप एक खराब प्रोग्रामर हैं।


4
सहमत - आपके पास एक प्रतिक्रिया पाश है, हमेशा अपनी गलतियों से सीखते हुए।
मार्सेल लमोटे

1
@PSU अच्छी तरह से कहा। किसी भी शिल्प की तरह, प्रोग्रामर ट्रेडमैन होते हैं और हमेशा सही नहीं होते हैं, हमेशा सीखते हैं लेकिन यदि आप गलतियों से सीखने में असफल होते हैं तो आप अपने शिल्प में सुधार नहीं कर रहे हैं।
क्रिस

2
वह बहुत व्यापक परिभाषा है; यह केवल प्रोग्रामर तक सीमित नहीं है। यह वैज्ञानिकों, रसोइयों, खिलाड़ियों, अनुवादकों, चौकीदारों, फोटोग्राफरों और वास्तव में किसी भी पेशे पर लागू होता है ।
21

13
सप्ताह में कम से कम एक बार सभी का मनोबल।
एमआईए

@RegDwight: और आपकी बात थी ...?
19

125

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


16
अगर मैं इस 100x को बढ़ा सकता हूं, तो मैं करूंगा। थोड़ी विनम्रता और सीखने की भूख लंबे समय में बहुत कुछ बनाती है।
विलियम पीट्री

1
नग और विलियम के लिए भी +1। यह एक खराब "प्रोग्रामर" का सबसे विशिष्ट मानदंड है।
फेब्रिक

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

@snOrfus, आपको सिखाने के लिए एक संरक्षक का पता

75

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

लेख से:

प्रोग्रामर जो समझते हैं कि कोड क्या करता है, लेकिन यह कैसे नहीं करता है।

3
* और उस तकनीक में कुछ समय से कोडिंग कर रहा है
जो फिलिप्स

5
यह लगभग सभी प्रोग्रामर्स पर लागू होगा जिन्होंने कभी जावा / स्प्रिंग या रूबी जैसे फ्रेम के साथ कुछ वेब डेवलपमेंट किया है। वे ढांचे काले जादू से भरे हैं जिन्हें सामान्य प्रोग्रामर आमतौर पर समझने की जहमत नहीं उठाते।
लापता

3
@ मिक्सिंग फकीर - और इसलिए, यह कहना गलत नहीं होगा कि अधिकांश प्रोग्रामर जो ऐसा करते हैं, वे महान प्रोग्रामर नहीं हैं :)
seanmonstar

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

4
@Missing Faktor: वे उन पुस्तकालयों और रूपरेखाओं के आंतरिक पहलुओं को नहीं समझ सकते हैं जो वे ठीक उपयोग करते हैं, लेकिन उन्हें कम से कम यह जानना चाहिए कि उनके कोड में प्रत्येक चीज़ क्या है: "फ़ॉर्बर्स को सूँघने के लिए", "क्योंकि प्रलेखन यह है कि यह है" अंतरिक्ष-समय सातत्य की अखंडता को बनाए रखने की आवश्यकता है ", आदि
सैमबी

45

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

एक कोरोलरी तब होती है जब वे एक ही प्रोग्रामिंग प्रश्न पूछते हैं कई बार संकेत करते हैं कि वे जानकारी को आंतरिक नहीं कर रहे हैं।


आह हाँ, मैंने उसके साथ काम किया। अतीत काल, सौभाग्य से।
माइक वुडहाउस ऑक्ट

1
कुछ लोग सभ्य प्रश्न बनाने में भी सक्षम नहीं होते हैं, जो आपसे "बस इसे ठीक करने" के लिए कह रहे हैं
deltreme

21

जब FizzBuzz समस्या को हल करने में उन्हें लंबा समय लगता है।


1
मुझे लगता है कि अच्छे प्रोग्रामर बनने की क्षमता वाले कुछ शुरुआती लोग हो सकते हैं - जिन्हें इससे परेशानी है।
जद इसाक्स

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

8
मेरा तर्क है कि इसे किसी को भी नहीं लेना चाहिए जिसने इसे हल करने के लिए प्रवेश स्तर के प्रोग्रामिंग कोर्स को सफलतापूर्वक समाप्त कर लिया है।
एप्सिलॉनवेक्टर

4
यदि कोई शुरुआत FizzBuzz को हल नहीं कर सकता है, तो उसे प्रोग्रामिंग नौकरियों के लिए आवेदन नहीं करना चाहिए। यदि आप प्रोग्राम करने में सक्षम होने का दावा करते हैं (उदाहरण के लिए, प्रोग्रामिंग जॉब के लिए आवेदन करके), तो आपको FizzBuzz को हल करने में सक्षम होना चाहिए।
चिन्मय कांची

1
FizzBuzz पर Stackoverflow सवाल अच्छी तरह से देखने लायक है। अजगर समाधान की जाँच करें जो विभाजन या मापांक का उपयोग नहीं करता है। stackoverflow.com/questions/437/…
गॉर्डन

21

प्रोग्रामर जो नई तकनीकों / भाषाओं को सीखने से इनकार करते हैं, और जो वे पहले से जानते हैं, उससे चिपके रहने पर जोर देते हैं।


परिशिष्ट: (टिप्पणी में नीचे डैश ने क्या कहा)

इसका एक विस्तार ऐसे लोग हैं जो कुछ प्रौद्योगिकी की कार्यक्षमता का सबसेट जानते हैं, लेकिन इसके बारे में अधिक जानने के लिए कोई इच्छा नहीं दिखाते हैं। प्रोग्रामिंग भाषा, संपादक, अन्य उपकरण ...


6
... और अच्छे कारणों के लिए, मुझे जोड़ना चाहिए।
अक्टूबर

18

जब एक टीम का सदस्य नकारात्मक उत्पादक निर्माता होता है

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

मतलब आपकी बाकी टीम को खराब डेवलपर की वजह से ज्यादा काम करना पड़ता है। NNPP


1
मैं सहमत हूं - ये लोग अपनी टीम के लिए बेहद हानिकारक हो सकते हैं।
मार्सेल लैमोथे

44
हुह ... मैंने कल बेमानी कोड की 500 लाइनें हटा दी हैं, और बग का परिचय नहीं दिया है। LOC मेट्रिक्स हानिकारक माना जाता है?
13

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

5
LOC मैट्रिक्स बेकार नहीं हैं। वे HARMFUL हैं। इसके अलावा, अधिकांश आधुनिक भाषाओं में LOC की गिनती बहुत कठिन है। लेकिन, मीट्रिक यहाँ बात नहीं है। यह सिर्फ कह रहा है | काम बनाने के लिए | - - काम जो गलत था | - - ठीक करने के लिए काम करते हैं। ... यानी यदि आपको 10 घंटे लगे हैं, तो आपको 6 घंटे काम करने में लग गए हैं, जिसे आखिरकार तय करना है और ऐसा करने में 6 घंटे और लगते हैं, तो आप -2 घंटे हैं। समय वास्तव में वही है जो आप वैसे भी पाने की कोशिश कर रहे हैं।
मिया

1
एलओसी मेट्रिक्स यह मापने का एक शानदार तरीका है कि कितने स्थानों पर कीड़े को छिपाना है।
SamB


15

जब वे जानते हैं कि चीजों को करने के बेहतर तरीके हैं लेकिन फिर भी समय होने पर भी उन्हें करने से मना कर दिया जाता है।


लेकिन "बेहतर" के बारे में विशेषज्ञ असहमति हो सकती है।
डेरेनडब्ल्यू

@DarenW - मैं यह नहीं कहूंगा कि कोई व्यक्ति एक बुरा प्रोग्रामर है क्योंकि उन्होंने एक विवादास्पद विषय पर एक पक्ष लिया है, लेकिन जब उनके पास अपने स्वयं के दिमाग में एक निश्चित विकल्प होता है।
जेफ ओक्ट

15

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


5
क्या होगा अगर वे कुछ भी गलत नहीं पा सकते हैं, और इससे उन्हें चिंता होती है?
सैमब

1
या इससे भी बदतर, वे कुछ भी गलत नहीं पाते हैं और इसे ठीक करने की कोशिश करते हैं।
तून Krijthe

15

जो अपने कोड पर चेतावनी को नजरअंदाज करते हैं और त्रुटियों पर ही ध्यान देते हैं।


14

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

  1. अतीत में अप्रशिक्षित या Ossified
    जब 'प्रोग्रामर' नई प्रणाली, नए टूल या जो कुछ भी तैनात किया जा रहा है, उसे अवशोषित करने में सक्षम नहीं लगता है, भले ही प्रशिक्षण / शिक्षा कैसे भी हो। बार-बार प्रशिक्षण के आधार पर कहा गया है।
    जब 'प्रोग्रामर' केवल उस तकनीक या कोडिंग प्रतिमान को जानता है जो उन्होंने 10 या 15 साल पहले इस्तेमाल किया था। यह तब काफी अच्छा था, इसलिए उन्हें क्यों बदलना चाहिए?
  2. काउबॉय कोडर
    वह व्यक्ति जो बिना किसी योजना के पहले कोड करता है। 'प्रोग्रामर' जो उत्पादन कोड और / या डेटा में अप्रयुक्त परिवर्तन करता है "क्योंकि हम इसे अभी तय कर लेते हैं" और फिर "फिक्स" विफल होने पर आश्चर्य होता है।
    काउबॉय भी निश्चित रूप से टीम के खिलाड़ी नहीं हैं। कोई बदबूदार टीम की जरूरत नहीं है।
  3. वेदर-वेन
    यह 'प्रोग्रामर' "टेक्नॉलॉजी डू पत्रिकाओं " से ओत-प्रोत है और हर नए ढांचे, भाषा, कार्यप्रणाली या जो भी नया और गर्म है, उसे देखता है ।
  4. "बिग ब्रेन"
    यह 'प्रोग्रामर' उनकी प्रतिभा और क्षमताओं के बारे में इतना सुनिश्चित है कि वे काम किए जाते हैं जो बहुत सारे प्रोजेक्ट अर्थ नहीं बनाते हैं। उदाहरण के लिए एक मानक पुस्तकालय को फिर से लिखना "क्योंकि यह हमारी प्रणाली के लिए अक्षम है" या हाथ में समस्या के लिए उपयुक्त उपकरण और तकनीक का परिचय नहीं है। उदाहरण के लिए एक मेनफ्रेम वातावरण में लिस्प या फोर्थ का परिचय।
  5. LOC ए। Sandbagger
    यह 'प्रोग्रामर' एक को बढ़ाने के लिए मोटापे और गलत दिशा का उपयोग करता है। LOC: कोड की पंक्तियाँ जिनके लिए भुगतान किया जाता है। मैंने इस स्थिति में कोड देखा है जो पृष्ठ के बाद पृष्ठ था, डुप्लिकेट संरचना और तर्क की स्क्रीन के बाद स्क्रीन, केवल अनुच्छेद या नियंत्रण चर नामों के साथ लाइन की गिनती को पंप करने के लिए बदल दिया गया था।
  6. अपरिहार्य विशेषज्ञ
    'प्रोग्रामर' जिनके पास हाथ में समस्याओं को हल करने के लिए डोमेन ज्ञान है, लेकिन चूंकि वे इसके बारे में सब कुछ "जानते" हैं। तथ्य की बात के रूप में, अगर वे एक बस से टकरा जाते, तो पूरा संगठन दुर्घटनाग्रस्त हो जाता। { अवलोकन: जो लोग सोचते हैं कि वे अपरिहार्य हैं वे आमतौर पर हैं। (किसी को भी इस aphorism पर स्रोत मिल गया?)}
  7. पास्ता शेफ
    दिस 'प्रोग्रामर' स्पैगेटी कोड में माहिर है, ऐसे पहचानकर्ताओं के साथ है जो सिंटैक्टली कार्यान्वित आईडीई के बिना पालन करना बहुत कठिन है। जैसे IndexI1O0, Index1I0O इत्यादि।
  8. समर इंटर्न - विशेष रूप से उपप्रकार चलना आपदा आपदा
    मेरी पुरानी दुकान कई देर से हाई स्कूल या कॉलेज की उम्र के इंटर्न को किराए पर देती थी। एक बार कुछ उपकरणों के उपयोग को ट्रैक करने के लिए एक विभाग को एक छोटे डेटाबेस की आवश्यकता थी, (अब यह वापस आ गया था, और यह dBase III का उपयोग कर रहा था)। उस लड़के ने सारी गर्मी साथ में कोड की, लेकिन जब कॉलेज गिरने की शुरुआत हुई तो ऐसा नहीं किया गया था। उन्हें एक सप्ताह का विस्तार मिला तो दूसरे सप्ताह का। दूसरे सप्ताह के अंत में, मुझे उसके प्रोजेक्ट को लेने और सिस्टम डेवलपमेंट में वापस लाने के लिए बाहर भेजा गया। उसने मुझे वह सामान दिखाया जो उसने किया था, और फिर अधूरा हिस्सा। क्या काम किया अच्छा आंख कैंडी था, लेकिन आवेदन थाअधूरा। जब मैंने प्रतियाँ प्राप्त करने के लिए स्वरूपित फ़्लॉपीज़ का नया बॉक्स खोला, तो उन्होंने कहा, "बस एक सेकंड, मुझे अपनी परीक्षण फाइलें हटाने दें ..." और इससे पहले कि मैं कुछ कह पाता, उन्होंने फाइलों का एक गुच्छा हटा दिया।
    संदिग्ध प्रकार के होने के नाते, और पाया कि उनका आवेदन लगभग कुछ भी नहीं था लेकिन आँख कैंडी जब मैं अपनी दुकान पर वापस आ गया, तो मैं विभाग में वापस गया और नॉर्टन को बाहर निकाला और उन फ़ाइलों को हटा दिया, जिन्हें उन्होंने हटा दिया था, कुछ अतिरिक्त तर्क खोजने की कोशिश कर रहे थे, अधूरा होने पर भी।
    मैंने पाया, बुरा तर्क नहीं, बल्कि बुरा व्यवहार। वह जिस पीसी का उपयोग कर रहा था, उससे जुड़ा प्रिंटर एक डेज़ी व्हील प्रिंटर था। सामान्य रूप से लगाया जाने वाला वर्ण एक स्विस संस्करण था। हटाए गए कार्यक्रमों के आउटपुट में एक नाम, पता, डीओबी, कुछ अक्षर कोड और कुछ प्रकार के आईडी नंबर होते हैं। प्रारूप और लेआउट ने मुझे परेशान किया। कई लोगों के लिए सभी जन्म तिथियां मुश्किल से पीने की उम्र थी। अधिकांश पते वहां नहीं थे, जब मैंने उन्हें हमारे criss-cross डायरेक्टरी में देखा। जब मैंने उसके पर्यवेक्षक को प्रिंटआउट दिखाया, तो उसने मेरी तरफ देखा और कहा "ड्राइवर लाइसेंस, क्या आपको नहीं लगता?" मैंने कहा मैंने ऐसा किया। उन्होंने कहा कि इसीलिए उन्होंने जेरोक्स के बगल वाले कूड़ेदान में पारदर्शिता स्टॉक पाया। हमारे बुरे लड़के ने अपने ड्राइवरों के लाइसेंस पर उसकी और उसके दोस्तों की उम्र को समायोजित करने के लिए ओवरले बनाया था। हमने इसकी सूचना अधिकारियों को दी।अपने पिछले दो सप्ताह के लिए भुगतान नहीं किया।

ये सिर्फ कुछ बुरे चरित्र हैं जिनके साथ मुझे काम करना था ...।

/ एस / बेजेंटसॉफ्ट


RE "जो लोग सोचते हैं कि वे अपरिहार्य हैं आमतौर पर" मुझे en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
डेवडेव

10

खुद को आगामी तकनीकों के अनुकूल बनाने में असमर्थ


10

ज्ञान / क्षमता की स्पष्ट कमी के अलावा, एक प्रोग्रामर एक बुरा है, अगर उनका कोड पढ़ने और / या उससे अधिक बनाए रखने के लिए कठिन है।


1
और प्रोग्रामर एक बहुत बुरा है जब वह एक कोड को अच्छी तरह से नहीं पढ़ सकता है :-)
मनिएरो

4
यह लगभग हर कोई नहीं होगा? मेरा मतलब है, कोड लगभग हमेशा पढ़ने और / या इसे बनाए रखने की तुलना में कठिन नहीं है?
सैमब

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

10

जब कोई और उसका कोड नहीं पढ़ सकता है। इससे कोई फर्क नहीं पड़ता कि आप कितने उज्ज्वल हैं; कोई प्रोग्रामर एक द्वीप नहीं है।


ठीक है, अगर वह अनलम्बदा में लिख रहा है, तो किसी को इसे पढ़ने में सक्षम नहीं होना चाहिए।
सामब

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

7

कोई है जो विवरणों पर ध्यान नहीं देता है और हमेशा "यह काम करता है, इसलिए मैं इसे अकेला छोड़ रहा हूं। लॉग में सभी अपवाद अपवाद नहीं हैं" मोड।


7

मेरे लिए प्रोग्रामर के लिए दो श्रेणियां हैं - सोलो और टीम।

खराब सोलो प्रोग्रामर हैं

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

खराब टीम प्रोग्रामर वे हैं जो खराब सोलो प्रोग्रामर श्रेणी में आते हैं, जिनमें शामिल हैं

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

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

@ जेम्स कृपया मेरी अंग्रेजी बहाना;)। मेरा मतलब है कि अगर कोई प्रोग्रामर कुछ दिनों बाद अपने कोड को देखने के लिए वापस आता है और उसका कोई सुराग नहीं है, तो यह एक बुरा संकेत है। मुझे यह भी याद नहीं है कि कुछ दिनों पहले मैंने कैसे और क्या किया, लेकिन मुझे यकीन है कि मुझे अपना कोड देखते समय अपना सिर खुजाना नहीं पड़ेगा और कहूंगा कि 'मैं क्या सोच रहा था?'
तिया

@ नाम: वास्तव में, उसे अपने कोड का दस्तावेज बनाना चाहिए ताकि यह मायने नहीं
रखे

4

स्वीकार करने के लिए तैयार नहीं वे जवाब और / या चीजों को देखने के लिए तैयार नहीं जानते हैं।

यदि आप इसे नहीं जानते हैं, तो हार न मानें - इसे समझें और इसे पूरा करें।


4

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

आप जानते हैं कि मेरा क्या मतलब है: जब आप कुछ बहुत ही हैक करने के लिए मजबूर होते हैं क्योंकि ऐसा करने का कोई बेहतर तरीका नहीं है।

अच्छे प्रोग्रामर ऐसा करने से नफरत करेंगे और इनलाइन टिप्पणियों में कहेंगे कि उन्हें उस तरह के हैक में डालने से कितना नफरत है, लेकिन कोई विकल्प नहीं है। खराब प्रोग्रामर सिर्फ हैक में डालेंगे और टिप्पणी नहीं करेंगे।


3

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


3

बार-बार इसे करने का सही तरीका दिखाया गया है, और बार-बार इसे करने का आसान तरीका है।


3

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

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

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

मैं काफी समय से, ध्रुवीकरण की दिशा में इस प्रवृत्ति से लड़ रहा हूं, और मेरा व्यक्तिगत समाधान यह है कि मैं ऐसे किसी भी मूल्यांकन के लिए तीन शब्दों को लागू करना कहीं अधिक उपयोगी समझता हूं: " किस हद तक!"

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

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

इसलिए, मैं आपको दृढ़ता से सलाह देता हूं कि आप मेरे तीन छोटे शब्दों की कोशिश करें, "किस हद तक", और देखें कि वे आपको कितनी अच्छी दिशा में ले जा सकते हैं!


2

कोई है जो कहता है "यह नहीं किया जा सकता है"।

मेरी राय में यह समस्या हल करने के बारे में है, उपकरण वास्तव में काम करने की तुलना में बहुत कम प्रासंगिक होना चाहिए। यदि मुझे MS-Access या असेंबली भाषा का उपयोग करके इसे हल करना है, तो यह समय और धन की बात है, "यह नहीं हो सकता है"

एक चेतावनी संकेत बहुत कुछ करने के शैक्षणिक और "उचित" तरीके पर केंद्रित है, और काम पूरा करने पर पर्याप्त ध्यान नहीं है।


2
और जब वह कहता है कि यह क्यों किया जा सकता है?
मनेरियो

1
तो, कैसे एक समस्या को हल करने के बारे में? क्या यह किया जा सकता है?
पी शेव्ड

2
यदि यह असंभव नहीं है तो कुछ को खारिज करना बुरा है और इसके विपरीत।
रान्डेल शुल्ज

2
@ रैंडल शुल्ज: जहां तक ​​मैं क्रैग्सलिस्ट से कह सकता हूं, एक रॉक स्टार प्रोग्रामर कोई है जो एक विज्ञापन एजेंसी में विकास के सभी स्तरों (डेटाबेस, उपयोगकर्ता अनुभव, तैनाती, sysadmin और उपयोगकर्ता समर्थन) को संभालता है, जो सामान्य वेतन से काफी अधिक है। उन चीजों में से एक। वे उन्हें रॉक स्टार कहते हैं क्योंकि सप्ताह के 60 घंटों के बाद, उनका आहार किसी ऐसे व्यक्ति के समान होता है जो एक इकोलाइन वैन में यात्रा करता है और भोजन के लिए अपने गिटार को पोज देना होता है।
डैन मोनेगो

1
हाँ, मैंने एक व्यापक सामान्यीकरण बनाया :), लेकिन .. यह एक बिंदु बनाना था। "मेरी पेशेवर राय है कि यह नहीं किया जाना चाहिए" बेहतर है। इससे भी बेहतर "एक ही समस्या को अलग तरीके से हल करने के बारे में क्या"। मेरी बात यह है कि एक अच्छा प्रोग्रामर समाधान केंद्रित होना चाहिए। "यह नहीं किया जा सकता है", विकल्प की पेशकश के बिना ग्राहक को बहुत निराशा होती है।
डैन विलियम्स

2

यदि वह केवल एक भाषा के वाक्य विन्यास को जानता है, लेकिन एल्गोरिदम की मूल अवधारणाओं को नहीं जानता है।


2

जब वे बहुत कुछ करते हैं लेकिन बहुत कम पैदा करते हैं।



2

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


2

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


2

एक तात्कालिक मान्यता संकेत है कोई कह रहा है: "मुझे समझ नहीं आता कि यह काम क्यों नहीं करता है। मैंने सब कुछ ठीक किया।"


"मुझे समझ में नहीं आता कि क्यों काम करता है, यह सही नहीं है।"
रान्डेल शुल्ज

हाँ, यह कंप्यूटर बेवकूफ है कि :)
Dan Williams

2

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

मुझे एक बार एक ऐसी प्रणाली विरासत में मिली थी, जहां पूर्व डेवलपर ने (जावा में) फिर से लागू किया, एशटन टेट डीबीएस III + एपी का एक बड़ा सेट कस्टम डीबीएफ एक्सेस लाइब्रेरी के शीर्ष पर था। जावा संग्रह ढांचे में से कोई भी उपयोग नहीं किया गया था।

ऐसा इसलिए था कि वह एक जावा / स्विंग ऐप लिख सकता था जो डीबीएएस III + (या संभवतः क्लिपर) ऐप की तरह दिखता और काम करता था।

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

वह व्यक्ति स्पष्ट रूप से एक कुशल डेवलपर था। वह पर्याप्त जानता था कि वह उस परियोजना के समय सीमा में स्वयं उस पूरे सिस्टम को लिखने में सक्षम था। वह इसे कुछ अन्य आंतरिक प्रणालियों पर फिर से उपयोग करने में सक्षम था।

लेकिन वह एक भयानक प्रोग्रामर थे कि उनके कोड ने उन प्रणालियों की सुविधाओं का दुरुपयोग किया, जिन पर उन्होंने काम किया था। वह जावा / स्विंग / एसक्यूएल सीखने की तुलना में संदिग्ध लाभ के कस्टम दायित्व पर 3 महीने बिताने के लिए तैयार था।

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