मुझे computer science से नफरत है!
मैं आपको उन पारंपरिक तर्कों से बचाऊंगा कि आपको “fundamentals” (बुनियादी बातों) का अध्ययन और अभ्यास क्यों करना चाहिए।
मुझे पता है, एक linked list को रिवर्स करने और एक सुरक्षित और गैस-कुशल smart contract लिखने के बीच का संबंध न के बराबर लगता है।
आपको शायद ही कभी production में log(n) समय में चलने वाले एल्गोरिदम को लागू करने की आवश्यकता पड़ी होगी।
और अगर पड़ी भी, तो आपने बस एक लाइब्रेरी को इम्पोर्ट कर लिया होगा। और आपने लगभग निश्चित रूप से कभी किसी कंपाइलर को डिबग नहीं किया होगा या ऑपरेटिंग सिस्टम में सिस्टम कॉल नहीं जोड़ा होगा। UDP पैकेट्स के लिए बफ़र लिखना? भगवान बचाए!
लेकिन आपको फिर भी इन विषयों का अध्ययन करना चाहिए।
चलिए मैं आपको एक कहानी सुनाता हूँ।
मार्शल आर्ट्स का बच्चा
जब मैं बच्चा था, मुझे याद है कि मार्शल आर्ट्स का अभ्यास करते समय मुझे “रोके जाने” (held back) का एहसास होता था।
कराटे में, हमें तब तक स्पैरिंग (spar) करने की अनुमति नहीं थी जब तक कि हम पंचिंग बैग पर दोषरहित तकनीक के साथ प्रहार न कर सकें (और सहज रूप से घूंसे रोकना न सीख लें)। जुजित्सु में, हमें तब तक ग्रैपल (grapple) करने की अनुमति नहीं थी जब तक कि हमने गिरने (breaking falls) और बुनियादी थ्रो (takedown techniques) में महारत हासिल नहीं कर ली थी।
आधे अभ्यास सत्र कार्डियोवैस्कुलर और फुटवर्क व्यायाम होते थे जिनका लोगों से लड़ने से कोई स्पष्ट संबंध नहीं था।
यह निराशाजनक था। मुझे याद है कि जब इंस्ट्रक्टर ने अंततः हमें अपने सहपाठियों के सिर पर वार करने की अनुमति दी, तो मुझे कितनी राहत महसूस हुई थी। मुझे नहीं लगता कि हिंसा ने इसे आकर्षक बनाया, बल्कि सबके सामने “शुरुआती” (beginners) समूह में अलग न किए जाने की बात थी। “शुरुआती” लेबल वाले अभ्यास सार्वजनिक रूप से करना स्वाभाविक रूप से अरुचिकर लगता है।
पीछे मुड़कर देखें, तो इस प्रतिबंध के पीछे की बुद्धिमत्ता स्पष्ट है: यदि आप सीधे अपने हाथ-पैर मारते हुए लड़ाई में उतर जाते हैं, तो आप उतनी कुशलता से नहीं सीख पाएंगे जितना सीधे fundamentals का अभ्यास करके सीखते।
शुरुआत से तकनीक विकसित करने की तुलना में, अगर स्पैरिंग मौजूदा आदतों का लाभ उठाती है, तो यह कहीं अधिक प्रभावी होती है। जब कोई अन्य सहपाठी आप पर वार कर रहा हो, तब उचित तकनीक के बारे में सोचने से कौशल (skill) धीमी गति से विकसित होता है।
वास्तविक स्पैरिंग केवल fundamentals का योग है: अच्छा फुटवर्क, अच्छी स्ट्राइकिंग, अच्छी ब्लॉकिंग, और सांस न फूलना।
बुनियादी बातों (basics) का अभ्यास करना केवल मार्शल आर्ट्स तक सीमित नहीं है। प्रतिस्पर्धी शतरंज (chess) खिलाड़ी और गो (go) खिलाड़ी अपना सारा समय खेल खेलने में नहीं बिताते हैं। इसके बजाय, वे विशिष्ट परिदृश्यों वाली समस्या-पुस्तिकाओं (problem books) से गुजरते हैं जिन्हें मिड-गेम, गैम्बिट्स, सैक्रिफाइस आदि जैसे आवर्ती पैटर्न सिखाने के लिए डिज़ाइन किया गया है — जिसे हम इस लेख में fundamentals कहते हैं।
मार्शल आर्ट्स और computer science की कला
सॉफ्टवेयर इंजीनियरिंग भी इससे बहुत अलग नहीं है।
उन तकनीकों में सीधे कूदने का एक बड़ा प्रलोभन होता है जो उस अंतिम एप्लिकेशन से एक कदम दूर हैं जिसे आप बनाने का प्रयास कर रहे हैं।
मशीन लर्निंग? TensorFlow सीखें! Blockchain? Solidity सीखें!
(शिक्षक जो भ्रामक रूप से इंजीनियरों को बेहतर वेतन का वादा करते हैं यदि वे इन तकनीकों को सीखते हैं, इस समस्या का एक बड़ा हिस्सा हैं)।
सीधे TensorFlow या Solidity में कूदने से आप एक प्रभावी मशीन लर्निंग या ब्लॉकचेन इंजीनियर नहीं बनेंगे। आप एक साथ बहुत सारे अंतर्निहित (underlying) कौशल से निपट रहे होंगे। आप उस नए मार्शल आर्ट्स छात्र की तरह होंगे जो अपने हाथ-पैर मारता है और 45 सेकंड के बाद ही हाँफने लगता है। आप शायद यहाँ-वहाँ कुछ प्रहार कर लें, लेकिन आप हमेशा एक सीमित अभ्यासकर्ता ही रहेंगे।
सबसे पहले fundamentals में महारत हासिल करें और उन्हें बार-बार दोहराएं।

