प्रोग्रामर मुश्किल समस्याओं के बारे में अलग-अलग बातें कहते हैं। संभवतः मेरा पसंदीदा विकल्प : "कंप्यूटर विज्ञान में दो कठिन समस्याएं हैं: कैश अमान्य होना, नामकरण और त्रुटि प्रति यूनिट।"

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

और यह बहुत मुश्किल है।

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

Technolepet

शब्दजाल बहुत महत्वपूर्ण है। यदि मेरा सहयोगी और मैं एक विशिष्ट समस्या को हल करने के लिए एक एल्गोरिथम चुनते हैं, तो हम कह सकते हैं कि "पहला विकल्प O(n^2)न्यूनतम ओवरहेड के साथ शुरू से, और दूसरा इसके लिए मूल्यह्रास है O(n log n), लेकिन महंगी स्थापना और कॉन्फ़िगरेशन के साथ । "

यह एक वाक्य बहुत कुछ कहता है, जिसके लिए एल्गोरिदम का उपयोग किया जाना चाहिए और हुड के तहत उन्हें कैसे लागू किया जाना चाहिए:

विकल्प ए एक प्रणाली के लिए महान है जिसमें थोड़ी मात्रा में इनपुट होता है।
विकल्प बी वास्तव में बड़ी मात्रा में इनपुट डेटा के साथ काम करने के लिए महान है, जहां सिस्टम को स्थापित करने और कॉन्फ़िगर करने की उच्च लागत प्रक्रिया में बेहतर प्रदर्शन से ऑफसेट होगी।
यदि आप लूप में एल्गोरिथ्म का उपयोग करने का इरादा रखते हैं, तो आपको महंगे इंस्टॉलेशन और कॉन्फ़िगरेशन कोड से बचने के लिए पहला विकल्प चुनना चाहिए।
शायद हम कैशिंग का उपयोग करके विकल्प बी स्थापित करने की लागत को कम कर सकते हैं।
संभवतः, विकल्प ए में, इनपुट डेटा के प्रत्येक तत्व की तुलना अन्य सभी (उदाहरण के लिए for x in inputs { for y in inputs { if some_condition(x, y) { ... }}}) के साथ की जाती है।
शायद, विकल्प बी पहले एक पेड़ बनाता है, फिर एक रैखिक खोज करता है, इसके बाद इस पेड़ में खोज करता है।

जैसा कि आप देख सकते हैं, हम एक वाक्य में जानकारी के कई पैराग्राफ को व्यक्त करने में सक्षम थे, बस सही शब्दों का उपयोग करके।

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

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

इसे मैं टेक्नोलॉथ कहता हूं, जो एक प्रोग्रामर की गड़गड़ाहट है।

स्पष्ट रूप से, आमतौर पर इन विवरणों और शर्तों की अन्य क्षेत्रों के लोगों को जरूरत नहीं होती है, और वे वास्तव में परवाह नहीं करते हैं।

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

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

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

आपको जो मतलब है उसका चित्रण दिखाने के लिए यह चोट नहीं करता है ...

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

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

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

आदर करना

इसलिए हम धीरे-धीरे अगले बिंदु पर आगे बढ़ते हैं ... सम्मान के बारे में मत भूलना।

बहुत से लोग जिनके साथ मैं काम करता हूं वे वास्तव में स्मार्ट हैं और अपने क्षेत्रों में विशेषज्ञ हैं, लेकिन जरूरी नहीं कि उनके पास सूचना प्रणाली बनाने में पर्याप्त ज्ञान और अनुभव हो।

एक जटिल समस्या की व्याख्या करते समय, अवधारणाओं को सरल बनाना अक्सर बेहतर होता है। लेकिन कृपालु बनने की कोशिश मत करो।

जिस सॉफ्टवेयर इंजीनियर के बारे में मैंने अक्सर जवाब दिया, वह है: "यह ... जटिल" जब एक "सामान्य" व्यक्ति ने पूछा कि यह या यह कैसे काम करता है। ऐसा लगता है जैसे कोड इतना परिष्कृत है कि 20 वर्षों के प्रोग्रामिंग अनुभव के बिना आप इसे समझ नहीं सकते हैं।

ऐसा मत करना।

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

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

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

निजीकरण, अतिशयोक्ति और सादृश्य

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

कहें कि आपकी कंपनी में ऑनलाइन खरीद प्रणाली है। मार्केटर ऑनलाइन ऑर्डर से लेकर पार्सल की डिलीवरी तक पूरी श्रृंखला को समझना चाहता है ताकि ग्राहकों के सवालों का बेहतर जवाब दिया जा सके। मैं कुछ इस तरह कह सकता था:

, . www.example.com, «» ( -, ).

(-). , () . , , , (, ).

( ), , . , , ( — , ), .

( ) . , , .

यह सब लगता है थोड़ा अनोखा, और उदाहरण के लिए अब तक प्राप्त किए गए की तुलना में अधिक है, लेकिन मैं गारंटी ले सकते हैं कि इस शब्द "वेब सर्वर", "घटना वास्तुकला" और "Apache काफ्का" के साथ एक बड़े नेटवर्क आरेख की तुलना में अधिक समझ में आता विवरण है (पर अनुभाग देखें technolepte )

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

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

