कैसे बिल्लियों को चराने के लिए

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

नीना प्रोग्रामर अपने सहयोगियों को कैसे देखते हैं

Habré पर सॉफ्टवेयर विकास के तरीके, संचार और परियोजना टीम में बातचीत, प्रोग्रामरों के चयन और काम पर रखने के लिए समर्पित लेखों की एक उचित मात्रा है। अतिशयोक्ति के बिना, इस तरह के प्रत्येक लेख में प्रोग्रामर से बहुत सारे गुस्से वाली टिप्पणियां एकत्र की जाती हैं, जिसमें वे "पिएमास", परीक्षक, कार्मिक विभाग के कर्मचारी, विश्लेषकों, ग्राहकों - को दोषी ठहराते हैं, जो किसी के लिए भी खुद को किसी विशेष विज्ञान में कमियों के लिए या परियोजनाओं में विफलताओं के लिए प्यार नहीं करते हैं। लेखों में और उनसे टिप्पणियों में, प्रचलित राय यह है कि डेवलपर हमेशा सही होता है। इस राय की व्यापकता अन्य बातों के अलावा, इस तथ्य के कारण है कि प्रोग्रामर अधिकांश दर्शकों को हबर में बनाते हैं। इसी समय, विशेषज्ञ जो प्रोग्रामर नहीं हैं वे संगठनों और परियोजना टीमों में काम कर रहे हैं। यह लेख निजी तौर पर "बैरिकेड्स" के दूसरी तरफ गठित एक पक्ष या किसी अन्य के दृष्टिकोण को स्पष्ट रूप से व्यक्त करता है।

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


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

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

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

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

हालाँकि, पहले चीजें पहले।

एक साधारण प्रोग्रामर का जीवन पथ

किसी तरह, एक सफल प्रोजेक्ट के बाद, मैंने, विकास विभाग के प्रमुख की सहमति से, प्रोग्रामिंग ग्रुप के लिए एक प्रेजेंटेशन तैयार किया, जिसमें अन्य बातों के अलावा, स्कूली उम्र में नोटपैड में कोडिंग, प्रोग्रामर के जीवन पथ को दर्शाने वाला एक "ग्राफ" शामिल था। सतत एकीकरण और स्वचालित विकास के अभ्यास को लागू करने से पहले एकीकृत विकास वातावरण (20 वर्ष), दोष प्रबंधन (25 वर्ष) और विशेषज्ञों और बाहरी ठेकेदारों (30 वर्ष) के अन्य समूहों के साथ बातचीत के माध्यम से। yvaniya विज्ञप्ति भूरे बालों 35 साल की उपस्थिति प्राप्त (उम्र मील के पत्थर, बेशक, सशर्त की है, और केवल जीवन के मार्ग औसतन वर्णन करने के लिए की सेवा)। एक प्रोग्रामर, जैसे आधुनिक दुनिया में कोई और नहीं, तकनीकी रूप से और पेशेवर रूप से लगातार सीखने और सुधार करने के लिए मजबूर किया जाता है, और बहुत सारे इसमें बहुत सफल होते हैं। उसी समय, जो लोग अपना पहला सीटी-धोखाधड़ी कार्यक्रम "हैलो, वर्ल्ड" लिखते हैं और hh.ru / मॉन्स्टर डॉट कॉम पर फिर से शुरू करते हैं, तुरंत साक्षात्कार में अपनी उंगलियों को फैलाना शुरू करते हैं और गर्व से खुद को "एक सच्चे पेशेवर" कहते हैं, - ये वास्तव में नहीं हैं।

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

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

गैर-प्रोग्रामर के साथ सहभागिता

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

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

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

प्रौद्योगिकी का इंजीनियरिंग ज्ञान

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


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

टूल कौशल

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

जैसा कि आप जानते हैं, आधुनिक विकास के वातावरण में संकलन शुरू करना F5 (या F6? या F13?) को दबाकर संभव है? अंत में, मुझे, परियोजना प्रबंधक को, ऐसी बातों को जानने की आवश्यकता क्यों है? आप नहीं जानते, MUD, कितनी जल्दी, कुछ मिनटों में। जीरा से अनलोड करें, इसे एक्सेल में ठीक से प्रारूपित करें और ग्राहक को ब्लैकजेट और व्हाट्सएप चार्ट और रुझानों के साथ दोष रिपोर्ट के बारे में एक ई-मेल भेजें, लेकिन आप अपने सहयोगियों के बीच धूम्रपान कक्ष में अपने "पीम" को पिन करने में कभी असफल नहीं होंगे, यह बेवकूफी नहीं है जानता है कि विध्वंसक कैसे निर्माणकर्ता से भिन्न होता है)। लेकिन काफी लंबे करियर के लिए, मैं इतने सारे प्रोग्रामर से नहीं मिला हूं जो कुछ मानक क्रियाओं को लागू करने के लिए कीबोर्ड पर कीबोर्ड शॉर्टकट का उपयोग करते हैं - अधिकांश इसके लिए धीमे माउस मैनिपुलेटर का उपयोग करते हैं। सशर्त "टैब - 1000 - टैब - 1 - टैब - 0 - टैब - बैकस्पेस - 2 - Ctrl + S - Ctrl-F6 - दर्ज करें, Alt- टैब, F5" 6 सेकंड में एक वास्तविक समर्थक को माउस फ़्लिकिंग और पॉकिंग द्वारा क्या करने की अनुमति देता है कीबोर्ड पर तर्जनी के साथ, एक धीमी गति से पांच लंबे मिनट होता है। और जब इस तरह के ऑपरेशन दिन में सैकड़ों बार किए जाते हैं, तो एक समय सीमा समाप्त होने के संदर्भ में, एक अन्य परियोजना प्रबंधक कभी-कभी कीबोर्ड से दूर एक "पेशेवर" को ले जाना चाहता है और परिवर्तन / संकलित / निष्पादन योग्य कोड तैयार करता है और परीक्षण समूह को आगे बढ़ाता है। नया बिल्ड आखिरकार तैयार है।


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

