एक "थियोरेटिशियन" प्रोग्रामर को समझने से बचें

Question

मैंने इस लेख को SO पर कई पोस्टों में पाया है । मैं अपने आप को 6 वें श्लोक में गिरता हुआ पाता हूं; "सिद्धांतवादी"।

यह "सिद्धांतवादी" को परिभाषित करता है:

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

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

यहां तक ​​कि जब एक साधारण परियोजना क्या होनी चाहिए, इस पर काम करते हुए, मैं स्क्रैच से सब कुछ खत्म करने के लिए इंजीनियर की कोशिश में फंस गया। अंततः व्यर्थ था)।

ऐसा करने से बचने में क्या बात मेरी मदद कर सकती है? और चुंबन सिद्धांतों से चिपके?

धन्यवाद

Comments

खैर, यह तथ्य कि आप प्रवृत्ति को पहचानते हैं एक अच्छी शुरुआत है!

— माइकल के

मुझे यह पसंद नहीं है कि कैसे लेख "सिद्धांतवादी" और "सुरुचिपूर्ण" जैसे शब्दों को "खराब" करने के लिए परिभाषित करता है।

— रीन हेनरिक

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

— एसके-लॉजिक

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

— बेरिन लोरिट्श

"यदि आप एक ही प्रोजेक्ट पर दो कोड काउबॉय डालते हैं, तो यह विफल होने की गारंटी है, क्योंकि वे एक-दूसरे के बदलावों को रौंदते हैं और एक दूसरे को पैर में गोली मारते हैं।" - यह शानदार है :)

— पी शेव्ड

Answer 1

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

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

Comments

हाँ! सैद्धांतिक प्रवृत्ति का मुकाबला करने के लिए एक और प्रोग्रामर का होना बहुत अच्छा काम करता है।

— माइकल के

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

— बॉब मर्फी

Answer 2

1. जो आप विकसित करने वाले हैं, उसके लिए लक्ष्य रखें।

2. निकट भविष्य में कुछ करने के लिए उन लक्ष्यों को संकीर्ण।

3. फिर उन लक्ष्यों पर ध्यान केंद्रित करें, अन्य सभी विचारों को समाप्त करें। कोई पृष्ठभूमि नहीं। कोई इतिहास नहीं। कोई एक्सटेंशन नहीं। कुछ भी सामान्य या सार नहीं।

4. फिर उन्हें बहुत कम में संकीर्ण करें आप ऐसा कर सकते हैं जो सुगम हो। अच्छा नही। लचीला नहीं है। बनाए रखने योग्य नहीं। केवल स्वीकार्य है।

5. फिर बहुत कम से कम आप कर सकते हैं को प्राप्त करने के लिए आवश्यक पूर्ण न्यूनतम में प्राथमिकता दें। बिंदु के बारे में एक सप्ताह में एक तारीख लेने और उस तिथि की ओर निर्माण करना है। यदि आप एक सप्ताह में कुछ नहीं दे सकते हैं। सीमित करें। ध्यान दें। ट्रिम। कम करें।

6. फिर फुलाना खत्म करें। आपके पास केवल एक सप्ताह है। काटते रहो।

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

---

मैंने सिद्धांतकारों के साथ काम किया है। मैं "एक्स्ट्रा" को एक बहाना मानता हूं जो वास्तव में ऐसा कुछ करने से बचता है जिसे असफलता करार दिया जा सकता है।

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

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

Comments

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

— जॉलीमॉर्फिक

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

— एस.लॉट

हाँ, मैंने "कठिन परिश्रम के रूप में लिया" का अर्थ है "करना कठिन काम है, और सिद्धांतकार भी इसे करने के लिए बहुत आलसी हैं", लेकिन "करने के लिए मनोवैज्ञानिक रूप से कठिन है" - कि यह अंतहीन और अधिक आरामदायक है अथक परिश्रम (कठिन!)। कुछ, वास्तव में इसे नीचे कील और इसे खत्म करने से।

— कार्सन63000 22

Answer 3

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

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

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

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

Answer 4

मुझे स्वयं यह समस्या हुई है। दो तकनीकों ने मदद की है:

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

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

Answer 5

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

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

यह कहना नहीं है कि आपका प्रश्न मान्य नहीं है - यदि आप चीजों को खत्म कर रहे हैं, तो यह सीखना अच्छा है कि उस प्रवृत्ति से कैसे बचें। लेकिन इस पंडित्री को अपने आप से कबूतरबाजी में बात करने न दें।

