प्रोग्रामर के कार्य में शीर्ष 5 कष्टप्रद क्षण

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

1. और इस सेक्शन को (एक लाइन से टीके दिए जाने में) कितना समय लगेगा?

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

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

2. आपने इसे दो दिनों में बनाने का वादा किया था, लेकिन एक सप्ताह बीत चुका है! (अनुच्छेद 1 की अवधि के लिए मस्तिष्क को धोएं)

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

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

3. तुरंत देखो, यहां आपको एक घंटे में एक टैबलेट बनाना है! (किसी और का कोड लिंक किया गया है)

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

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

4. कोई रिफैक्टिंग नहीं, आज मुझे इसकी आवश्यकता है!

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

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

5. इसे त्वरित, कृपया, और extJS पर बेहतर बनाएं।

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

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

अंत में

टिप्पणियों में जोड़ें जो आपके प्रबंधकों के काम में आपको बदनाम करता है, और एक मैनुअल बनाने की कोशिश करें ताकि आरटीएफएम लिंक देने के लिए जहां हो।

प्रबंधक को: अपने प्रोग्रामरों के काम का सम्मान करें। याद रखें, प्रोग्रामर भी एक व्यक्ति है,% उपयोगकर्ता नाम%।

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