2020 में एक आईटी विशेषज्ञ को क्या नहीं करना चाहिए?

हैबर में भविष्यवाणियों और सलाहों की भरमार है कि अगले साल क्या करना है — कौन सी भाषाएँ सीखनी हैं, किन क्षेत्रों में जाना है, अपने स्वास्थ्य के साथ क्या करना है। प्रेरणादायक लगता है! लेकिन हर सिक्के के दो पहलू होते हैं, और हम न केवल किसी नई चीज़ में, बल्कि ज़्यादातर रोज़ाना जो करते हैं उसमें भी ठोकर खाते हैं। “किसी ने मुझे चेतावनी क्यों नहीं दी!” हम चिढ़कर कहते हैं, आमतौर पर खुद को संबोधित करते हुए। हम खुद पर आग लगाते हैं — हमने आपके लिए 2020 में (और शायद हमेशा) क्या नहीं करना है, इसकी एक सूची तैयार की है। 

लेकिन गुरुत्वाकर्षण के बारे में तो पूछा ही नहीं गया

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

अगर सब कुछ ठीक है तो आईटी में जाने की कोई जरूरत नहीं है

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

स्टैक को स्टैक में बदलना समय की बर्बादी है

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

अपनी जमीन पर खड़े होने और कांस्य बनने की कोई आवश्यकता नहीं है

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

आपका अपना दिमाग अच्छा है, हमेशा अच्छा

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

उपयोगकर्ता डरावने लोग हैं

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

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

गूगल करना बंद करो!

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

विश्वास करो, लेकिन सत्यापित

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

बैकअप बनाएं!

बैकअप न बनाना या उन्हें उसी थर्ड-पार्टी सर्वर पर रखना बंद करें जहाँ आपका प्रोजेक्ट होस्ट किया गया है। क्या आपको लगता है कि यह मज़ेदार और व्यर्थ सलाह है? लेकिन टेलीग्राम चैट में 700 से अधिक प्रतिभागी जो हाल ही में एक प्रसिद्ध डेटा सेंटर के बंद होने के साथ एक अप्रिय स्थिति में आ गए, उन्होंने ऐसा नहीं सोचा - वहाँ सब कुछ था: पालतू परियोजनाओं से लेकर बड़ी सरकारी वेबसाइट और कॉर्पोरेट 1C और बिलिंग डेटाबेस तक। एक महत्वपूर्ण हिस्सा - बिना बैकअप के या बैकअप के साथ। इसलिए जोखिम वितरित करें और बैकअप को कम से कम मुख्य होस्टिंग पर, कुछ विश्वसनीय VDS पर और अपने स्थानीय सर्वर पर रखें। अंत में, यह बहुत सस्ता होगा। 

परियोजना को नुकसान पहुंचाने के लिए अपना सामान लाना बंद करें

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

कोई कोड नहीं, बल्कि तंत्रिकाओं का एक बंडल

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

मूर्ख इसे सहज ही रखो

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

सुरक्षा लें

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

कुएँ में न थूकें

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

ऐसा करना भी उचित नहीं है। लेकिन, जैसा कि अनुभव से पता चलता है, हम रुकेंगे नहीं

सामान्य तौर पर, दोस्तों, सलाह पढ़ें, लेकिन वही करें जो आपको सबसे अच्छा लगे - आखिरकार, असली खोज तब होती है जब हम पहले से खोजे गए सत्य पर संदेह करते हैं। नया साल मुबारक हो, आपकी परियोजनाएँ सफल हों, आपका करियर दिलचस्प हो, आपके सहकर्मी और प्रबंधक पर्याप्त हों, और आपका जीवन सामान्य रूप से सफल हो। सामान्य तौर पर, यहाँ नए साल और नए कोड के लिए है! 

प्यार से,
रीजनसॉफ्ट डेवलपर स्टूडियो टीम

नए साल में, हम आपके लिए काम करना जारी रखेंगे और एक शक्तिशाली डेस्कटॉप CRM सिस्टम विकसित करेंगे रीजन सॉफ्ट सीआरएम और एक सरल और सुविधाजनक हेल्पडेस्क और टिकट प्रणाली जेडलाइन सपोर्ट.

स्रोत: www.habr.com