Answer 6

एक सरल दिशानिर्देश है, जो पूरी तरह से अनपैक होने पर, इस परिदृश्य से बचने के लिए पूरी तरह से समझाता है।

सबसे सरल काम करें जो संभवतः काम कर सकता है।

- कैंट बेक

Comments

या जैसा कि आइंस्टीन ने कहा: "सब कुछ जितना संभव हो उतना सरल बनाओ, लेकिन सरल नहीं।"

— इयान

समस्या यह है कि, एक सैद्धांतिक के लिए, "सरल" के बहुत सारे अर्थ हैं। मॉस्क का उपयोग करते हुए हास्केल में ओएस कर्नेल को फिर से शुरू करना एक सिद्धांतकार को "सादगी" में अंतिम रूप दे सकता है।

— क्रिस्टोफर जॉनसन

Answer 7

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

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

Answer 8

सरल :

1. व्यावहारिक हो ।

थियोरियन के विपरीत पक्ष (कि प्रोग्रामिंग डोमेन की जानकारी / ज्ञान पक्ष पर इसके फायदे हैं) व्यावहारिक है।

KISS, सूखा, एसओसी और सोच के अन्य तरीके से लागू करने के लिए इस जवाब में वर्णित के रूप , मतलब beeing व्यावहारिक।

आप इस पुस्तक को पढ़कर व्यावहारिक होना सीख सकते हैं:

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

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

इसलिए, बहुत अभ्यास करें। और बहुत कुछ सीखते हैं। लेकिन एक को दूसरे के ऊपर मत आने दो।

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

Answer 9

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

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

Answer 10

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

यहाँ 'वास्तविक प्रश्न' पोस्ट के बाद के आधे हिस्से में अधिक स्पष्ट है। विशिष्ट परियोजना लक्ष्य को जानें और उस छोर की ओर काम करें, किसी अन्य छोर की ओर नहीं। यह वास्तव में इस मामले में आत्म-अनुशासन का मामला है। इस पर अधिक के लिए एस। लोट का जवाब देखें :)।

Answer 11

प्रोग्रामिंग से अपने दिमाग को फिर से भरना और यहां तक ​​कि काम करने वाले सॉफ्टवेयर को डिलीवर करने के लिए चीजों को पूरा करना। यह आपकी प्राथमिकताओं को सही करता है।

इसे कैसे प्राप्त किया जाए यह एक और कहानी है। सबसे अच्छा तरीका है कि किसी परियोजना की कल्पना करें और इसे उत्पादन में लॉन्च करने के लिए सभी चरणों से गुजरें। उसके बाद आपकी पहले से अलग मानसिकता होगी।

Answer 12

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

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

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

Answer 13

अपने बॉस से एक संरक्षक प्राप्त करने के लिए कहें, और फिर गुरु के कहे अनुसार करें।

कठिन भाग ध्यान केंद्रित कर रहा है, और पहचान रहा है कि "हे, चलो ऑपरेटिंग सिस्टम को फिर से लिखें" आपको उस कार्य को पूरा करने के लिए पर्याप्त रूप से लाभ नहीं देगा जो आपको दिया गया है (यही कारण है कि एक परियोजना प्रबंधक नहीं करेगा)।

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

Answer 14

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

1. असतत कार्य शुरू करते समय , कुछ मिनट यह सोचने में बिताएं कि वास्तव में कार्यक्षमता, गुणवत्ता, वितरण तिथि आदि के रूप में क्या आवश्यक है ।
2. कोड के ग्राहक के लक्ष्यों को ध्यान में रखते हुए, उप-कार्यों, उप-उप-कार्यों इत्यादि में इसे तोड़ने के लिए योजना बनाने के लिए कुछ और समय लें ।
3. प्रत्येक आइटम के लिए समय का अनुमान लगाएं , अज्ञात के लिए 50% तक जोड़ना। यदि कोई आइटम चार घंटे से अधिक समय लेगा, तो उसे कुछ और नीचे तोड़ दें। (यदि मैं कॉलेज प्रोजेक्ट्स कर रहा था, तो मैं एक स्प्रेडशीट का उपयोग करूंगा, लेकिन कई क्लाइंट्स के साथ एक सलाहकार के रूप में, मैं एक समस्या-ट्रैकिंग प्रणाली का उपयोग करता हूं जिसे रेडमाइन कहा जाता है।)
4. सबसे महत्वपूर्ण बात: केवल उन वस्तुओं को करें जिनके साथ मैं आया था ।

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

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

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

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