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

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


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

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

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

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

स्टैक को स्टैक में बदलें - केवल खोने का समय

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

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

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

आपका सिर अच्छा है, हमेशा अच्छा है

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

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

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



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

गुगली बंद करो!

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

भरोसा करें लेकिन सत्यापन करें

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

बैकअप बनाओ!

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

परियोजना की रुकावट के लिए खुद को लाने बंद करो

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

कोड नहीं, बल्कि नसों का एक बंडल

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

इसे सरल, मूर्ख बनाए रखें

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

बाहर देखो

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

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

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


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

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

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

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