उन नए software developers के लिए सलाह जिन्होंने बाकी सभी advice essays पढ़ डाले हैं
(buttondown.email)- करियर की शुरुआत में मशहूर developer advice को ज्यों का त्यों मानने के बजाय पहले यह देखना चाहिए कि वह आपकी स्थिति पर लागू होती है या नहीं, क्योंकि software क्षेत्र के कई दावों के पीछे ठोस निर्णायक प्रमाण नहीं होते
- जो ideas पसंद आएँ उन्हें खुद आज़माया जा सकता है, लेकिन सहकर्मियों के काम में बाधा न डालते हुए trial and error से गुजरना सीखने की प्रक्रिया का हिस्सा है
Debugging: The 9 Rulesएक आसान शुरुआती किताब के रूप में सुझाई जाती है, क्योंकि यह debugging skills पर बात करती है, जिन्हें beginner books अक्सर छोड़ देती हैं- “सही तरीका” या “best practices” अक्सर किसी खास failure case और ऐतिहासिक path से निकले होते हैं, इसलिए technique और उसके प्रचार के तरीके में फर्क करना चाहिए
- tools की छिपी हुई सुविधाएँ, दूसरे departments का काम, और programming के अलग-अलग प्रकार शुरुआती दौर में देखने से अपने लिए सही software work ढूँढना आसान होता है
सलाह को अपनाने का रवैया
- जो developer advice बहुत पढ़ी जाती है, वह सिर्फ इसलिए नहीं फैलती कि लेखक बेहतरीन programmer है, बल्कि कई बार इसलिए भी कि वह अच्छा लिखता है
- हर सलाह को अपने-आप खारिज करने की ज़रूरत नहीं, लेकिन उसे अपनी स्थिति में कैसे लागू करना है, यह सावधानी से सोचना चाहिए
- software के बारे में “objective truth” जैसे दावों को सतर्कता से लेना चाहिए; इस विषय पर वैज्ञानिक अध्ययन बहुत कम हैं, और जो हैं उनके नतीजे भी अक्सर साफ़ नहीं होते
- यह सोचकर ज़्यादा परेशान होने की ज़रूरत नहीं कि कहीं आप “गलत चीज़” न सीख लें
- अगर किसी का idea अच्छा लगे, तो उसे खुद आज़माया जा सकता है
- जब तक आप सक्रिय रूप से अपने सहकर्मियों के काम में बाधा नहीं डाल रहे, बाद में पीछे मुड़कर देखने पर भले लगे कि कुछ और करना चाहिए था, फिर भी वह आखिरकार सीखने में बदल सकता है
- Debugging: The 9 Rules नए developers के लिए सुझाई गई किताब है
- यह पढ़ने में आसान है, और debugging जैसे अहम कौशल पर बात करती है, जिसे दूसरी “beginner programmer” किताबें लगभग छूती ही नहीं
- इसे library से उधार लिया जा सकता है या company से खरीदने का अनुरोध किया जा सकता है
“सही तरीका” और best practices की सीमाएँ
- किसी समय आपको लग सकता है कि programming का एक “Right Way” मिल गया है, और अगर सब उसी को मानें तो पूरा क्षेत्र बेहतर हो जाएगा
- उदाहरण के तौर पर test-driven development, functional programming, Lisp, और formal methods का उल्लेख किया गया है
- ऐसे तरीकों के प्रति आकर्षित होने से बचना कठिन है, और यह अच्छा महसूस भी करा सकता है, लेकिन अपनी पहचान को “Right Way Guy” बना लेना ठीक नहीं
- समय के साथ समझ आता है कि कोई भी तरीका programming को पूरी तरह साफ़-सुथरा नहीं बना देता; यह काम फिर भी उलझा हुआ और थकाने वाला हो सकता है, और उस तरीके के बिना भी शानदार software बनाया जा सकता है
- जब कई “Right Way” पता चल जाते हैं, तो उन्हें समस्या के हिसाब से मिलाकर इस्तेमाल किया जा सकता है
- जो पहला “Right Way” आप देखते हैं, वह अक्सर किसी ऐसे व्यक्ति से आता है जो उसमें पूरी तरह डूबा हुआ होता है
- बाद में उस व्यक्ति को ज़रूरत से ज़्यादा दोष देने के बजाय, असल technique और उसके प्रचार के तरीके को अलग-अलग समझना बेहतर है
- कई ideas को उनकी शुद्ध original form में नहीं, बल्कि दूसरे ideas के साथ काम करने लायक बनाने के लिए कुछ हद तक बदलना पड़ता है
- Julia Evans के शब्दों में, “हर best practice के पीछे एक डरावनी कहानी होती है”
- अगर कोई best practice समझ में न आए, तो उस failure case को खोजा जा सकता है जिसने उसे जन्म दिया
- अगर वह failure case आपकी स्थिति से जुड़ा नहीं है, तो कोई दूसरा तरीका चुनना भी ठीक है
- बहुत-सी best practices और conventions path-dependent होती हैं
- हो सकता है आप किसी चीज़ का पालन सिर्फ इसलिए कर रहे हों कि आपके mentor ने किया, और उन्होंने इसलिए किया क्योंकि उनके mentor ने किया था
- अतीत की समस्याएँ सुलझाने के लिए बनी कोई पद्धति आज कम प्रासंगिक हो सकती है
- जो convention बाद में गढ़ी गई तर्कसंगत व्याख्या जैसी लगती है, वह सचमुच वैसी ही हो सकती है; चाहें तो उसके बनने की प्रक्रिया को पीछे जाकर देखा जा सकता है
व्यावहारिक समझ बढ़ाने के तरीके
- टहलना विचारों को व्यवस्थित करने में मदद करने वाली आदत के रूप में सुझाया गया है
- जिन tools का आप उपयोग करते हैं, उनमें अक्सर छिपी हुई गहराई होती है
- programming language, Git, या JIRA जैसे tools में हर चीज़ expert level तक सीखना ज़रूरी नहीं
- लेकिन 5–10 मिनट लगाकर यह देखना कि उनसे और क्या किया जा सकता है, ज़रूर उपयोगी है
- company के अंदर दूसरे departments के लोगों से बात करने पर काम की समझ बढ़ती है
- support, business domain, sales आदि से बात की जा सकती है
- अगर समय हो और कहना आसान लगे, तो उनके काम को थोड़ी देर follow करके देखना भी सुझाया गया है
- करियर की शुरुआत में जितना हो सके programming के अलग-अलग प्रकारों का अनुभव लेना अच्छा है
- इसके लिए ज़रूरी नहीं कि आप job change ही करें; ज़्यादातर companies में कई तरह की programming साथ-साथ होती है
- अगर company web development करती है, तो frontend, backend, operations, database जैसे काम आज़माए जा सकते हैं
- इससे सीखने में मदद मिलती है, लेकिन उससे भी ज़्यादा अहम यह है कि इससे यह पता चलने की संभावना बढ़ती है कि आपको सच में किस तरह का software work पसंद है
- एक निजी उदाहरण में बताया गया है कि पहली job frontend में होने पर कठिनाई हुई, लेकिन बाद में backend में जाने पर ज़्यादा संतोष मिला
- software क्षेत्र लगातार बदलता रहता है, इसलिए framework trends के पीछे भागने के बजाय fundamentals पर ध्यान देने की सलाह के पीछे वजह है
- internet, open source, conferences आदि की वजह से software दुनिया की जानकारी बहुत तेज़ी से फैलती है
- ideas साझा करने की बाधाएँ कम हैं, इसलिए किसी एक व्यक्ति के private project को भी ऐसा लग सकता है जैसे बहुत लोग उसे जानते हों
- जिन technologies की चर्चा सुनाई देती है, उनमें से कई का user base छोटा हो सकता है और वे व्यापक रूप से अपनाई न जाएँ
- अगर आपकी रुचि बहुत गहरी है, तो early adopter बनना ठीक है; नहीं तो कुछ साल इंतज़ार करके देखना भी ठीक है कि क्या सच में टिकता है
- कोई भी भविष्य की सही भविष्यवाणी नहीं कर सकता, और वर्तमान भी कई ऐसी चीज़ों का नतीजा है जिनका पहले अनुमान लगाना मुश्किल था
- इसलिए जितना अच्छा कर सकते हैं उतना करें, अपने मूल्यों के अनुसार जिएँ, और इस प्रक्रिया का आनंद लेना सीखें
1 टिप्पणियां
Hacker News की राय
हाल ही में एक hobby project में मैंने एक junior और एक उससे थोड़ा कम junior developer के साथ काम किया, और दोनों ही “सही तरीके” के जुनूनी थे
वे एक लगभग 300-line Discord bot + Rust codebase के लिए, जिसे सिर्फ हम ही चलाने वाले थे, पूरी documentation, QA और “operations” के लिए अलग VM, systemd deployment, कुछ strings के लिए template system, और सिर्फ चार SQL queries के लिए ORM layer तक मांग रहे थे
यह ज़्यादा से ज़्यादा 10 लोगों द्वारा इस्तेमाल होने वाला project था, और यह भी सिर्फ “0.3” release requirements का आधा हिस्सा था, जबकि आगे और भी over-engineering की योजना थी, इसलिए मैंने उस project से हाथ खींच लिया
programming के शुरुआती दौर में मैं भी कुछ साल ऐसा ही था, लेकिन बाद में सीखा कि best practices या code style से परे भी computer science में बहुत गहराई है, और आखिरकार मायने रखता है काम करने वाला code
मतलब, असली समस्या की तुलना में मामूली details पर अनुपातहीन ध्यान देना; इसके लिए एक मशहूर उदाहरण है कि परमाणु संयंत्र अनुमोदन समिति असली reactor को छोड़कर बगल के cycle shed के रंग पर बहस करती रहती है
इस मामले में भी 10 users वाले project में QA/operations VM अलग करना, systemd deployment, कुछ strings के लिए templates, और कुछ SQL queries के लिए ORM पर फोकस करना Law of triviality का क्लासिक उदाहरण लगता है
ऐसे हिस्सों में junior developers के लिए समझना और बहस करना आसान होता है, इसलिए वे वहीं ज़्यादा शामिल हो जाते हैं, जबकि मुश्किल core functionality आसानी से नज़रअंदाज़ हो जाती है
हालांकि, project के meaningful हिस्सों को ठीक से document करना तुच्छ चीज़ों पर अटकना नहीं है
systemd unit लिखना या ORM इस्तेमाल करना उतना समय नहीं लेता जितना लगता है, लेकिन बाद में जब कोई project देखे या कोई और contribute करना चाहे, तब यह काफी मददगार हो सकता है
जब तक context दिमाग में ताज़ा हो, तब तक यह काम कर लेना आसान होता है, और project बड़ा होने के बाद ऐसे छोटे काम अक्सर कभी पूरे नहीं होते
हो सकता है कि hobby project होने की वजह से वे इसे ठीक से करके tools सीखना और संतोष पाना चाहते हों
शुरुआत में $50 का router खरीदने वाला एक scene है, जहाँ एक किरदार कहता है कि मौजूदा router को repair करके देख लें, और बाकी लोग उसका वाक्य पूरा होने से पहले ही लगभग जवाब देते हैं, “कर चुके हैं”
इससे दिखता है कि वे एक-दूसरे को इतना अच्छी तरह जानते हैं और इतना समय साथ बिताते हैं कि लगभग एक-दूसरे के दिमाग पढ़ लेते हैं
लेकिन जब कोई नया router खरीदने के लिए “yes” कहता है, तो दूसरा जवाब देता है, “aye चाहिए”
यानी side business के decision vote में इस्तेमाल होने वाले शब्दों का नियम बहुत सख्त है, और यह मायने नहीं रखता कि वे एक-दूसरे के कितने करीब हैं, router सिर्फ $50 का है, या side income कोई बड़ी बात नहीं
नियम aye की मांग करता है
“सही तरीके” के कुछ जुनूनी लोग ऐसे लगते हैं जैसे उन्होंने social hive mind में जमा knowledge की नकल करके सफलता पाई हो, लेकिन उनके अपने दिमाग में सच में क्या चल रहा है, इसकी समझ कम हो
verified methodologies को खुद कठिनाई से खोजने के बजाय विरासत में पा लेने का फायदा है, लेकिन नुकसान यह है कि वे उन परिस्थितियों को शाब्दिक रूप से नहीं समझते जिनमें वही तरीका विफल हो सकता है
director commentary में कहा गया है कि यह scene जानबूझकर इसलिए रखा गया था ताकि दिखे कि कुछ किरदार नियमों को बहुत ज़्यादा गंभीरता से लेते हैं, और कुछ उतनी गंभीरता से नहीं
ऐसी cargo-cult practices दूसरों को सुझाने की वजह भी शायद यही होती है: जितने ज़्यादा लोग उसका पालन करेंगे, जब वह practice विनाशकारी तरीके से फेल होगी, तब फेल होने वाला शायद वह खुद नहीं होगा
आजकल मैं ऐसे लोगों को बहुत बार देखता हूँ, और इन्हें smart junior कहता हूँ। करियर 1 साल का हो या 20 साल का, इससे फर्क नहीं पड़ता
smart junior को ज़्यादातर design patterns पता होते हैं और उसने Mythical Man-Month भी पढ़ रखी होती है, लेकिन वह नई technology, language, या framework आज़माना चाहता है, इसलिए चमकदार नए हथौड़े के साथ हर चीज़ में कील ढूंढता फिरता है
फिर वह इस बात को समझे बिना अजीब फैसले लेता है कि एक पुराना, अच्छी तरह optimized database कितनी ताकत दे सकता है
20 साल के अनुभव में मैंने बहुत बार देखा है कि 5–10 साल बाद ऐसे projects का क्या हाल होता है, जब original team का आधे से ज़्यादा हिस्सा जा चुका होता है, और तब मैं सचमुच मूल्यवान चीज़ें बचाकर बेकार के आधे हिस्से काट देता हूँ
हम किसी भी तरह मज़ा ढूंढने की कोशिश करने वाले developers का kindergarten नहीं चला रहे; हम ऐसे business के लिए काम करते हैं जो पैसा देता है और stable, reasonably fast results की उम्मीद करता है
cutting-edge tech लाना या boredom से बचने के लिए नई चीज़ें आज़माना, लंबे समय में सुधार से ज़्यादा नुकसान करता रहा है
आपको वही technology लानी चाहिए जिसे पूरी team समझ सके और उसमें दक्ष हो सके, न कि वह जिसे सिर्फ एक bored superstar जानता हो
अगर आपको अपने resume में ढेर सारी technologies जोड़नी हैं, तो ऐसी कंपनियों में जाइए; वैसी जगहें भी अपनी तरह ठीक हैं
बस, ऐसे लोग वैसे भी अक्सर ज़्यादा समय नहीं टिकते, इसलिए उनके कुल added value पर भी संदेह रहता है। किसी को यह boring लग सकता है, लेकिन मैं इसे अनुभवी तरीका कहता हूँ
अगर side project का मकसद कंपनियों को मेरा GitHub दिखाना है, तो यह approach और भी उचित लग सकती है
documentation बहुत महत्वपूर्ण है। मेरे पास bot और web scraper समेत कुछ काफ़ी simple projects हैं, 300 lines से भी कम, लेकिन documentation न होने की वजह से अब मैं उन्हें चला नहीं सकता
जिस Raspberry Pi पर वे चलते थे वह खराब हो गया, और अब समझ नहीं आता कि headless virtual framebuffer को कैसे ठीक करूँ, या ऐसे अजीब errors को कैसे debug करूँ जिनके लिए search करने पर कोई काम की result नहीं मिलती
अगर मैंने उन्हें containerize किया होता, या कम से कम setup process document की होती, तो यह समस्या नहीं आती
यह अच्छी पोस्ट है और काश इसे और लोग पढ़ें
software, खासकर data management के क्षेत्र में 15 साल काम करते हुए मैंने ठीक यही सीखा है
Theravada Buddhism की पृष्ठभूमि से सीखा गया Kesamutti Sutta भी बहुत मददगार रहा
इसका मतलब है कि किसी बात को सिर्फ इसलिए न मानो कि उसे बार-बार सुना है, वह परंपरा है, अफ़वाह है, ग्रंथ में है, अनुमान या स्वयंसिद्ध या ऊपर-ऊपर से ठीक लगने वाली तर्कशृंखला है, लंबे समय से मन में बसी धारणा के प्रति पक्षपात है, कोई व्यक्ति सक्षम दिखता है, या वह शिक्षक की बात है
यह सलाह कि उसे तभी अपनाओ जब तुम स्वयं जान लो कि “यह अच्छा है, निंदा के योग्य नहीं है, बुद्धिमान लोग इसकी प्रशंसा करते हैं, और इसे अमल में लाने से लाभ और सुख मिलता है”, मेरे लिए मिडिल स्कूल से नास्तिक बनने के बाद भी जीवन में बहुत उपयोगी रही
कुछ लोग कहते हैं कि किसी ने इसे और rationalist अर्थ देने के लिए अनुवाद को तोड़-मरोड़ दिया
अगर यह सच है तो दुख की बात है। क्योंकि मैं मानना चाहता था कि Buddha इतने “enlightened” थे
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
“तुम ठगे गए” या “तुमने गलत चीज़ सीखी” इस बात की बहुत चिंता न करने वाली बात से मैं सहमत हूँ
जब TDD का चलन था तब सीखा? हाँ। क्या अब TDD इस्तेमाल करता हूँ? नहीं। फिर भी क्या TDD ने बेहतर code लिखना सिखाया? हाँ
यही बात उन भाषाओं पर भी लागू होती है जिन्हें मैं अब पेशेवर रूप से इस्तेमाल नहीं करता। हर चीज़ कुछ न कुछ सिखाती है
दोनों तरफ थोड़ा-थोड़ा आगे बढ़े बिना अच्छा मध्य बिंदु नहीं मिल सकता
अगर पहले से code है और आप उसे बढ़ाना चाहते हैं, तो उसके इस्तेमाल के आसपास कुछ tests लिखना बिल्कुल उचित है
अगर अभी code नहीं है, लेकिन दिमाग में structure है और आप पहले बनाने और बाद में test करने लायक हिस्से अलग कर सकते हैं, तब भी इसका मतलब बनता है
शुद्ध अर्थ में यह TDD नहीं है, बल्कि test-assisted development के ज़्यादा करीब है, लेकिन यह TDD की भावना का उपयोग ही है
बुरी चीज़ें सीखना भी यह समझने का बड़ा हिस्सा है कि कौन-सा approach बेहतर है या बदतर
इसका मतलब यह नहीं कि TDD खुद बुरा है, लेकिन उस पर हद से ज़्यादा अटक जाओ तो वह बुरा हो सकता है
आख़िरकार यह “गलतियाँ सीखने का रास्ता हैं” वाली आम समझ से भी जुड़ता है
ऐसे दिशानिर्देश और सिद्धांत आम तौर पर जानने लायक होते हैं, लेकिन समस्या तब होती है जब लोग उन्हें धर्म की तरह मानने लगते हैं
हमारे industry में विचारधारावादी लोग सच में बड़ी परेशानी हैं
छोटी है, सटीक है, और तुरंत असर करती है
यह अच्छी पोस्ट और अच्छी सलाह है
आख़िरकार honeymoon phase खत्म होने पर आप सीखते हैं कि चाहे कोई भी “सही तरीका” अपनाओ, programming निराशाजनक और बेतरतीब होती है, और उस तरीके का पालन किए बिना भी शानदार software बनाया जा सकता है
समय के साथ आप दर्जनों और “सही तरीके” सीखते हैं, और उन्हें समस्या के हिसाब से मिलाकर इस्तेमाल करते हैं
लेकिन पिछले कुछ सालों में ऐसा लगता है कि बहुत-से developers सही तरीके के जुनून में फँस गए हैं और अपने ज्ञान व नज़रिए को व्यापक नहीं बना पा रहे
अगर यह सच है तो दुखद है, और कारण क्या है यह ठीक से नहीं पता
हो सकता है आजकल कम हुई attention span की वजह से ज्ञान को कुशलता से फैलाना मुश्किल हो गया हो, और यह भी कि लोग अपनी मौजूदा जगह पर ज़्यादा सहज हो गए हों
या फिर शायद इसलिए कि सिर्फ किसी खास framework को सीखने का इनाम बहुत बड़ा है, और यह समझने की बुनियादी जानकारी सीखने की प्रेरणा कम है कि चीज़ें अंदर से कैसे काम करती हैं
इसलिए उनके पास मौजूदा काम से सबक लेने का समय नहीं होता, और जब तक वह सबक असर करे तब तक वे शायद वहाँ से जा चुके होते हैं
साथ ही उनके पास नई trending technologies पर ध्यान न देने की गुंजाइश भी नहीं होती
यह रुझान विकास में बहुत बड़ी बाधा बनता है
मेरी तरफ़ से एक छोटी-सी सलाह यह है। state दुश्मन है। जहाँ भी संभव हो, state कम करनी चाहिए
इसमें सिर्फ code के भीतर की state नहीं, बल्कि वे सारी चीज़ें भी शामिल हैं जिन्हें काम करने के लिए short-term memory में पकड़े रखना पड़ता है, यहाँ तक कि project-विशिष्ट details भी जिन्हें याद रखना पड़ता है
state दुश्मन है। अगर किसी चीज़ को first principles से निकाला जा सकता है, तो हमेशा वैसा करने की कोशिश करनी चाहिए
इनमें से कुछ बातें सिर्फ programmers के लिए सलाह होने से आगे जाती हैं
पहला बिंदु हर किसी के सोचने लायक है। बहुत-से लेखक और essayist इसलिए पढ़े जाते हैं क्योंकि वे उस विषय के विशेषज्ञ नहीं, बल्कि अच्छा लिखते हैं
टहलना भी चाहिए
अलग-अलग तरह के काम आज़माने चाहिए, और कंपनी के भीतर दूसरे roles के बारे में भी सीखना चाहिए
खासकर बड़ी कंपनियों में, हो सकता है जो काम मैं कर रहा हूँ उसे कहीं और फिर से ठीक या bypass करना पड़ता हो, और अगर मैं उसे बदल दूँ तो सबके लिए चीज़ें आसान हो जाएँ
पहला बिंदु यह भी बताता है कि YouTube जैसी video-sharing services से सीखी गई बातों पर शक क्यों करना चाहिए
अगर कोई आत्मविश्वास से बोले और ideas को प्रोफेशनल ढंग से पेश करे, तो लोग उन ideas को गंभीरता से लेते हैं, चाहे उनमें खामी ही क्यों न हो
ऐसे संसार में जहाँ यह सामने आ चुका है कि कुछ “essayist” असल में Wikipedia लेख और Reddit posts पढ़कर सुनाने भर का काम कर रहे थे, अभिव्यक्ति की विश्वसनीयता और सटीकता को अलग-अलग देखने की आदत ज़रूरी है
मैं बिंदु 10 को भी और आगे बढ़ाना चाहूँगा। संबंधित लोगों से बात करने पर software या development work जिस समस्या को हल करना चाहता है, वह ज़्यादा साफ़ दिखती है, और ऐसे pain points भी दिखते हैं जो खुद से नज़र नहीं आते
बहुत ही कम अपवादों को छोड़कर, software software के लिए नहीं, बल्कि समस्याएँ हल करने के लिए लिखा जाता है
वह internet या training process के किसी हिस्से से “सही” जवाब पढ़ सकता है, और यह सोचे बिना कि वह वास्तव में सच है या नहीं, उसे भरोसेमंद अंदाज़ में दोहरा सकता है
पोस्ट में सुझाई गई debugging book मुझे इतनी पसंद आई कि मैंने उसकी कई copies खरीदकर बाँटीं
मैंने इसे दोस्तों, interns, data scientists, यहाँ तक कि executives को भी दिया, और जिसने भी पढ़ा उसने धन्यवाद कहा
इसमें बड़े technical systems की समस्याएँ सुलझाने के लिए कुछ अच्छी, सरल techniques हैं, इसलिए यह लगभग हर किसी के काम आ सकती है
इसे पढ़ना आसान है, दिलचस्प है, और इसमें बहुत-सी “war stories” भी हैं जो वरना सूखी लगने वाली सलाह में रंग और संदर्भ जोड़ देती हैं
https://debuggingrules.com/
“लोग मेरी बात इसलिए सुनते हैं कि मैं अच्छा programmer नहीं बल्कि अच्छा writer हूँ” — इसका मतलब सिर्फ़ यह नहीं है कि अच्छे writers की बात पढ़ते समय सावधान रहना चाहिए, बल्कि यह भी है कि हमें अपने काम को कैसे approach करना चाहिए
अगर आप अच्छा लिखते हैं, तो आम तौर पर लोगों के साथ काम करने की आपकी क्षमता भी बेहतर होती है
software developers के लिए writing और communication core काम हैं
अगर आप beginner हैं, तो जिन मुश्किलों का सामना किया, जो experiments किए, और आपकी thought process क्या थी, उन्हें लिखने की सलाह है
हो सके तो essays भी लिखिए। career के बाद के चरणों में यह सचमुच बहुत काम आने वाली skill बनती है
beginners को ठीक से समझाना मुश्किल एक बात है: “आपका काम code लिखना नहीं है”
हम problems solve करने के लिए code को एक tool की तरह इस्तेमाल करते हैं
code, goal हासिल करने का means है; वह खुद goal नहीं है
अगर आप code के लिए ही coding करते हैं, तो नतीजे गलत निकलते हैं
problem solving पर focus करना चाहिए, और अगर यह साफ़ नहीं है कि आपका code कौन-सी problem solve कर रहा है, तो coding रोककर पहले यह समझना चाहिए
कंपनी के हिसाब से यह email भी हो सकता है
सवालों का जवाब देना, collaboration करना, और team व organization की direction को influence करना काम जैसा लगता है, लेकिन communication भी code की तरह कुछ उपयोगी बनाने का tool है; वह अपने आप में उपयोगी चीज़ नहीं है
ज़्यादातर code, यहाँ तक कि “code के लिए code” भी, किसी न किसी problem को solve करता है
कई programmers भी कम से कम अवचेतन रूप से यह जानते हैं, इसलिए वे ऐसा code लिखते हैं
असली problem यह है कि दूसरे लोग — जैसे suit पहनने वाले business side के लोग — चाहते हैं कि वह code कोई दूसरी problem solve करे
बस, वह code सही code होना चाहिए
और सामान्य रूप से इसे ऐसे समझाया जा सकता है: “software systems को लागू करके business problems solve करना”
अगर junior से यह कहा जाए, तो वह business requirements पर focus करेगा और MBA, managers, या PM की बातों का आलोचनात्मक मूल्यांकन करके सही काम कर सकेगा
लेकिन VC को बेचने लायक software होना भी अपने आप में value रखता है
इसलिए कभी-कभी सचमुच आपको code लिखने के लिए ही पैसे दिए जाते हैं