अनुवाद के बारे में
यह
पैशन प्रोग्रामर के अध्याय 20 का अनुवाद है
: सॉफ्टवेयर डेवलपमेंट में एक उल्लेखनीय कैरियर बनाना । इसका लेखक -
चाड फाउलर - एक प्रतिभाशाली रूबी डेवलपर है, जो सामान्य रूप से रूबी और आईटी पर सम्मेलनों में एक प्रसिद्ध वक्ता है। पूर्व सैक्सोफोनिस्ट, और अब सीटीओ 6Wunderkinder।
पुस्तक का क्राउडसोर्सिंग अनुवाद
जीथब पर किया जाता है,
सम्मिलित हों।
अध्याय 20. टेलीपथ
मैंने राव नाम के एक लड़के के साथ काम किया। राव भारत के दक्षिणी राज्य आंध्र प्रदेश से हैं, लेकिन वे अमरीका में रहते थे और हमारे साथ काम करते थे। राव कोई भी कोड लिख सकते थे, चाहे आपने जो भी पूछा हो। यदि आपको निम्न-स्तरीय सिस्टम प्रोग्रामिंग की आवश्यकता है - यह उसके लिए है, यदि कोई उच्च-स्तरीय लागू प्रोग्रामिंग है, तो वह लगभग कुछ भी कर सकता है।
हालाँकि, राव ने वास्तव में जो कमाल किया, वह यह था कि आपने उनसे पूछा था। उसके पास यह अनुमान लगाने की अलौकिक क्षमता थी कि आप इससे पहले कि आप इसके बारे में सोचने से पहले उससे क्या करने जा रहे हैं। यह जादू के समान था। मुझे लगता है कि मैंने भी उस पर एक बार धोखा देने का आरोप लगाया था, लेकिन धोखा देने की कोई संभावना नहीं थी। मैं कहूंगा: “राव, मैं अपने आवेदन ढांचे [1] पर नियंत्रक को एनकैप्सुलेट करने के तरीके को बदलने के बारे में सोच रहा था। यदि हम इसे थोड़ा बदलते हैं, तो इसका उपयोग न केवल वेब अनुप्रयोगों के लिए करना संभव होगा। आपको क्या लगता है? ” "मैंने पिछले हफ्ते ऐसा किया था," वह कहेंगे, "यह संस्करण नियंत्रण प्रणाली में है। देखो। ”राव के साथ
हमेशा ऐसा ही
होता था। इतना अक्सर कि यह सब एक संयोग होने का एकमात्र तरीका है जैसे कि राव वह
सब कुछ कर रहे थे
जिसकी कल्पना हर उस कोड के टुकड़े के साथ की
जा सकती थी जिस पर हमारी टीम काम कर रही थी।
उस समय, मैंने एप्लिकेशन आर्किटेक्चर टीम [2] का नेतृत्व किया। अन्य बातों के अलावा, हमने कंपनी अनुप्रयोगों में उपयोग के लिए फ्रेमवर्क विकसित और बनाए रखा। मेरे सहयोगियों ने यह चर्चा करने में बहुत समय बिताया कि हम कंपनी को बेहतर बनाने के लिए सॉफ्टवेयर विकास कैसे देखना चाहते हैं। हमने इन सुधारों में प्रमुख बुनियादी ढांचे के घटकों की भूमिका पर भी चर्चा की।
यहीं पर राव की चाल उपयोगी साबित हुई। वह इन वार्तालापों के दौरान बहुत कुछ नहीं बोलता था, लेकिन उसने उनसे संपर्क नहीं छोड़ा। उसने ध्यान से सुना। और, इस रहस्य का खुलासा करते हुए कि एक भी जादूगर नहीं करता है, उसने बाद में मुझे बताया कि उसने केवल वही किया जो मैंने पहले ही कहा था कि मैं यह करना चाहता हूं। यह सिर्फ इतना है कि मैंने इसके बारे में इतनी सूक्ष्मता से बात की कि
यहां तक कि मैंने कल्पना भी नहीं की कि मैंने यह कहा है। हम तब तक इंतजार कर सकते थे जब तक कि कॉफी को पीसा नहीं जाता, और मैं बता सकता था कि अगर हमारे कोड में अतिरिक्त लचीलापन होता तो कितना अच्छा होता। अगर मैंने इस बारे में अक्सर बात की या पर्याप्त रूप से पर्याप्त बात की, भले ही मैंने इसे टू-डू सूची में शामिल नहीं किया, राव इन चीजों में से एक को पेश करने की संभावना की तलाश में, "असली काम" में ब्रेक भर सकते थे। यदि यह आसान (और सस्ता) था, तो वह इसे कोड़ा और जाँच कर सकता था।
दूरदर्शिता न केवल आपके प्रबंधकों के लिए, बल्कि आपके ग्राहकों के लिए भी प्रासंगिक है। यदि वे आपको सही संकेत देते हैं, तो आप उस कार्यक्षमता को जोड़ सकते हैं जो वे या तो आपसे माँगने
जा रहे थे, या यदि वे कल्पना
कर सकते थे कि यह संभव है। यदि आप हमेशा वही करते हैं जो ग्राहक मांगते हैं, तो वे सिर्फ संतुष्ट होते हैं। हालाँकि, यदि आप उनसे पूछते हैं, या पहले से कुछ किया है, तो आप उन्हें मारेंगे - यह तब है जब आपकी टेलीपैथी की क्षमता सही है।
यह माइंड रीडिंग ट्रिक पूरी तरह से सुरक्षित नहीं है। यह एक फैली हुई रस्सी की तरह है जिसे आप सुरक्षा जाल के बिना चलने से बचते हैं। मुख्य जोखिम (अपेक्षित शमन के साथ) इस प्रकार हैं:
- आप कंपनी का पैसा काम करने में खर्च करते हैं, जो आपसे किसी ने नहीं पूछा। अगर आप गलत हैं तो क्या होगा? छोटे से शुरू करो। अपने वर्तमान कार्य में केवल पोज़ भरने के बारे में धारणाएँ बनाएं, ताकि परिवर्तनों का प्रभाव कम से कम हो। आप चाहें तो इसे अपने खाली समय में कर सकते हैं।
- हर बार जब आप सिस्टम में कोड जोड़ते हैं, तो एक बहुत बड़ी संभावना है कि कोड परिवर्तनों के लिए कम लचीला हो जाएगा। मान्यताओं से बचें अगर यह घटता या सीमित हो सकता है जो सिस्टम प्रदर्शन कर सकता है [3]। जब परिवर्तन का प्रभाव काफी बड़ा होता है, तो व्यावसायिक निर्णयों की आवश्यकता होती है। और इस मामले में, शायद ही कभी डेवलपर्स निर्णय को प्रभावित करते हैं।
- आप सिस्टम की कार्यक्षमता को अपने ग्राहकों द्वारा अनुरोध के अनुसार बदल सकते हैं, ताकि समाधान अप्रत्याशित रूप से ग्राहक के लिए कम उपयोगी या वांछनीय हो जाए। अनुमान लगाने से सावधान रहें, खासकर जब यह उपयोगकर्ता इंटरफेस की बात करता है।
लोगों और परियोजनाओं का प्रबंधन करना कठिन काम है। जो लोग परियोजना को सही दिशा में ले जा सकते हैं, बिना दिशा के, वे अक्सर अपने अति व्यस्त प्रबंधकों और ग्राहकों द्वारा सराहना करते हैं। दिमाग पढ़ने वाली बात, अगर सही किया जाता है, तो लोग आप पर भरोसा करते हैं - कैरियर के विकास के लिए एक महान नुस्खा। यह कौशल सीखने और विकसित होने के लायक है।
अधिनियम!- इस पुस्तक के एक शुरुआती समीक्षक कार्ल ब्रॉफ़ी सुझाव देते हैं कि अपने अगले प्रोजेक्ट या सिस्टम के लिए, जो आप सोचते हैं कि प्रबंधक या ग्राहक पूछना चाहते हैं, उनके बारे में नोट्स बनाना शुरू करें। रचनात्मक बनो। सिस्टम को उनके दृष्टिकोण से देखने की कोशिश करें। नहीं-तो-स्पष्ट कार्यों की एक सूची संकलित करने के बाद, सोचें कि हर एक को सबसे प्रभावी ढंग से कैसे लागू किया जाए।
- जब आप सिस्टम को बेहतर बनाने के लिए किसी प्रोजेक्ट या कार्य में शामिल होते हैं, तो प्रगति का पालन करें। अपने अनुमानों में से कितने वास्तव में विकसित करने के लिए कहा? जब आपके कार्यों को पेश किया गया था, तो क्या आपके पास विचार-मंथन के लिए इन विचारों का उपयोग करने का अवसर था? [४]
[१] मैं कहूंगा, "राव, मैं अपने एप्लीकेशन फ्रेमवर्क पर कंट्रोलर को इनकैप्सुलेट करने के तरीके को बदलने के बारे में सोच रहा हूँ"
[२] उस समय, मैं अपनी कंपनी एप्लीकेशन आर्किटेक्चर टीम का नेतृत्व कर रहा था।
[३] मन-पढ़ने के काम से बचें जो सिस्टम को किसी विशेष वास्तु पथ के लिए मजबूर कर सकता है या सिस्टम को किसी भी तरह से सीमित कर सकता है।
[४] जब आपकी अनुमानित विशेषताएं सामने आईं, तो क्या आप उन विचारों का उपयोग करने में सक्षम थे जो आप अपने मंथन सत्रों में ले आए थे?
फीचर का सबसे अच्छा अनुवाद क्या है?
और क्या किसी ने ऐसे राव को देखा है?