Wax on, Wax off - Bits in, Bits out
Computer science में हर समस्या, चाहे वह किसी भी डोमेन की हो, बिट्स (bits) की एक स्ट्रिंग अंदर जाने, कोई ऑपरेशन होने, और बिट्स की एक स्ट्रिंग बाहर आने की प्रक्रिया है।
हर। एक। समस्या।
इन बिट्स की व्याख्या डोमेन-विशिष्ट (domain-specific) है, लेकिन वे सभी बिट अनुक्रम परिवर्तन (bit sequence transformations) हैं।
इन बिट स्ट्रिंग ट्रांसफॉर्मेशन्स के बारे में तर्क करने का एक विज्ञान है। इसे computer science कहा जाता है।
मैं स्पष्ट करता हूँ कि यह एब्स्ट्रैक्शन (abstraction) विकास (development) में हर चीज़ पर कैसे लागू होता है।
एक ब्लॉकचेन की स्थिति (state) को बिट्स की एक स्ट्रिंग (सभी के बैलेंस और स्मार्ट कॉन्ट्रैक्ट्स की स्थिति) के रूप में मॉडल किया जाता है। आप उस स्थिति को एक अन्य बिट स्ट्रिंग (एक लेनदेन/transaction) के साथ जोड़ते हैं, दोनों को एक ट्रांसफॉर्मेशन में डालते हैं, और एक नई बिट स्ट्रिंग प्राप्त करते हैं: ब्लॉकचेन की नई स्थिति।
मशीन लर्निंग भी यही बात है। डेटा + मॉडल (दोनों बिट स्ट्रिंग्स) का परिणाम एक नई बिट स्ट्रिंग (प्रशिक्षित मॉडल) होता है। उस क्षेत्र में, हम डेटा को “jpegs”, मॉडल को “network file”, और ट्रांसफॉर्मेशन को “training” के रूप में सेमांटिक रूप से व्याख्या करते हैं, लेकिन वे अभी भी सिर्फ बिट स्ट्रिंग्स और ट्रांसफॉर्मेशन्स हैं।
किसी वेबसाइट को रेंडर करना API से JSON को वेबपेज पर HTML में बदलना (transformation) है। बिट स्ट्रिंग अंदर, दूसरी बिट स्ट्रिंग बाहर। इनका एब्स्ट्रैक्शन का स्तर JSON और HTML से अधिक है, लेकिन आंतरिक रूप से (under the hood), वही बिट स्ट्रिंग ट्रांसफॉर्मेशन हो रहा है।
उन बिट स्ट्रिंग्स पर सेमांटिक अर्थ (semantic meaning) लागू करने के सार्थक तरीकों की संख्या अच्छी तरह से प्रलेखित (documented) है, और आप उनका कड़ाई से अध्ययन कर सकते हैं।
उन बिट स्ट्रिंग ट्रांसफॉर्मेशन्स के साथ क्या किया जा सकता है और क्या नहीं, इसके बारे में बुनियादी प्रमेय (theorems) हैं, भले ही डोमेन कोई भी हो:
- यदि किसी बिट स्ट्रिंग की व्याख्या कंप्यूटर निर्देशों के रूप में की जाती है, तो क्या इसका परिणाम अनंत लूप (infinite loop) होगा या नहीं? (अनिर्णायक/Undecidable, वह halting problem है)।
- यदि किसी बिट स्ट्रिंग की व्याख्या कंप्यूटर निर्देशों के रूप में की जाती है, तो क्या हम यह साबित कर सकते हैं कि यह किसी अन्य बिट स्ट्रिंग के समकक्ष (equivalence) है? हाँ, लेकिन यह आम तौर पर कठिन (intractable) है। लेकिन अगर हम इसे एक constraint solving के रूप में मॉडल करते हैं, तो हम कुछ मामलों को कुशलतापूर्वक हल कर सकते हैं।
- यदि किसी बिट स्ट्रिंग को जानकारी संप्रेषित (conveying information) करने के रूप में मॉडल किया गया है, तो क्या बिना किसी जानकारी के नुकसान के बिट स्ट्रिंग को छोटा किया जा सकता है? आपको कैसे पता चलेगा कि आप इसे और छोटा नहीं कर सकते? (यह बैंडविड्थ बचाने के लिए मायने रखता है!)
- यदि एक बिट स्ट्रिंग बहुत बड़ी है, तो हम संबंधित सबस्ट्रिंग्स (substrings) से अपनी पसंद की जानकारी के टुकड़ों को कुशलतापूर्वक प्राप्त (retrieving) करने के बारे में क्या दावे कर सकते हैं? (Database theory और distributed systems)
- एक बिट स्ट्रिंग और एक अन्य बिट स्ट्रिंग को देखते हुए, एक और बिट स्ट्रिंग आउटपुट करें जो उनकी समानता का वर्णन करती हो। (Search algorithms)
- या फिर क्या होगा यदि कोई बिट स्ट्रिंग किसी सिस्टम की स्थिति (state) का प्रतिनिधित्व करती है? क्या इसे अवांछनीय कॉन्फ़िगरेशन (undesirable configurations) में ले जाया जा सकता है? (Hacking और state machines)।
क्या आपको बात समझ आई?
बिट स्ट्रिंग मैनिपुलेशन के बारे में तर्क करना आपको computer science की किसी भी विशेषज्ञता (specialization) में अच्छा बनाता है। आप वास्तव में 1s और 0s को इधर-उधर नहीं घुमा रहे हैं; आप 1s और 0s की व्याख्या के ऊपर शक्तिशाली एब्स्ट्रैक्शन लागू कर रहे हैं। और ये एब्स्ट्रैक्शन इतिहास के कुछ सबसे प्रतिभाशाली विचारकों के दशकों के शोध के परिणाम हैं। आपको वास्तव में दिग्गजों के कंधों पर खड़े होने (stand on the shoulders of giants) का अवसर मिलता है।
एब्स्ट्रैक्शन की ये श्रेणियां “cryptography”, “information theory”, “compilers”, “networks”, “virtual machines” आदि नामक समूहों (clusters) में आती हैं। आप जानते हैं, वो विषय जिनका अध्ययन करना व्यर्थ लगता है क्योंकि उनके लिए एक स्थापित उपकरण मौजूद है।
चलिए अपने मार्शल आर्ट्स के उदाहरण पर वापस चलते हैं। आप कुछ ब्लैक बेल्ट्स को एक बहुत ही प्रभावशाली स्पैरिंग मैच का प्रदर्शन करते हुए देख सकते हैं, लेकिन अंदरूनी तौर पर, यह वास्तव में केवल फुटवर्क, स्ट्राइकिंग, ब्लॉक्स और सांस न फूलना है। वही घटना कोडिंग निन्जा (coding ninjas) के प्रभावशाली कारनामों को शक्ति प्रदान करती है। यह केवल बुनियादी बातों (basics) का धाराप्रवाह निष्पादन है।
Computer science में आप जो कुछ भी करते हैं वह बिट्स की एक स्ट्रिंग लेना है जो किसी चीज़ का प्रतिनिधित्व करती है और उसे किसी अन्य चीज़ में बदलना है जो किसी और चीज़ का प्रतिनिधित्व करती है। (या यदि आप एक हैकर हैं, तो ऐसे इनपुट की पहचान करना जिसके परिणामस्वरूप अवांछित आउटपुट उत्पन्न होते हैं)।
आप अपनी 10वीं NFT मिंटिंग वेबसाइट लिखकर नहीं, बल्कि बिट स्ट्रिंग्स को मॉडल और ट्रांसफॉर्म करने की अपनी सामान्य क्षमता में सुधार करके computer science में बेहतर बनते हैं।
बिट स्ट्रिंग ट्रांसफॉर्मेशन के लिए आपके पास जितने अधिक एब्स्ट्रैक्शन और प्रतिमान (paradigms) होंगे, आप computer science और डेवलपमेंट के किसी भी क्षेत्र में उतने ही अधिक सक्षम होंगे।
क्या Leetcode अनुचित है?
ऐसा लग सकता है कि मैं टेक कंपनियों का उनके 45-मिनट के व्हाइटबोर्ड इंटरव्यू लेने के लिए बचाव कर रहा हूँ। ऐसा करने का एक महत्व है, और मैं इसके सिद्धांत का बचाव कर रहा हूँ, विशिष्ट कार्यान्वयन (typical implementation) का नहीं।
हम छात्रों से मांग करते हैं कि वे RareSkills blockchain bootcamp में शामिल होने से पहले एक आसान से मध्यम स्तर (easy to medium) का डेटा स्ट्रक्चर्स और एल्गोरिदम टेस्ट पास करें। अंतर यह है कि उनके पास इसे करने के लिए पारंपरिक 45 मिनट से अधिक का समय होता है।
मैं सहर्ष स्वीकार करता हूँ कि किसी के लिए 45 मिनट में ड्राई-इरेज़ मार्कर के साथ डेटा स्ट्रक्चर के प्रश्नों को हल करना काफी क्रूर है। हालाँकि, जो व्यक्ति उन्हें बिल्कुल भी हल नहीं कर सकता है, वह एक सक्षम प्रोग्रामर नहीं है और उस पर लाखों डॉलर रखने वाले स्मार्ट कॉन्ट्रैक्ट बनाने के लिए भरोसा नहीं किया जाना चाहिए। आपको आश्चर्य होगा। टेस्ट देने वाले 30% आवेदक एक भी समस्या हल नहीं कर पाते हैं (और फ़िज़ बज़ - fizz buzz - का एक प्रकार प्रश्नों में से एक है)।
मैं इस बिंदु पर बाद में फिर आऊंगा, लेकिन यद्यपि डेटा स्ट्रक्चर्स और एल्गोरिदम computer science की नींव का एक महत्वपूर्ण पहलू हैं, शायद सबसे महत्वपूर्ण हिस्सा भी हैं, वे computer science का एकमात्र परिणामी (consequential) हिस्सा नहीं हैं।
लेकिन फ्रेमवर्क जॉब रिक्वायरमेंट्स का क्या?
एम्प्लॉयर्स (नियोक्ता) आमतौर पर सहज रूप से (intuitively) जानते हैं कि बुनियादी बातें (fundamentals) एप्लीकेशन से ज्यादा मायने रखती हैं, भले ही उनमें से अधिकांश इसे स्पष्ट रूप से व्यक्त न करें।
कोई यह इंगित करेगा, “लेकिन जेफरी, अधिकांश जॉब डिस्क्रिप्शन (job descriptions) कहते हैं कि उन्हें React के साथ दो साल का अनुभव, Solidity के साथ एक साल का अनुभव, Kubernetes के साथ प्रोडक्शन अनुभव, आदि चाहिए। स्पष्ट रूप से मुझे इसी के लिए ऑप्टिमाइज़ करना चाहिए!”
यदि आपने अभी तक गौर नहीं किया है, तो अधिकांश जॉब डिस्क्रिप्शन काफी खयाली पुलाव (pie-in-the-sky) होते हैं।
चलिए कुछ बुनियादी गणित (basic math) करते हैं। मान लीजिए कि 12 फ्रेमवर्क और भाषाएं (languages) हैं जो वास्तव में मायने रखती हैं। एक औसत डेवलपर अपने 5 साल के करियर में वास्तव में उनमें से 4 में महारत हासिल कर सकता है। इस बात की संभावना कि डेवलपर ने एम्प्लॉयर की पसंद के उन्हीं 12 में से 4 को सीखा है, 495 में से 1 है।
(यह 4/12 * 3/11 * 2/10 * 1/9 या C(12, 4) है)
सॉफ्टवेयर जॉब डिस्क्रिप्शन अक्सर एक ऐसे औसत व्यक्ति की तरह लगते हैं जो किसी ऐसी आइवी-लीग शिक्षित सुपरमॉडल को डेट करना चाहता है जो Forbes 30 under 30 में भी हो। शुभकामनाएँ। आपकी संभावनाएँ 0.2% हैं। सच कहूँ तो, बहुत से सॉफ्टवेयर इंजीनियरों की उम्मीदें भी अवास्तविक होती हैं। सॉफ्टवेयर इंजीनियरों का नौकरियों से मेल कराना (matching) उतना ही उलझा हुआ है जितना कि पारंपरिक डेटिंग (traditional dating)। खैर, मैं विषय से भटक रहा हूँ।
लोगों के जॉब रिक्वायरमेंट से मेल खाने की कम संभावना के बावजूद, लोग फिर भी मैच हो ही जाते हैं। एम्प्लॉयर ऐसे लोगों को काम पर क्यों रखते हैं जो जॉब डिस्क्रिप्शन से पूरी तरह मेल नहीं खाते? (या, उस मामले के लिए, लोग ऐसे पार्टनर्स को डेट क्यों करते हैं जो सभी मापदंडों पर खरे नहीं उतरते? माफ़ करें, मैं फिर से विषय से भटक रहा हूँ, लेकिन यह उदाहरणात्मक है)।
ऐसा इसलिए है क्योंकि वे देख सकते हैं कि डेवलपर के पास computer science में सामान्यीकृत (generalized) कौशल है और वह इसे कंपनी की ज़रूरतों के अनुसार ढाल सकता है। (डेटिंग पर वापस जाते हुए, लोग इसलिए पार्टनर बनते हैं क्योंकि वे देखते हैं कि दूसरे व्यक्ति में वे अंतर्निहित विशेषताएं हैं जो एक अच्छा साथी बनाती हैं, इसलिए नहीं कि उनमें ऐसे फीचर्स हैं जो एक अच्छे साथी होने से जुड़े हैं)।
मैं यह नहीं कह रहा हूँ कि कोई कंपनी किसी ऐसे व्यक्ति को सीनियर फ्रंटएंड रोल के लिए काम पर रखेगी जिसने कभी कोई फ्रंटएंड ऐप नहीं बनाया है। लेकिन मैं यह कह रहा हूँ कि हम जिसे व्यापक रूप से, “फ्रंटएंड, बैकएंड, smart contract, इंफ्रास्ट्रक्चर, आदि” के रूप में नामित करते हैं, उसके भीतर, स्मार्ट एम्प्लॉयर्स फ्रेमवर्क अनुभव की तुलना में सामान्य क्षमता की अधिक परवाह करते हैं।
अंग्रेजी भाषा में एक गैप (gap)
ऐसा नहीं है कि जॉब पोस्टिंग आपको गुमराह कर रही हैं; बात यह है कि सॉफ्टवेयर डेवलपमेंट पर हावी होने वाली अंग्रेजी भाषा और अमेरिकी संस्कृति में संक्षेप में व्यक्त करने की क्षमता में एक गैप (अंतर) है…
“एक डोमेन के भीतर सामान्यीकृत क्षमता जो सिर्फ स्मार्ट होने से अधिक विशिष्ट है लेकिन बहुत सारे तथ्यों को याद रखने से अधिक सामान्य है — कोई ऐसा व्यक्ति जिसे ‘यह समझ आता है (gets it)’ जहां ‘यह’ महत्वपूर्ण मेटा-स्किल्स का एक सेट है जो इस सप्ताह हल की जाने वाली समस्या और अगले महीने हल किए जाने की संभावना वाली समस्या के बीच के सामान्य संबंध पर लागू होता है… और जब वे समस्या को हल करते हैं, तो वे समाधान के साथ आने वाले डोमेन के भीतर के साइड-इफेक्ट्स (side-effects) को समझते हैं, और यह भी कि वे साइड-इफेक्ट्स अन्य डोमेन में कैसे लीक हो सकते हैं।”
वाह, यह बहुत अधिक शब्दों वाला था।
(यदि मैं अत्यधिक सुसंस्कृत (cultured) होता और इसका दिखावा (flex) करना चाहता, तो मैं {जापानी, फ्रेंच, भारतीय, या कोई अन्य गैर-अंग्रेजी}-समकक्ष शब्द कहता, लेकिन अफ़सोस, मैं अत्यधिक सुसंस्कृत नहीं हूँ, और यदि मैं होता भी, तो किसी अन्य भाषा में इस शब्द का होना मौजूदा समस्या का समाधान नहीं करता)।
हमारे पास एक और कठिनाई है: “foundations”, “first principles”, और “fundamentals” जैसे शब्द “शुरुआती सामग्री” (beginner material) का संकेत देते हैं। लीनियर अलजेब्रा (linear algebra) के संदर्भ में, हमारे पास ऐसा कोई शब्द या बोलचाल का शब्द नहीं है जो यह बताए बिना किसी नॉलेज स्पेस (knowledge space) के बेसिस वेक्टर्स (basis vectors) को संदर्भित करता हो कि इसका अध्ययन करने वाला व्यक्ति एक नौसिखिया (noob) है। (देखिए, मैंने आप पर अपने लीनियर अलजेब्रा ज्ञान का दिखावा करने का मौका नहीं छोड़ा)।
शब्दावली (terminology) के अंतर के बावजूद, मार्शल आर्ट्स प्रशिक्षक और तकनीकी हायरिंग मैनेजर सहज रूप से इस अवधारणा को समझते हैं। लेकिन क्योंकि उनके पास इसे व्यक्त करने के लिए उचित भाषा की कमी होती है, वे “एथलेटिक”, “अनुभवी”, या “फास्ट लर्नर” जैसे भ्रामक शब्दों का उपयोग करते हैं।
ठीक है, हमारे पास “एक्सपर्ट” (expert) और “मास्टरी” (mastery) जैसे शब्द हैं, लेकिन ये उन शिक्षकों द्वारा बहुत अधिक हल्के और अति-उपयोग (overused) किए गए हैं जो दावा करते हैं कि वे आपको आज के किसी भी हाइप्ड फ्रेमवर्क के साथ पार्लर ट्रिक्स सिखाकर आप पर “विशेषज्ञता” (expertise) प्रदान कर सकते हैं।
भले ही आप मांगे गए फ्रेमवर्क का पांच वर्षों से उपयोग कर रहे हों, यह आपकी मदद नहीं करेगा यदि आप केवल ऑनलाइन ट्यूटोरियल को आंख मूंदकर कॉपी करते हैं। आपकी कमी (deficiency) आमतौर पर इंटरव्यू के स्तर पर पकड़ी जाएगी। तो “अनुभव के वर्ष” (years of experience) के मुख्य कारक होने की बात यहीं खत्म हो जाती है, है ना? एम्प्लॉयर आपसे यह उम्मीद करते हैं कि आप समझें कि फ्रेमवर्क कैसे काम करते हैं, न कि केवल यह कि उनके API के साथ इंटरफेस कैसे किया जाए।
सभी फ्रेमवर्क अंततः fundamentals पर ही आकर टिकते हैं। वे आपके द्वारा API के माध्यम से प्रदान की गई एक बिट स्ट्रिंग लेते हैं और एक स्टेट चेंज (state change) या किसी क्वेरी (query) के परिणाम के रूप में एक अन्य बिट स्ट्रिंग वापस करते हैं। वे पहले सूचीबद्ध किए गए मूलभूत (foundational) डोमेन में उसी तरह के मौलिक डेटा ट्रांसफॉर्मेशन्स कर रहे हैं।
फ्रेमवर्क्स में महारत हासिल करना चाहते हैं? आप जानते हैं कि मेरा अगला वाक्य क्या है!
इसलिए fundamentals का अध्ययन करें, फ्रेमवर्क्स का नहीं। इस तरह आप ऐसे व्यक्ति बन जाते हैं जो किसी भी फ्रेमवर्क को जल्दी सीख सकता है — यहाँ तक कि खुद भी फ्रेमवर्क बना सकता है। और वास्तव में एम्प्लॉयर यही चाहते हैं, भले ही वर्तमान भाषा उन्हें इस इच्छा को संक्षेप में व्यक्त करने की अनुमति न दे।
एवरग्रीन (Evergreen) और हाई लेवरेज (High Leverage) ज्ञान
चूँकि “fundamentals” का अर्थ “शुरुआती” लगता है (अर्थात, आपको कोने में जाना चाहिए और उस बैग पर सौ बार मुक्का मारना चाहिए, इससे पहले कि आप उन लोगों के साथ अभ्यास कर सकें जिनके पास आपसे गहरे रंग की बेल्ट है), मैं कुछ computer science अवधारणाओं को “एवरग्रीन” (Evergreen) और “हाई लेवरेज” (High Leverage) के रूप में संदर्भित करने जा रहा हूँ: “एवरग्रीन” क्योंकि यह पुराना नहीं होता (doesn’t go out of date) और “हाई लेवरेज” क्योंकि यह संबंधित ज्ञान की प्राप्ति को तेज करता है।
एक और भाषा (language) सीखना, मान लीजिए Rust, निश्चित रूप से आपके लिए कुछ अच्छा करेगा।
लेकिन कंपाइलर कैसे काम करते हैं, यह सीखना आपको किसी भी भाषा को तेज़ी से सीखने में मदद करेगा।
CPU आर्किटेक्चर और मशीन कोड कैसे काम करते हैं, यह सीखना आपको किसी भी ब्लॉकचेन पर किसी भी स्मार्ट कॉन्ट्रैक्ट को ऑप्टिमाइज़ करने में मदद करेगा।
ध्यान दें कि यह उल्टे क्रम में काम नहीं करता है। कोई दूसरी भाषा सीखने से आपको कंपाइलर्स के बारे में ज़्यादा कुछ नहीं पता चलता। लेकिन कंपाइलर्स सीखने से आपको प्रोग्रामिंग भाषा सीखने में मदद मिलेगी। इसीलिए इसे पारंपरिक रूप से “मूलभूत” (foundational) कहा जाता है, हालाँकि मैं इसे इस संदर्भ में “हाई लेवरेज” (high leverage) कहना पसंद करता हूँ।
डेटा स्ट्रक्चर्स और एल्गोरिदम कैसे काम करते हैं, यह सीखना आपको बड़े कोड बेस (code bases) को समझने में मदद करेगा क्योंकि आप आर्किटेक्चर को वेरिएबल-दर-वेरिएबल (variable by variable) के बजाय समझदार हिस्सों (sensible chunks) में पढ़ सकते हैं। इसके अलावा, कई तरीकों से बिट स्ट्रिंग्स को मॉडल करने और ट्रांसफॉर्म करने के अभ्यास से गुजरने के बाद, जब आप “वास्तविक दुनिया” में कोड करते हैं तो अच्छे समाधान आपके पास तेज़ी से आएंगे। अंत में, आप यह भी समझेंगे कि फ्रेमवर्क डेटा को उस तरह से मॉडल क्यों करते हैं जैसा वे करते हैं, और यह आपको नए फ्रेमवर्क तेज़ी से सीखने और प्रतिस्पर्धा में आगे रहने में मदद करेगा।
“लेकिन जेफरी! मुझे यह सब सीखने में एक साल लग जाएगा, और तब तक मैं ब्लॉकचेन के साथ बहुत आउट ऑफ डेट (out of date) हो जाऊंगा!”
यहीं पर “एवरग्रीन” (Evergreen) वाला हिस्सा आता है!
और क्या? भले ही आप आज की वर्तमान सामग्री का अध्ययन कर लें, फिर भी आप ब्लॉकचेन में एक साल बाद आउट ऑफ डेट हो जाएंगे। आप हमेशा आउट ऑफ डेट ही रहेंगे। कुंजी (key) यह है कि आप खुद को तेज़ी से सीखने के लिए सुसज्जित करके समाप्त हो रही जानकारी (expiring information) को अपने प्रतिस्पर्धियों (competitors) से बेहतर तरीके से नेविगेट करें।
ब्रह्मांड के वे नियम जो सूचना एन्कोडिंग (information encoding) और ट्रांसफॉर्मेशन को नियंत्रित करते हैं, कभी आउट ऑफ डेट नहीं होते हैं।
डेप्थ-फर्स्ट सर्च (Depth-first search) एक सदी से भी पुराना है और आज भी प्रासंगिक है। रैडिक्स सॉर्ट - Radix sort (कई अनुप्रयोगों में क्विकसॉर्ट - quicksort से भी तेज़) भी एक सदी पुराना है। ट्यूरिंग मशीन (Turing machine), जो कम्प्यूटेशन के सभी सिद्धांतों का आधार है, की कल्पना 80 साल पहले की गई थी। क्रिम्टोग्राफी (cryptography) जिन मान्यताओं (assumptions) पर निर्भर करती है, वे भी नहीं बदली हैं। यह इस बात पर निर्भर करता है कि क्या एन्क्रिप्टेड टेक्स्ट (फिर से, एक बिट स्ट्रिंग) औपचारिक परिभाषाओं (formal definitions) के अनुसार “रैंडम दिखाई देता है”।
Computer science केवल बिट अनुक्रमों (bit sequences) का मैनिपुलेशन (हेरफेर) है। यह हमेशा से ऐसा ही रहा है। इसे नियंत्रित करने वाले नियम एवरग्रीन (evergreen) हैं।

