एक कला के रूप में प्रोग्रामिंग

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



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



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



एक प्रोग्रामर लगभग हमेशा रचनात्मक विकास की स्थिति में होता है। हर समय वह सीखना चाहता है, नई तकनीकें सीखता है, नवीनतम उपकरणों पर लिखना चाहता है, एक नई भाषा या सिस्टम के संस्करण में एप्लिकेशन को फिर से लिखना, अपने कंप्यूटर को अपडेट करना, विकास का वातावरण, पैच स्थापित करना, बायोस के नए संस्करण को अपग्रेड करना ... जोड़ा गया कार्यक्रम तुरंत पुराना माना जाता है।



इसके अलावा, प्रोग्रामर खुद को ईमानदारी से विश्वास के साथ कहता है कि वह इस ज्ञान को एक नई परियोजना या नई नौकरी पर लागू करने के लिए अध्ययन कर रहा है। लेकिन प्रोग्रामर अपनी नौकरी बदल देता है या बस एक नई परियोजना के लिए आता है, और ... फिर से वह खुद को कार्यान्वयन के लिए अगली नई तकनीक चुनता है। क्यों? क्योंकि वह इसका अध्ययन करना चाहता है और पहले से ही इस पर एक परियोजना बनाने की कोशिश कर रहा है। वह ऐसा करने की कोशिश कर रहा है, क्योंकि उसके लिए परिणाम ज्यादा मायने नहीं रखता। परिणाम का सीखने से कोई लेना-देना नहीं है, है ना? खुद के लिए, वह प्राप्त परिणाम से नहीं, बल्कि एक रचनात्मक कृति से, प्रलेखन की एक अध्ययन की गई परत या बनाए गए कोड द्वारा एक आंतरिक मूल्यांकन देता है। परिणाम - यह एक यादृच्छिक उपहार की तरह है - हो सकता है या नहीं हो सकता है (1/2 संभावना)। लेकिन परिणाम आमतौर पर प्रोग्रामर को पूरा करने के लिए उत्साहित नहीं करता है, पेशेवर विकास या विकास का भ्रम अधिक दिलचस्प है।



बेशक, सभी प्रोग्रामर ऐसे नहीं हैं, लेकिन यूनिवर्सिटी छोड़ने वालों में से 99% ऐसे ही हैं। और मैं वैसा ही था, जब मैंने विश्वविद्यालय से स्नातक किया था।



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



पहले बैंक में, जिसे मैंने अपनी उपस्थिति से खुश किया, बैंकिंग सॉफ्टवेयर को फॉक्सप्रो पर DBF फाइलों के साथ लिखा गया था। लेकिन यह मुझे अपमानजनक लग रहा था, अर्थात् अपमानजनक, फॉक्सप्रो पर लिखने और किसी और के कार्यक्रम को जोड़ने के लिए। मैंने सोचा कि यह कायरों के लिए था - जैसे, एक वास्तविक पेशेवर प्रोग्रामर ऐसा नहीं लिखता है।



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



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



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



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



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



हाँ, हमारे प्रोग्रामरों को प्रशिक्षण देने की प्रणाली में एक प्रणालीगत दोष है: प्रोग्रामर को कभी भी यह नहीं सिखाया जाता है कि वे कंपनी के कार्यों को महसूस करने के लिए कंपनी में आएं। हमारे पास कंपनी के क्षमताओं को ध्यान में रखते हुए विभिन्न उपकरणों का उपयोग करके संगठन के कार्यों के लिए इष्टतम समाधान पर प्रोग्रामर के प्रशिक्षण कार्यक्रम में प्रशिक्षण नहीं है। वैसे, मैंने Microsoft प्रमाणन कार्यक्रमों में से एक में ऐसे पाठ्यक्रम और प्रश्न देखे (निश्चित रूप से, उनके समाधानों को ध्यान में रखते हुए)। लेकिन ऐसा कुछ सिखाने के लिए इसके लायक है।



और फिर भी, कला या शिल्प?



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



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



और पेशे की परवाह किए बिना, सभी लोगों को उन लोगों में विभाजित किया जाता है जो जानते हैं कि परियोजनाओं को कैसे करना है, और जो वास्तव में परियोजनाएं करते हैं।



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



और बेहतर करने के लिए उसी विषय पर अगला लेख लिखने के कई कारण हैं

"प्रोग्रामिंग" के रहस्य का पता लगाएं।