दस वर्षों में स्वयं प्रोग्रामिंग सीखें (1998)
यह दावा कि आप “24 घंटों में प्रोग्रामिंग खुद सिख सकते हैं” व्यापक रूप से अस्वीकार किया जाता है; इसके बजाय उद्देश्यपूर्ण अभ्यास, विविध प्रोजेक्ट्स, और सहज-बुद्धि जमा करने वाली दशकों-लंबी यात्रा को प्राथमिकता दी जाती है। टिप्पणीकार गहरी विशेषज्ञता की तुलना बूटकैंप्स के माध्यम से नौकरी-योग्य बनने जैसे अधिक सीमित लक्ष्यों से करते हैं, और नोट करते हैं कि सफलता बहुत हद तक पूर्व पृष्ठभूमि, प्रेरणा, और किसी भी कोर्स से परे निरंतर प्रयास पर निर्भर करती है। वे यह भी विचार करते हैं कि क्षेत्र के टूल्स, कार्यप्रणालियाँ (जैसे Scrum), और अब AI assistants वास्तव में प्रोग्रामर्स क्या और कैसे सीखते हैं, इसे कैसे आकार देते हैं, जबकि ज़ोर देते हैं कि दीर्घकाल में बुनियादी बातें और स्वयं-निर्देशित जिज्ञासा ही सबसे अधिक मायने रखती हैं।
“निपुणता” तक पहुँचने का समय और 10-वर्षीय क्षितिज
- कई लोग मानते हैं कि लगभग 10 वर्षों का निरंतर, विविध अभ्यास एक “ठोस” डेवलपर बनने के लिए सही लगता है, हालांकि जरूरी नहीं कि एक मास्टर बनने के लिए।
- 10,000 घंटे का नियम-आधारित अनुमान अत्यधिक सरलीकृत माना जाता है, लेकिन दिशा के लिहाज़ से उपयोगी है; लोग केवल बीते समय के बजाय उद्देश्यपूर्ण, क्रमशः कठिन होती प्रैक्टिस पर ज़ोर देते हैं।
- कई लोगों का कहना है कि कुछ डेवलपर यदि खुद को लगातार चुनौती नहीं देते, तो “1 साल के अनुभव को 10 बार दोहराने” पर ही अटक जाते हैं।
पेशेवर काम बनाम हॉबी प्रोजेक्ट्स
- कुछ लोग तर्क देते हैं कि एक सामान्य 40h/week सॉफ़्टवेयर नौकरी वर्षों में गहरी दक्षता जमा करने के लिए पर्याप्त है।
- दूसरों का कहना है कि केवल “सामान्य व्यावसायिक काम” करना (खासकर एक ही कंपनी या स्टैक में) सीखने को स्थिर कर सकता है; साइड प्रोजेक्ट्स और नए डोमेन विकास को तेज़ करते हैं।
- “मैं इसे प्यार करता हूँ इसलिए हर समय कोड करूँ” और “पूरा दिन की नौकरी के बाद मैं शामें कोडिंग में नहीं लगाऊँगा” के बीच तनाव है।
प्रोग्रामिंग में आने के रास्ते: CS, बूटकैंप्स, और स्वयं-शिक्षण
- कई सफलता की कहानियाँ: बूटकैंप्स, छोटे इंटेंसिव कोर्स, बेसमेंट में स्वयं-अध्ययन, गैर-CS डिग्री से डेवलपमेंट में मोड़।
- पैटर्न: सफलता के लिए उच्च प्रेरणा, “मुख्य” प्रशिक्षण से परे कई घंटे, और अक्सर एक कठिन पहली नौकरी की ज़रूरत होती है जहाँ असली सीख होती है।
- CS की बुनियादी समझ की कमी बाद में महसूस हो सकती है (जैसे, डेटा स्ट्रक्चर्स, एल्गोरिदम), लेकिन बहुत से लोग चलते-चलते कमियाँ भर लेते हैं।
सॉफ़्टवेयर इंजीनियरिंग की प्रकृति और ज्ञान का क्षरण
- इस पर बहस कि क्या सॉफ़्टवेयर विज्ञान, इंजीनियरिंग, या सामाजिक/विधायी प्रणालियों के अधिक निकट है।
- कुछ का दावा है कि बुनियादें (एल्गोरिदम, OS theory, concurrency, आदि) स्थिर हैं; अव्यवस्था भाषाओं, फ्रेमवर्क्स, और टूलिंग में आर्थिक दबावों के तहत है।
- दूसरों को लगता है कि दिन-प्रतिदिन का बहुत सा प्रयास खराब टूल्स, लाइब्रेरीज़, और “entropy” से जूझते हुए व्यर्थ हो जाता है, जैसे खराब भौतिक टूल्स या prefab components।
Scrum, प्रक्रिया, और टीम वर्कफ़्लो
- Scrum की बहुत कड़ी आलोचना: daily standups को “advertisements” कहना, अल्पकालिक optics पर ध्यान, गहरे काम का fragmentation, और engineering outcomes से अधिक management reporting की सेवा करना।
- कुछ लोग एक stripped-down core (जैसे Kanban, simple standups) का समर्थन करते हैं; दोष अक्सर बुरी संस्कृति और over-ceremony पर डाला जाता है, न कि core ideas पर।
AI Tools, Learning, और Deliberate Practice
- कुछ सीखने वाले कहते हैं कि ChatGPT जैसे tools ने उन्हें हार मानने से रोका, क्योंकि उन्होंने उनकी क्षमता की सीमा पर उन्हें unblocking किया।
- दूसरों को चिंता है कि AI और autocomplete गहरी समझ को कमजोर करते हैं, इसे हमेशा GPS इस्तेमाल करने और कभी रास्ता न सीखने से जोड़ते हैं।
- उभरता हुआ नियम: पहले खुद जूझो, फिर hints के लिए AI को एक senior developer की तरह इस्तेमाल करो; boilerplate और tests के लिए इसे बहुत उपयोग करो, लेकिन core problem-solving के लिए इसे crutch मत बनाओ।