अप टू डेट (up to date) रहने के पीछे का रहस्य
अप टू डेट रहने का अर्थ है यह तेज़ी से समझना (grokking) कि किसी नवीनतम चतुर व्यक्ति ने मौजूदा ज्ञान को कैसे फिर से संयोजित (recombine) किया है।
प्रमुख नवाचार (Major innovations) आंतरिक रूप से (under the hood) बहुत ही वृद्धिशील (incremental) होते हैं। बात सिर्फ इतनी है कि प्रमुख नवाचारों ने अत्यधिक अनुपातहीन (disproportionate) परिणामों के साथ कुछ महत्वपूर्ण वेरिएबल्स (variables) को बढ़ाया:
Bitcoin ने केवल डिजिटल सिग्नेचर (digital signatures) को प्रूफ ऑफ वर्क (proof of work) के साथ मिलाया (बिटकॉइन के आविष्कार के समय ये दोनों दशकों पुरानी अवधारणाएं थीं)। Ethereum ने Bitcoin के निष्पादन कोर (execution core) को लिया और इसे ट्यूरिंग कंप्लीट (Turing complete) बना दिया। Chat GPT ने सेल्फ-अटेंशन ट्रांसफॉर्मर (self-attention transformer - जो उस समय तक 4 साल पुराना था) लिया और उसे बड़ा बना दिया, और कुछ हार्डकोडेड बिज़नेस रूल्स जोड़ दिए।
“इनोवेशन” (नवाचार) आम तौर पर एक असममित (asymmetric) परिणाम के साथ किसी मुख्य वेरिएबल की एक आकस्मिक वृद्धि (serendipitous increment) मात्र है (दूसरे शब्दों में, किसी चीज़ को सावधानीपूर्वक फिर से संयोजित करना और सुधारना जब तक कि कुछ अलग और/या अच्छा न हो जाए)। यदि आप मौलिक रूप से यह समझते हैं कि जब कोई नया इनोवेशन सामने आता है तो किस चीज़ में वृद्धि की जाती है, तो आप नई तकनीक में उस गति से महारत हासिल कर लेंगे जो आपके समकालीनों को हैरान कर देगी।
अपने जॉब एप्लीकेशन (job application) को अलग (stand out) कैसे बनाएं
यहाँ एक रहस्य (secret) है। शुरुआत (scratch) से कंपाइलर बनाने या गणित से लेकर किसी गैर-मामूली (nontrivial) क्रिप्टोग्राफी एल्गोरिदम को लागू करने जैसा कुछ पागलपन भरा काम करें। इस प्रकार का प्रोजेक्ट संभावित नियोक्ताओं (employers) का ध्यान कैट क्लासिफायर (cat classifier) या स्टैकिंग (staking) फीचर के साथ 100वाँ NFT मार्केटप्लेस बनाने की तुलना में कहीं अधिक आकर्षित करेगा।
एक प्रोजेक्ट दिखाता है कि आप जानते हैं कि किसी ट्यूटोरियल का अनुसरण कैसे किया जाता है। दूसरा यह प्रदर्शित करता है कि आप कठिन विषयों से सीधे निपट सकते हैं और उन अनगिनत समस्याओं को संभाल सकते हैं जो सामने आ सकती हैं लेकिन जॉब डिस्क्रिप्शन में नहीं दिखाई देती हैं।
मानो या न मानो, Solidity कंपाइलर में बग्स (bugs) होते हैं। एक एम्प्लॉयर किसे काम पर रखना पसंद करेगा, एक ऐसा इंजीनियर जो समस्या आने पर बस हाथ खड़े कर देता है, या एक ऐसा इंजीनियर जो समस्या पर ध्यान देता है, कंपाइलर सोर्स कोड में गहराई तक जाता है, GitHub पर एक इश्यू (issue) उठाता है, और समस्या को दरकिनार (circumvent) करने के लिए Solidity कोड को फिर से डिज़ाइन करता है? पहले इंजीनियर के GitHub पर एक दर्जन DeFi स्टैकिंग ऐप्स हो सकते हैं, लेकिन यह उस इंजीनियर की तुलना में फीका पड़ जाता है जो खरगोश के बिल (rabbit hole) को उसके निष्कर्ष तक एक्सप्लोर कर सकता है।
अब मैं समझता हूँ: शुरुआती चरण में पुनरावर्ती (recursively) बाइनरी ट्री (binary trees) को पलटने (flipping) और कुशल स्मार्ट कॉन्ट्रैक्ट (smart contracts) लिखने के बीच संबंध देखना बहुत कठिन है।
यह एहसास वैसा ही हो सकता है जब मैं मार्शल आर्ट्स सीख रहा था: “हम जंपिंग जैक (jumping jacks) क्यों कर रहे हैं जबकि हमें लोगों के चेहरे पर लात मारनी चाहिए? यह संबंध बहुत दूर का लगता है!”
मैं आपको बता सकता हूँ कि fundamentals को पूरी तरह से घिसने (grinding) ने मुझे इस अवधारणा से परिचित होने के दो साल से भी कम समय में एक बड़ी कंपनी में एक मशीन लर्निंग विभाग का नेतृत्व करने में सक्षम बनाया, और ब्लॉकचेन में पूर्णकालिक काम करने के एक साल से भी कम समय में Udemy पर एकमात्र विशेषज्ञ-स्तर (expert-level) के Solidity कोर्स बनाने में सक्षम बनाया। और आगे जो भी हाइप (hype) वाला क्षेत्र आएगा, मैं उसे 98% इंजीनियरों की तुलना में तेज़ी से सीखूंगा।
क्यों? क्योंकि हर तकनीक ज़मीन से उन्हीं फर्स्ट प्रिंसिपल्स (first principles) से बनी होती है, बस उन्हें अलग-अलग तरीके से जोड़ा गया होता है।
आप जितने अधिक फर्स्ट प्रिंसिपल्स को समझेंगे, आप computer science के किसी नए उप-क्षेत्र (subfield) में उतनी ही तेज़ी से सीख पाएंगे, क्योंकि अब आप शुरू (ground up) से नहीं सीख रहे हैं। इसके बजाय, आप बस उस जानकारी को जोड़ रहे हैं जो आप पहले से जानते हैं।
लेकिन मेरा स्टाफ इंजीनियर (staff engineer) बहुत अच्छा है और वह leetcode नहीं कर सकता!
Fundamentals केवल Leetcode की तुलना में बहुत व्यापक हैं। मैं यह नहीं कह रहा हूँ कि चूंकि आप एक एरे (array) के चारों ओर दो पॉइंटर्स (pointers) को स्थानांतरित कर सकते हैं, तो आप सॉफ्टवेयर डेवलपमेंट के किसी भी डोमेन में तेज़ी से महारत हासिल कर सकते हैं। एक निश्चित बिंदु के बाद डेटा स्ट्रक्चर्स और एल्गोरिदम का अध्ययन करने से कम लाभ (diminishing returns) मिलता है (हालांकि मैं तर्क दूंगा कि अधिकांश इंजीनियर उस इन्फ्लेक्शन पॉइंट (inflection point) तक नहीं पहुंचते हैं)।
Leetcode आपको नेटवर्किंग, लैंग्वेज थ्योरी, इन्फॉर्मेशन लीक, वर्चुअल मशीन, ऑपरेटिंग सिस्टम, कंपाइलर्स आदि पर नहीं परखता है।
यह चर्चा के दायरे से बाहर है, लेकिन उच्च स्तर पर, सॉफ्ट स्किल्स (soft skills) बहुत मायने रखते हैं। मैं इसे नज़रअंदाज़ नहीं करना चाहता। लेकिन हम इस बात पर सहमत हो सकते हैं कि यदि सॉफ्ट स्किल्स लगभग समान हैं, तो बेहतर तकनीकी परिपक्वता (technical maturity) वाला इंजीनियर आगे निकलेगा।
यदि आपके पास ऐसी समस्याओं का अच्छा-खासा अनुभव (exposure) है जो आपको उनसे निपटने के लिए मजबूर करती हैं और आप पैटर्न को तेज़ी से पहचान सकते हैं, तो भी आप fundamentals का अंतर्ज्ञान (intuition) प्राप्त कर सकते हैं। हालाँकि, यादृच्छिक संयोग (random chance) से सीखने की तुलना में सीधे नींव (foundations) का अध्ययन करना हमेशा अधिक कुशल (efficient) होगा। हो सकता है कि आप अपने स्टाफ इंजीनियर जितने भाग्यशाली न हों।
Fundamentals का अभ्यास कैसे करें — केवल leetcode नहीं
- एक बेकार (useless) फंक्शनल प्रोग्रामिंग भाषा (functional programming language) सीखें। यह आपको बिट स्ट्रिंग्स को एक अलग तरीके से देखने के लिए मजबूर करेगा।
- उस भाषा में Leetcode मीडियम (medium) स्तर तक अपना रास्ता बनाएं।
- शुरुआत (scratch) से एक कंपाइलर लिखें।
- शुरुआत से एक सरल ऑपरेटिंग सिस्टम या वर्चुअल मशीन बनाएं या किसी मौजूदा को संशोधित करें।
- कॉम्प्लेक्सिटी थ्योरी (complexity theory) सीखें (संकेत: यह केवल O(f(n)) एनालिसिस नहीं है)।
- एक क्रिप्टोग्राफी (cryptography) कोर्स लें और वास्तव में एल्गोरिदम को फिर से लागू (re-implement) करें।
- यदि आप मशीन लर्निंग कर रहे हैं, तो एक उचित लीनियर अलजेब्रा (linear algebra) और सांख्यिकी (statistics) की कक्षा लें।
Computer science में सब कुछ एक बिट स्ट्रिंग है जो किसी बॉक्स में जाती है और दूसरी बिट स्ट्रिंग के रूप में बाहर आती है। आप इसे कॉम्प्लेक्सिटी थ्योरी में सीखते हैं। ये सभी क्षेत्र बिट स्ट्रिंग्स में एब्स्ट्रैक्शन और उपयोगी व्याख्याओं को लागू करने के तरीके मात्र हैं। आप जितने अधिक एब्स्ट्रैक्शन जानेंगे, आप उतने ही अधिक शक्तिशाली डेवलपर बनेंगे।
क्या आपको पहले fundamentals सीखने चाहिए?
यदि आप कोडिंग में बिल्कुल नए हैं (संभावना है कि आप नहीं हैं यदि आप इस लेख को पढ़ रहे हैं, लेकिन मैं इस खंड को शामिल करूंगा), तो मुझे नहीं लगता कि सबसे पहले fundamentals सीखना कड़ाई से आवश्यक है। मैं देखता हूँ कि कई CS अंडरग्रेजुएट्स उन्हीं अनुभवों से गुज़र रहे हैं जिनसे मैं एक युवा मार्शल आर्टिस्ट के रूप में गुज़रा था। सामग्री का अध्ययन यह समझे बिना करना कि यह क्यों महत्वपूर्ण है, इष्टतम (optimal) नहीं है। यह बहुत अच्छा है अगर आपके पास कोई ऐसा शिक्षक है जो आपको फर्स्ट प्रिंसिपल्स में महारत हासिल करने का आत्मविश्वास रखने के लिए प्रेरित करता है, लेकिन यह विलासिता (luxury) हर किसी के पास नहीं होती है।
मुझे लगता है कि एक उचित सीखने की यात्रा निम्नलिखित की तरह दिख सकती है। बहुत सफल सेल्फ-टॉट (self-taught) इंजीनियरों या web2 बूटकैंप ग्रैड्स (grad’s) की सीखने की यात्रा ऐसी ही दिखती है।
अभी शुरुआत (Just starting off) → ट्यूटोरियल हेल (tutorial hell) → करके सीखना (learning from doing) → fundamentals में महारत हासिल करना (mastering the fundamentals)।
एक सफल चार वर्षीय डिग्री CS छात्र की सीखने की यात्रा कुछ इस तरह दिख सकती है:
Fundamentals में महारत हासिल करना (Mastering the fundamentals) → करके सीखना (learning from doing) → fundamentals को फिर से देखना (revisiting the fundamentals)।
यदि आप अभी भी कार्यात्मक एप्लिकेशन (functional applications) बनाने में बुनियादी चीजें करने के लिए संघर्ष कर रहे हैं, तो मूलभूत (foundational) विषयों को सीखने में देरी करना ठीक है। लेकिन कार्यात्मक एप्लिकेशन बनाने में सहज (comfortable) न हों क्योंकि यदि आप fundamentals में महारत हासिल नहीं करते हैं तो आप वहीं फंस जाएंगे।
हाँ, ट्यूटोरियल हेल (tutorial hell) जैसी कोई चीज़ होती है, और इसका समाधान यह है कि सीधे छलांग लगाएं और निर्माण (build) करें।
लेकिन एक बार जब आप ट्यूटोरियल हेल से बाहर निकल जाते हैं, तो अगला कदम अधिक एप्लिकेशन विकसित करना नहीं है, बल्कि ऐसी चीजों को कोड करना है जो सामान्यीकृत (generalizable) computer science कौशल विकसित करती हैं।
यदि आप एप्लिकेशन नहीं बना सकते हैं, तो आपको भुगतान नहीं किया जाएगा। लेकिन यदि आपके पास नींव (foundations) नहीं है, तो आपको किसी वांछनीय नौकरी के लिए काम पर हायर (hired) नहीं किया जाएगा, एक वांछनीय प्रमोशन (promotion) प्राप्त करना तो दूर की बात है, जब तक कि आपके पास आवश्यक बैकबोन स्किलसेट (backbone skillset) न हो।
एक इंटरव्यूअर (interviewer) के रूप में
मैं यह वकालत नहीं कर रहा हूँ कि हर एम्प्लॉयर (employer) को Leetcode शैली का परीक्षण (test) करना चाहिए या कुछ ऐसा करना चाहिए जो मेरे द्वारा पहले बताए गए fundamentals पर सवाल (quizzes) करे। यदि आप केवल अपेक्षाकृत सीधे-सादे (straightforward) एप्लिकेशन बना रहे हैं, तो इंजीनियरों को केवल उसी क्षमता पर परखना उचित है। हालाँकि, इस लेख के इच्छित दर्शक (intended audience) वे इंजीनियर हैं जो अपने करियर को आगे बढ़ाना चाहते हैं (यही RareSkills प्रदान करता है)। करियर में उन्नति (Career advancement) बार-बार एक ही एप्लिकेशन के कुछ रूप (variation) बनाने से नहीं आएगी।
निष्कर्ष (Conclusion)
सॉफ्टवेयर डेवलपमेंट में हम जो कुछ भी करते हैं वह बिट्स (bits) की एक महिमामंडित व्याख्या (glorified interpretation) और ट्रांसफॉर्मेशन (transformation) है। डेटा ट्रांसफॉर्मेशन एक ऐसा कौशल (skill) है जिसे जानबूझकर किए गए प्रशिक्षण (deliberate training) के साथ सीधे विकसित किया जा सकता है। आप computer science के जितने अधिक क्षेत्रों का अध्ययन करेंगे, आप मौजूदा समस्या के लिए उतनी ही बड़ी शब्दावली (vocabulary) ला सकते हैं। सर्वश्रेष्ठ इंजीनियर इन कौशलों को जानबूझकर विकसित करते हैं। औसत डेवलपर्स सीधे फ्रेमवर्क (frameworks) का उपयोग करने लगते हैं। फ्रेमवर्क आउट ऑफ डेट (out of date) हो जाते हैं। सूचना एन्कोडिंग (information encoding) और मैनिपुलेशन के मौलिक प्रमेय (fundamental theorems) नहीं होते हैं।
आपके और उस इंजीनियर के बीच का अंतर जो आपसे $100,000 अधिक कमाता है, वह किसी भाषा (language) या फ्रेमवर्क (framework) का ज्ञान नहीं है। यह उस फ्रेमवर्क के घटकों (components) का ज्ञान है। और वे घटक सीधे computer science की नींव (foundations) पर निर्भर करते हैं।
लीक से हटकर (Go off the beaten path) चलें।
उन डराने वाले (intimidating) विषयों का अध्ययन और अभ्यास करें जो बेकार (useless) लगते हैं।
लंबे समय में यह केवल एक शॉर्टकट (shortcut) नहीं है।
यह एकमात्र रास्ता है।
RareSkills
इस लेख को पढ़ने के लिए धन्यवाद। जैसा कि आप देख सकते हैं, मैं डेवलपर शिक्षा (developer education) को लेकर भावुक हूँ। इसीलिए मैंने RareSkills बनाया। यह कोड ब्लॉकचेन डेवलपमेंट (code blockchain development) को सही तरीके से सिखाने के लिए है। तो कृपया हमारे blockchain bootcamp को चेक करें। हम web3 कोडिंग में बिल्कुल नए लोगों के लिए कोर्स से लेकर पेशेवर Solidity डेवलपर्स के उद्देश्य वाले कोर्स तक सब कुछ प्रदान करते हैं।
हमारे आधे छात्रों के पास पहले से ही स्मार्ट कॉन्ट्रैक्ट डेवलपर (smart contract developers) के रूप में नौकरी है, इसलिए हम किसी भी विशिष्ट बूटकैंप (bootcamp) की तुलना में कहीं अधिक उन्नत (advanced) हैं। और चूंकि हम fundamentals पर बहुत जोर देते हैं, इसलिए आप जो सीखेंगे वह ब्लॉकचेन के बाहर के क्षेत्रों में भी प्रासंगिक (relevant) होगा।
मूल रूप से 8 फरवरी, 2023 को प्रकाशित (Originally Published Feb 8, 2023)