श्रम मूल्यांकन

जब प्रोजेक्ट मैनेजर "लेखन कोड" की पवित्र प्रक्रिया में हस्तक्षेप करता है, तो आप इसे खड़ा नहीं कर सकते। लेकिन एक ही समय में, आप "अवास्तविक" समय सीमा, "टपकी" आवश्यकताओं, परिवर्तन के लिए असंगत अनुरोध, अक्षम परियोजना प्रबंधकों के बारे में कास्टिक टिप्पणी देने की खुशी से खुद को कभी भी इनकार नहीं करेंगे। जब, किसी विशेष कार्यप्रणाली के ढांचे के भीतर, वे अगले पुनरावृत्ति या पूरे प्रोजेक्ट के लिए श्रम लागत का आकलन करने के लिए विशेषज्ञ राय के लिए आपकी ओर रुख करते हैं, तो आप एक आश्चर्यचकित चेहरा बनाते हैं और समझ से बाहर या अतुलनीय विनिर्देशों, अज्ञात प्रौद्योगिकियों के बारे में "बहाने बनाने" लगते हैं, और यह आपकी बिल्कुल भी बात नहीं है। योजना बनाने के लिए, आपके पास "बकवास" के लिए समय नहीं है और आप बेहतर तरीके से जा सकते हैं और असली काम कर सकते हैं - कोड लिखना। “कार्यात्मक बिंदुओं की विधि द्वारा श्रम लागत का अनुमान? पिछले परिणामों के आधार पर सादृश्य द्वारा? स्क्रीन फॉर्म और डेटाबेस I / O अनुरोधों की संख्या के आधार पर? नहीं, मैंने सुना नहीं है! "

इसलिए, एक युवा दोस्त, या तो एक चीर में चुप रहता है, जब यह परियोजना में काम की योजना बनाने के लिए आपका व्यवसाय नहीं है, या वास्तव में विशेषज्ञ आकलन जारी करने में अपने कौशल को बेहतर बनाता है, और आकाश में आपकी उंगली से नहीं। और जब तक आप अंतिम मास्टर न करें - IPKB !!!

हिंदू कोड

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

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

अंतहीन प्रौद्योगिकी चर्चा

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

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

"अनावश्यक" रैलियों के बारे में Whining

इसलिए, जब आपने अपना समय बस बात करने में बिताया था, तो मैंने नवीनतम Google-Microsoft-Apple-Linus Torvalds फ्रेमवर्क / प्रेस कॉन्फ्रेंस के बारे में एक ही शिट कोडर्स के आधा दर्जन रसोई / धूम्रपान कक्ष में 2 घंटे तक बात की, जैसे कि कुछ लोगों को चुराया था- विकास के दिनों में, आप अचानक पूरा किए गए पुनरावृत्ति के विश्लेषण पर आप घोषणा करते हैं कि परियोजना में बहुत सारी अनावश्यक बैठकें आयोजित की जाती हैं और आपको उन्हें छोटा करने की आवश्यकता है - इसके जवाब में आप केवल एक चीज चिल्लाना चाहते हैं: शट अप और आईपीकेबी !!!

रूसी साहित्य

खैर, अंत में, जैसा कि वे कहते हैं, आखिरी, लेकिन सबसे महत्वहीन से दूर। , , , C## — - ( - , XXI ). , , , - — , ..! , _ — , . tsya.ru , «» — , " " «» — , « », ..!!111

उपसंहार

, , , , , . ! , , , - , .

---

: ? , , , .

, , , . , - 10 . 3 , , , , , “” 3 .

: 1 3 3 1. , . , “ ” ( “”). , , , , , .

“ ” , , , “”, , . , , , , “, , , , , XYZ , , ( / / )!”.

, “”, “ ”, , : , , , , ( ), “”.

.