समय उड़ जाता है, है ना?

मेरा कैरियर 2012 में शुरू हुआ, सी ++ में पहली इंटर्नशिप के साथ। ईमानदारी से, मुझे नहीं पता था कि मैं क्या कर रहा था (वास्तव में, कुछ भी नहीं बदला है)। हालाँकि, मैंने कुछ सबक सीखे हैं।

अस्वीकरण: इस संदेश में कोई कोड नहीं होगा।

प्रश्न: प्रोग्रामिंग में सबसे महत्वपूर्ण भाषा क्या है?

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

कारों से बात करने की तुलना में लोगों से बात करना अधिक महत्वपूर्ण है।

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

संचार कौशल एक परियोजना को बचा सकता है या दफन कर सकता है। चिंता न करें, समस्या केवल आपकी नहीं है, यहां तक ​​कि नासा भी इसकी वजह से पीड़ित है ।

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

आपको यह समझने की जरूरत है कि आप क्या और क्यों विकसित कर रहे हैं

लक्ष्य मिलने पर ज्यादातर लोग खुश हो जाते हैं। यह काम करने के लिए भी लागू होता है।

एक डेवलपर के रूप में आपका लक्ष्य JIRA का जावास्क्रिप्ट, Trello से C #, आदि में अनुवाद करना नहीं है। आपका लक्ष्य समस्याओं को हल करना है ।

यदि आपके पास उस प्रणाली की गहरी समझ है जिसे आप बना रहे हैं / बनाए रख रहे हैं, तो आप शुद्ध प्रौद्योगिकी के बाहर निर्णय ले सकते हैं। प्रश्न पूछें: क्या यह सुविधा भी आवश्यक है? यह किस समस्या का हल है? क्या हम इस समस्या को अलग तरीके से हल कर सकते हैं? हम इस समस्या को पहली जगह में हल करना चाहते हैं ?

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

यदि कोई कोड समीक्षा तनावपूर्ण है, तो यह बहुत खराब है, बहुत गलत तरीके से आयोजित किया गया है।

हे भगवान! कोड सत्यापन।

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

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

ठीक है, लेकिन मुझे क्या करना चाहिए जब यह फ़ंक्शन पूरी तरह से टूट गया है?

उठो। इस व्यक्ति से संपर्क करें, व्यक्ति में बात करें। उससे बात करें, पता करें कि उसने इस तरह से कोड क्यों लागू किया।

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

कुछ गलत होगा, तैयार हो जाओ

विकिपीडिया के अनुसार:

मर्फी का नियम एक कहावत या महाकाव्य है जो आमतौर पर पढ़ता है: "जो कुछ भी गलत हो सकता है वह गलत होगा।"

यह उन चीजों में से एक है जो बहुत अधिक सच है। सिस्टम को डिजाइन करते समय, हमेशा किसी प्रकार की विफलता को मानें।

यदि आप एक लॉगिन फ़ॉर्म बना रहे हैं, तो मान लें कि लोग पूरी पुस्तक के पाठ को पासवर्ड फ़ील्ड में कॉपी और पेस्ट करेंगे।

यदि आप एक WYSIWYG विंडो बनाते हैं, तो मान लीजिए कि कोई इसे तोड़ने की कोशिश करता है, और ऐसा करने में सक्षम होने की संभावना है।

यदि आपके पास एक डेटाबेस है, तो यह किसी बिंदु पर काट दिया जाएगा। यदि आपने बैकअप से डेटाबेस को पुनर्स्थापित करने का परीक्षण नहीं किया है, तो यह बैकअप नहीं है।

यदि आप दर्शकों के सामने प्रदर्शन की तैयारी कर रहे हैं, तो सुनिश्चित करें कि डेमो ऑनलाइन, ऑफ़लाइन, उल्टा और पानी के नीचे काम करता है।

"मुझे नहीं पता" कहने से डरो मत

बिल्ला पर "वरिष्ठ" शीर्षक का सबसे सुखद विशेषाधिकार, आखिरकार , जवाब देने का अवसर है:

मुझे नहीं पता, मैंने कभी इसकी कोशिश नहीं की। मैं देखूंगा और आपको वापस बुलाऊंगा।

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

या मैं सिर्फ एक अविश्वसनीय स्कैमर हूं जो हर किसी को धोखा देने में कामयाब रहा कि मैं वास्तव में अपना काम कर सकता हूं। आपको कभी पता नहीं चलता।

जनता में जानें

जैसे ही आप "I don’t know" से स्विच करते हैं, "वैसे, यह दिलचस्प था" - इसे किसी के साथ साझा करें। एक ब्लॉग लिखें, एक वीडियो रिकॉर्ड करें, एक ज्ञान-साझा करने की घटना पर बात करें, या बस ... किसी को बताएं। अगर आपको लगता है कि हर किसी के लिए कुछ स्पष्ट है, तो ऐसा नहीं है। यहां तक ​​कि सबसे अच्छे पेशेवरों में शुरुआती से सीखने के लिए कुछ है, और इसके विपरीत।

शिक्षण यह सुनिश्चित करने के लिए एक अविश्वसनीय रूप से प्रभावी तरीका है कि आप वास्तव में प्रश्न में विषय को समझते हैं।

जैसा कि किसी ने बहुत चालाकी से कहा:

जब कोई सिखाता है, तो दो सीखते हैं।

एक डेवलपर के रूप में आपने क्या सबक सीखा?