उदाहरणों के साथ उपयोगी उपमाएँ (यदि उपयुक्त हों)। आपने शायद पहले ही देखा है कि यह लेख उदाहरणों से भरा है। एक अमूर्त व्याख्या के बजाय, मैं विशिष्ट कहानियां बताता हूं जो थीसिस को समझाने में मदद करती हैं। यह दुर्घटना नहीं है।

सुंदर चित्र खींचे

यह सुनने में अटपटा लगता है, लेकिन कभी-कभी एक तस्वीर एक हजार शब्दों के लायक होती है।

कुछ महीने पहले मैं रेडियो पर एक पाठ्यक्रम पढ़ रहा था, और पास की लड़की को यह याद नहीं था कि इस छोटे 16 × 2 एलसीडी के मेनू पर कौन से बटन दबाए जाएं।

मैंने पूछा कि क्या वह एक चित्र बना सकता है।

उसने सोचा कि मैं एक स्मार्ट लड़का था और उसकी खिल्ली उड़ा रहा था।

लेकिन मैं मजाक नहीं कर रहा था।

इसके बजाय, मुझे कागज का एक टुकड़ा मिला, और साथ में हमने कुछ ऐसा बनाया:

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

लेकिन वह (और इस स्तर पर हर कोई) विज्ञान के बारे में बहुत कुछ नहीं देता। उन्हें एक नक्शा मिला जिसका उपयोग वे उपयोगकर्ता इंटरफ़ेस को नेविगेट करने के लिए कर सकते हैं।

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

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

मैंने $ फीचर्स को दस गुना तेज किया

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

एक ओर, आप पिछले सप्ताह क्या किया के सवाल पर, आप उस व्यक्ति सच्चाई बता सकते हैं: "मैं करने के लिए कैशिंग जोड़ा lookup_something ()सामान्य खोज में तेजी लाने और से एल्गोरिथ्म अनुवाद करने के लिए detect_collisions()ग O(n^2)करने के लिए O(n log n)" , लेकिन एक उच्च संभावना के साथ वे कुछ भी (देखें नहीं समझोगे technolept ) ।

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

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

ज्यादातर मामलों में, आपने वास्तव में कई कार्यों के प्रदर्शन में सुधार किया है, लेकिन अगर ये फ़ंक्शन प्रदर्शन में अड़चन नहीं थे, तो उच्च संभावना के साथ किसी को कोई अंतर नहीं दिखाई देगा।

ध्यान दें। यदि आप अमदहल के नियम से परिचित हैं, तो एक फ़ंक्शन के प्रदर्शन को बढ़ाना जो एक अड़चन नहीं है, एक कार्य के लिए अधिक सीपीयू कोर का उपयोग करने जैसा है जो अनिवार्य रूप से संगत है।

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

यह मुझे लगता है कि सटीकता और समझ के बीच एक मध्यम आधार खोजने की कोशिश करना बेहतर है। यदि आपने एक ऐसा परिवर्तन किया है जो कोड के टुकड़े के एल्गोरिथम की जटिलता में सुधार करता है (उदाहरण के लिए, एक फ़ंक्शन से detect_collisions()स्विच किया O(n^2)गया O(n log n)), तो आप कह सकते हैं:"फ़ंक्शन एक्स अब उचित समय में बड़ी मात्रा में इनपुट का पैमाना बना सकता है, लेकिन इससे पहले नहीं । "

यह कहना सामान्य है कि "मुझे नहीं पता" ...

... और इस तरह जारी रखें: "... लेकिन अगर आप मुझे पांच मिनट देते हैं, तो मैं आपको बता सकता हूं" ।

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

उदाहरण के लिए, यदि कोई प्रबंधक आपके पास आता है और पूछता है: “क्लाइंट ने फ़ंक्शन X के लिए पूछा, क्या यह संभव है? और इसमें कितना समय लगेगा? ”

दस में से नौ मामलों में, ईमानदार जवाब "मुझे नहीं पता", लेकिन यह वास्तव में प्रबंधक को समय तय करने में मदद नहीं करता है। वह आपसे मुखातिब हुआ क्योंकि आप संबंधित क्षेत्र के विशेषज्ञ हैं और उत्तर देने के लिए तैयार हैं।

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

यह सहयोगियों और वरिष्ठों के सम्मान को खोने का एक शानदार तरीका है।

दूसरी ओर, शब्द "निश्चित नहीं है, लेकिन 5-10 मिनट दें, और मेरे पास एक जवाब होगा" एक साथ कई चीजें दिखाता है:

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

(और आपको यह पता लगाने के लिए पर्याप्त समय मिलता है)।

यह एक पुराने दृष्टांत से मिलता जुलता है :

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

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

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

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

एक नया, विस्तृत खाता इस तरह दिखता है ...

हैमर: $ 5

पता है कि कार हथौड़ा से कहाँ टकराती है: $ 4995

कोई भी किसी भी सवाल को google कर सकता है। लेकिन केवल एक सॉफ्टवेयर इंजीनियर जानता है कि कौन से कीवर्ड का उपयोग करें और परिणामों की व्याख्या कैसे करें।

जाँच - परिणाम

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

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

कुछ इसे "कार्यालय की राजनीति" और अन्य लोगों की राय में हेरफेर मान सकते हैं। यहाँ मैं क्या जवाब दूंगा:

सही है। लेकिन क्या यह अधिकांश पारस्परिक संबंधों पर लागू नहीं होता है?

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

बात करना मुश्किल है। गैर-प्रोग्रामर के साथ संवाद करने पर निबंध