हर प्रोग्रामर को आज़माने चाहिए ऐसे चुनौतीपूर्ण प्रोजेक्ट (2019)
“हर प्रोग्रामर को आज़माने चाहिए” वाले चुनौतीपूर्ण प्रोजेक्ट्स — जैसे text editors, toy operating systems, emulators, और ray tracers — की एक लोकप्रिय सूची इस बहस को जन्म देती है कि कौन-से side projects वास्तव में उपयोगी कौशल विकसित करते हैं। कई लोग तर्क देते हैं कि मौलिक प्रणालियों को दोबारा implement करने से software और hardware के काम करने के तरीके की समझ गहरी होती है, जबकि अन्य का कहना है कि modern software engineering अधिकतर libraries चुनने, complexity प्रबंधित करने, और टीमों में काम करने के बारे में है, न कि low-level implementation के बारे में। यह चर्चा work–life balance, “programmer” और “software engineer” के अंतर, और third-party code पर अत्यधिक निर्भरता तथा “Not Invented Here” आदतों—दोनों—के जोखिम पर भी व्यापक सवाल उठाती है।
प्रोजेक्ट बनाम जीवन संतुलन / गैर-कंप्यूटर शौक
- कुछ लोगों का तर्क है कि “हर प्रोग्रामर को चाहिए” जैसी सूचियाँ खटकती हैं; काम पहले से ही मांग भरा है और खाली समय को निर्देशात्मक रूप से कोड से नहीं भरना चाहिए।
- कई लोग कंप्यूटर से पूरी तरह असंबंधित शौकों (वुडवर्किंग, बागवानी, संगीत, हाइकिंग) की वकालत करते हैं, और स्पष्ट रूप से पाठकों को “घास छूने” की याद दिलाते हैं।
- अन्य लोग नोट करते हैं कि बाहरी/शारीरिक गतिविधियाँ और गहरे प्रोग्रामिंग प्रोजेक्ट परस्पर-विरोधी नहीं हैं।
सुझाए गए प्रोजेक्ट्स की कठिनाई और दायरा
- इस बात पर असहमति है कि क्या गेम बॉय एमुलेटर “लिटिल OS” से अधिक कठिन है; कुछ कहते हैं OS कठिन है, जबकि अन्य कहते हैं कि सटीक टाइमिंग और एज केसों वाला एमुलेटर अधिक मुश्किल है।
- रे ट्रेसर को एक स्पेक्ट्रम के रूप में देखा जाता है: एक साधारण वीकेंड रे ट्रेसर से लेकर कई महीनों वाले, प्रोडक्शन-ग्रेड सिस्टम तक। इसी तरह, “वेब ब्राउज़र” का मतलब टेक्स्ट-ओनली से लेकर पूर्ण आधुनिक ब्राउज़र तक हो सकता है।
- कई लोग इस बात पर ज़ोर देते हैं कि सीखने के लिए आप पूर्ण निष्ठा के बजाय एक न्यूनतम, काम करने वाले उपसमुच्चय तक रुक सकते हैं।
अतिरिक्त प्रोजेक्ट आइडिया
- आम सुझाव: सर्च इंजन + क्रॉलर, CAS (computer algebra system), रे ट्रेसर, सर्च-इंजन जैसा टेक्स्ट सर्च, सरल HTTP wrapper, वेब फ्रेमवर्क, Netcat clone, memcached जैसा कैश, मिनी-डेटाबेस, फ़ाइल सिस्टम, बुनियादी Docker clone, xv6 के जरिए mini OS, सरल MMOs, robotics, drones, CFD / fluid dynamics, inverted pendulum robots.
- सुरक्षा संबंधी सुझावों में buffer overflow और SQL injection लैब्स, Wireshark exploration, और CTFs शामिल हैं।
प्रोग्रामिंग बनाम software engineering बहस
- एक पक्ष: toy compilers/OSes/editors “programmer chops” तो बेहतर करते हैं, लेकिन “software engineering” नहीं (library चयन, बड़े पैमाने का डिज़ाइन, maintainability, optimization tradeoffs)।
- जवाबी तर्क: ठोस low-level foundations के बिना आप अच्छे engineer नहीं बन सकते; चीज़ें implement करने से यह सीख मिलती है कि उन्हें कब पुनः आविष्कार नहीं करना चाहिए।
- Big-O पर तीखी बहस: कुछ कहते हैं कि CRUD apps में यह शायद ही प्रासंगिक है; अन्य धीमे, फूले हुए software के लिए complexity की अनभिज्ञता को दोष देते हैं।
Not Invented Here बनाम reimplementation के माध्यम से सीखना
- कई लोग editors, search, DBs आदि को फिर से implement करने का बचाव “recreational programming” और systems को गहराई से समझने के तरीके के रूप में करते हैं।
- आलोचक इसे NIH कहते हैं और तर्क देते हैं कि modern systems (जैसे search engines) को पूरी तरह scratch से समझदारी से नहीं बनाया जा सकता और उन्हें मौजूदा libraries के साथ एकीकृत करना ही होगा।
- कई लोग संतुलन पर ज़ोर देते हैं: hobby projects में scratch से लिखें, लेकिन production में dependencies के साथ व्यावहारिक और चयनात्मक रहें।
Text editors, data structures, और उपयोगिता
- text को arrays बनाम ropes/piece tables के रूप में संग्रहीत करने पर बहस: कुछ रिपोर्ट करते हैं कि array-based editors megabytes तक ठीक हैं; अन्य pathological edits और बहुत बड़ी files के बारे में चेतावनी देते हैं।
- कई लोग तर्क देते हैं कि editor की usability और correctness आंतरिक data structures को micro-optimize करने से अधिक महत्वपूर्ण हैं।
- केवल visible text render करना और बहुत बड़ी/लंबी-line files को कुशलतापूर्वक संभालना वास्तविक चुनौतियों के रूप में उद्धृत किया जाता है।