Toy software बनाने की खुशी

• Toy software बनाना software development की मूल खुशी और रचनात्मकता को फिर से पाने का एक तरीका है
• ऐसे समय में जब AI और औद्योगीकरण के कारण software development की शुद्ध खुशी कम होती जा रही है, व्यक्तिगत प्रोजेक्ट के रूप में सरल toy programs बनाना व्यावहारिक काम में उपयोगी ज्ञान और गहरी समझ हासिल करने का अवसर बन सकता है
• Toy software 80:20 नियम के अनुसार न्यूनतम code से अधिकतम functionality लागू करता है, और अत्यधिक design या पूर्णता के प्रति आसक्ति से बचना इसका मुख्य बिंदु है
• LLM जैसे AI tools पर निर्भर हुए बिना खुद टकराकर कुछ बनाने का अनुभव ही सीखने और आगे बढ़ने की असली खुशी है

---

हमें और ज़्यादा toy programs क्यों बनाने चाहिए

• Richard Feynman का प्रसिद्ध कथन: “जिसे मैं बना नहीं सकता, उसे मैं समझता भी नहीं हूँ” → किसी चीज़ को सीधे बनाकर देखना गहरी समझ तक ले जाता है
• प्रचलित सलाह ‘पहिया दोबारा मत बनाओ’ के विपरीत, पहिया खुद बनाकर देखने का अनुभव पढ़ाई या सैद्धांतिक सीख से अधिक सिखाता है
• हाल के समय में AI और software के औद्योगीकरण ने development की खुशी और कारीगरी की भावना को खतरे में डाल दिया है
• Toy software बनाना हमें फिर से कंप्यूटरों में डूब जाने वाली वह सरल खुशी लौटा सकता है

Toy programs के सिद्धांत: Keep it simple

• Toy software 80:20 सिद्धांत का पालन करता है: 20% प्रयास से 80% functionality हासिल करना
• लक्ष्य अंतिम product नहीं, बल्कि सरलता और मुख्य सिद्धांतों को खुद लागू करना है
• Over-engineering से बचते हुए केवल ज़रूरी code लिखने के तरीके पर ज़ोर
• सभी code paths को अभी तक implement न किए गए रूप में छोड़कर, ज़रूरत पड़ने पर धीरे-धीरे implementation बढ़ाने वाला approach सुझाया जाता है
• देखने में छोटा लगने वाला system भी वास्तव में हाथ लगाकर बनाने पर अपेक्षा से काफ़ी आसान हो सकता है

Toy software के अतिरिक्त फ़ायदे

• Toy projects से मिला ज्ञान वास्तविक काम में issue tracing, bug fixing और गलतियों की रोकथाम में उम्मीद से ज़्यादा मददगार साबित होता है
• खुद टकराकर constraints का अनुभव करना software की प्रकृति पर गहरी अंतर्दृष्टि देता है, और कभी-कभी नई तरह के समाधान भी दिखाता है

उदाहरण: अलग-अलग toy software projects की सूची

पिछले 15 वर्षों में सीधे implement किए गए toy projects के प्रकारों को कठिनाई और अनुमानित समय के साथ व्यवस्थित किया गया है। हर project के साथ छोटा विवरण और अतिरिक्त संदर्भ सामग्री भी शामिल है

• Regex engine (कठिनाई 4/10, 5 दिन) : POSIX शैली के regular expressions को parse करना और matching strings पहचानना; इससे regex की आंतरिक कार्यप्रणाली की गहरी समझ मिलती है
• x86 OS kernel (कठिनाई 7/10, 2 महीने) : CLI, सरल drivers, memory manager आदि शामिल; आगे in-memory filesystem, ELF executables, GUI, process isolation जैसी चुनौतियाँ जोड़ी जा सकती हैं
• GameBoy/NES emulator (कठिनाई 6/10, 3 हफ्ते) : सरल instruction set और hardware को समझने का अच्छा अभ्यास; PPU, PSG और अनोखे cartridge formats भी implement किए जा सकते हैं
• GameBoy Advance game (कठिनाई 3/10, 2 हफ्ते) : sprite-आधारित सरल game, GBA development community सक्रिय है, और system structure इतना सीमित है कि एक व्यक्ति इसे अच्छी तरह समझ सकता है
• 2D physics engine (कठिनाई 5/10, 1 हफ्ता) : बुनियादी Newtonian mechanics और सरल collision handling; आगे complex shapes, inertia, resolution algorithms, soft body और composite interactions तक बढ़ाया जा सकता है
• Dynamic interpreter (कठिनाई 4/10, 1~2 हफ्ते) : tree-walking interpreter; अपनी language बनाना तकनीकी और रचनात्मक दोनों तरह की खुशी देता है
• C-family compiler (कठिनाई 8/10, 3 महीने) : सरल type system और target environment से शुरुआत; आगे optimizations और अलग-अलग backends के लिए architecture design तक जा सकता है
• Text editor (कठिनाई 5/10, 2~4 हफ्ते) : सरल file I/O से शुरुआत, UI toolkit (QT/GTK आदि) का उपयोग संभव, या console-based approach; unicode, syntax highlighting, multi-buffer, LSP जैसी सुविधाएँ जोड़ी जा सकती हैं
• Async runtime (कठिनाई 6/10, 1 हफ्ता) : Rust में impl Future tasks को संभालना और concurrency लागू करना, साथ में I/O waking जोड़ना
• Hash Map (कठिनाई 4/10, 3~5 दिन) : इसकी आंतरिक कार्यप्रणाली, closed और open addressing, Robin Hood नियम सीखना, और performance व सही उपयोग-समय समझना
• Rasteriser / Texture Mapper (कठिनाई 6/10, 2 हफ्ते) : 3D graphics pipeline की संरचना सीखना; vector math, Z-buffer, texture mapping और shading algorithms तक गहराई में जाना संभव
• Signed Distance Field rendering (कठिनाई 5/10, 3 दिन) : गणितीय spatial representation, सरल visualization, और shaders व vector math की समझ
• Voxel engine (कठिनाई 5/10, 2 हफ्ते) : 3D graphics या game development का अनुभव हो तो समझना आसान; texture, procedural generation, networking जैसी अतिरिक्त चुनौतियाँ जोड़ी जा सकती हैं
• Threaded Virtual Machine (कठिनाई 6/10, 1 हफ्ता) : तेज interpreter; architecture-specific code generation के बिना optimized interpreter बनाना, और compiler-जैसी performance का अनुभव करना
• GUI toolkit (कठिनाई 6/10, 2~3 हफ्ते) : बुनियादी UI tools लिखने के बाद layout engine, text shaping, accessibility जैसी उन्नत सुविधाएँ खुद implement की जा सकती हैं
• Orbital mechanics simulator (कठिनाई 6/10, 1 हफ्ता) : Newtonian gravity model को सरल रूप में implement करना; कई celestial bodies की interaction, integration algorithms, visualization, और NASA data के उपयोग तक विस्तार संभव
• Bitwise Challenge (कठिनाई 3/10, 2~3 दिन) : केवल 64-bit state से पुनरुत्पादित होने वाला game; रचनात्मक state management का अभ्यास, और GitHub पर विस्तृत नियम देखे जा सकते हैं
• ECS framework (कठिनाई 4/10, 1~2 हफ्ते) : Entity-Component-System संरचना को खुद implement करना, language type system के साथ integration, और high performance व constraints के अनुसार अनुकूलन
• CHIP-8 emulator (कठिनाई 3/10, 3~6 दिन) : 1970 के दशक की सरल virtual machine; तेज implementation, और कई fan games को देखना व चलाना संभव
• Chess engine (कठिनाई 5/10, 2~5 दिन) : नियमों से शुरुआत कर धीरे-धीरे आगे बढ़ना; अपने बनाए engine से हारना भी developer की growth का एक यादगार पल होता है
• POSIX Shell (कठिनाई 4/10, 3~5 दिन) : POSIX-आधारित shell के सिद्धांत और सीमाएँ; वास्तविक shell language compatibility लागू करके गहरी समझ और अनेक tricks का अनुभव

LLM जैसे tools के उपयोग पर सलाह

• LLM जैसे उन्नत tools उपयोगी हैं, लेकिन सच्ची सीख तब और गहरी होती है जब आप खुद तलाश करते हैं
• मौजूदा solutions को पहले से देखने के बजाय, अज्ञात क्षेत्र को टटोलते हुए अपना उत्तर खोजने की प्रक्रिया अधिक गहरा संतोष देती है
• LLM के बिना toy project करना शुरुआत में असहज और कठिन लग सकता है, लेकिन समय के साथ यह अपनी तरह की तकनीकी खुशी और ऊँची उपलब्धि की भावना देता है

• कार से जाने पर एक धावक की ‘runner’s high’ महसूस नहीं की जा सकती → शॉर्टकट नहीं, बल्कि प्रत्यक्ष अनुभव से गहरी खुशी मिलती है

[tolluset]

मुझे यह बात अच्छी तरह समझ आती है कि इसे LLM के बिना करने को कहा जा रहा है। अगर बहुत तेज़ development की ज़रूरत न हो, तो एक-एक चीज़ को खुद समझते हुए बनाना ज़्यादा मज़ेदार और संतोषजनक लगता है।

[nezz1204]

अच्छा, तो बात toy project की थी। सिर्फ़ शीर्षक देखकर मुझे लगा था कि खिलौनों में जाने वाला software बनाने की बात हो रही है। haha

[GN⁺]

Hacker News राय

• सोच रहा हूँ कितने लोग LLM को search engine की तरह इस्तेमाल करते हैं। पहले मैं Google पर “pros cons mysql mongodb” जैसा खोजता था और official docs, forums, blogs, Stack Overflow तक पढ़ता हुआ बहुत समय लगाता था। लेकिन पढ़ते-पढ़ते सीखने में जो समय जाता था, वह हमेशा स्वागतयोग्य था। अब मैं LLM को थोड़ा ज़्यादा specific prompt देता हूँ, जैसे “फोटो स्टोर करते समय mysql vs mongodb के फायदे-नुकसान, reference links के साथ”। इससे जल्दी core points समझ आ जाते हैं, और links भी मिल जाते हैं, इसलिए hallucination पर निर्भर नहीं रहना पड़ता। कभी-कभी “postgres में फोटो metadata स्टोर करने के लिए data schema बना दो, X को दूसरी table में अलग करना चाहता हूँ” जैसी specific request भी करता हूँ, लेकिन यह तभी जब मुझे ठीक-ठीक पता हो कि किस तरह का output चाहिए। बस typing time बचाना हो या type के exact नाम जैसे int और integer थोड़ी देर के लिए भूल गया हूँ, तब काम आता है

  • अगर LLM को technical query engine की तरह इस्तेमाल करो, तो ऊपर-ऊपर से वह ठीक लगता है, लेकिन अहम जगहों पर गलत जानकारी देने के मामले बहुत हैं। अगर सीधे भरोसा करके उसके जवाब के पीछे चल पड़े, तो बेकार में कई घंटे, कई दिन भी बर्बाद हो सकते हैं। Reference links माँगने पर भी कभी असली जानकारी मिलती है, कभी पूरी तरह unrelated चीज़ें—लगभग आधा-आधा। फिर भी एक चीज़ यह पक्का बहुत अच्छी करता है: "tip-of-my-tongue" तरह की reverse lookup। यानी concept समझाओ तो उससे जुड़े search terms सुझाने में यह लगातार अच्छा और संतोषजनक है
  • जल्द ही कंपनियाँ बहुत पैसा देकर LLM से यह सुनिश्चित करवाएँगी कि उनके products बेहतर comparison के रूप में सामने आएँ। LLM framing और emphasis बदलकर result को ‘organic’ जैसा दिखा सकता है। क्योंकि वह सिर्फ सच और evidence-आधारित जानकारी दिखाते हुए भी ‘context का emphasis’ बदल सकता है
  • मैं भी बिल्कुल इसी तरह LLM को search के लिए इस्तेमाल करता हूँ। एहसास कुछ वैसा है जैसे 2010 के शुरुआती दौर का Google फिर लौट आया हो—जब सब कुछ मिल जाता था। बेशक वह दौर ज़्यादा लंबा नहीं चला, और आज की googling तो दर्द और निराशा जैसी लगती है। Google और marketers द्वारा लाए गए बदलावों को लेकर शिकायतें बहुत हैं, लेकिन अभी के LLM online information को तुरंत surface करने में बेहद efficient लगते हैं। Reference links भी आमतौर पर काफी accurate होते हैं। आखिरकार वही पुराने बदलाव के forces यहाँ भी काम करेंगे, तो लगता है यह बस एक छोटा-सा मौका है, फिर यह भी खत्म हो जाएगा
  • मैं भी उन लोगों में हूँ जो LLM को search engine की तरह इस्तेमाल करते हैं। अभी तक AI IDE इस्तेमाल नहीं करता। हाल ही में एक live technical interview में मैंने अपने चुने हुए LLM से Google की तरह queries करके जवाब देने की कोशिश की, तो interviewer ने कहा कि AI को इस तरह इस्तेमाल करने वाला candidate उसने पहली बार देखा है। मुझे लगा था ज़्यादातर developers अभी AI IDE से पहले search के लिए ही AI इस्तेमाल करते होंगे। क्या हमारे जैसे मामले अभी भी दुर्लभ हैं?
  • मैं तो development में भी LLM को search engine की तरह इस्तेमाल करता हूँ। जैसे, “/src/foo में मेरे cloned repo को analyze करके समझाओ कि barFeature कैसे implement हुआ है। अब /src/baz project देखो और बताओ कि foo वाला approach baz में लागू करना क्यों मुश्किल है।” मैं इससे कुछ बिल्कुल नया नहीं बनवाता, बस existing project को अपने ideas में translate करने के लिए उपयोग करता हूँ। सच में नया और challenging development तो मुझे खुद code करना ही अच्छा लगता है

• करियर के हिसाब से मेरे सबसे अच्छे फैसलों में से एक था नौकरियों के बीच 6 महीने का ब्रेक लेकर personal project करना। शुरू में कई projects शुरू करने का इरादा था, लेकिन जब limits नहीं होतीं तो scope बढ़ता ही जाता है और आखिर में कुछ पूरा नहीं होता। इसलिए तय किया कि हर project पर सिर्फ 1 हफ्ता दूँगा। एक हफ्ते में जितना बन सके, उतना ही बनाया। Zero से शुरू करके किसी नई language, framework, या अनजाने domain में सिर्फ 1 हफ्ते में कुछ usable बना लेने का अनुभव मेरे confidence के लिए जबरदस्त था। इससे यह भी याद आया कि मुझे programming मूल रूप से क्यों पसंद थी। अगर नौकरियों के बीच कुछ महीनों का आराम मिले, तो Silicon Valley interview की तैयारी करने के बजाय toy projects बनाना आपको खुद हैरान कर देगा कि आप पहले से कितना कुछ जानते थे

  • अगर AI generation tools हों, तो ऐसे personal toy projects में वे बहुत मदद करते हैं। मैं मुख्यतः backend करता हूँ, लेकिन frontend भी कर सकता हूँ। बस CSS में इतना समय चला जाता था कि पहले कई personal projects पूरे ही नहीं हो पाते थे। अब AI से “इसे सुंदर बना दो” कहो तो वह 85% तक तैयार रूप दे देता है, और फिर बस bugs और थोड़े edits करने होते हैं, इसलिए जल्दी finish हो जाता है। पहले जो development कीचड़ जैसा लगता था, अब इतना आसान हो गया है कि मैं personal projects ज़्यादा बनाने लगा हूँ
  • हाल में मैं इस्तेमाल की जा रही library से इतनी निराशा जमा कर चुका हूँ कि खुद उसे ठीक करने की तरफ चला गया हूँ। Incomplete onboarding docs, टूटा हुआ SDLC, गंभीर performance problems वगैरह दिखें तो पूरा दिन fixes में निकल जाता है। Collaborative projects में कोई आपका इंतज़ार कर रहा होता है, लेकिन personal toy projects में side quests में भटक जाना बहुत आसान है
  • जानना चाहता हूँ कि आप 6 महीने का ब्रेक लेकर अगली नौकरी कैसे पा गए। मैं भी 6 महीने आराम करना चाहता हूँ, लेकिन डर लगता है कि कहीं नौकरी न मिले और ब्रेक उससे भी लंबा न हो जाए
  • बचपन में classic ASP + SQL से server सेट कर लेता था, HTML/CSS/JS सब खुद संभालता था और आसानी से deploy कर देता था। तब तो बस FTP से files upload करनी होती थीं। अब कुछ modern तरीकों को explore करना चाहता हूँ, लेकिन personal project करते समय हर बार deployment और development process/lifecycle को लेकर उलझ जाता हूँ। toy project hosting और deployment method कैसे चुनते हो, यह जानने की इच्छा है
  • मैं भी यह महसूस करता हूँ कि AI boilerplate वाले हिस्से और test automation code बना देता है, इसलिए ऐसे personal projects की गति सच में बढ़ जाती है

• toy software development कुछ वैसा है जैसे cycle, car, या boat की maintenance। मज़ेदार। लेकिन office जाने वाली cycle ठीक करना stress देता है। toy software बनाना मज़ेदार है, मगर जैसे ही कभी उसे सच में इस्तेमाल करना चाहो, सारे bugs दिखने लगते हैं और उन्हें ठीक करने का समय नहीं होता—यही दुविधा है

  • मुझे अपने इस्तेमाल के लिए software बनाना ज़्यादा पसंद है। कार में भी मेरा संतोष इसी में है कि उसे सस्ते में लंबे समय तक चलाऊँ
  • एक समय मैं अपना email server खुद चलाता था, अब नहीं चलाता। इसलिए नहीं कि मैं करना नहीं चाहता था, बल्कि अब लगता है यह काम experts को ही देना बेहतर है
  • हाल में मैंने अपना invoice application बनाया। ज़रूरत के अनुसार features एक-एक करके जोड़ना मज़ेदार था। उसमें वे features भी शामिल कर दिए जिनके लिए existing paid services में monthly subscription देना पड़ता है, लेकिन जैसे ही सच में invoice भेजने का समय आया, समझ आया कि मेरे बनाए app में style, address input जैसी कितनी चीज़ें अभी सुलझानी बाकी हैं। आखिर में लगा कि cycle चलाने के मज़े और commute वाली cycle की practicality के बीच संतुलन चाहिए। समय के साथ शायद मज़ा और practicality एक-दूसरे के करीब आ सकते हैं
  • मैं भी बहुत-सी चीज़ों को “finished software” बनाना चाहता हूँ, लेकिन समय और ऊर्जा नहीं है। उबाऊ और दोहराव वाले काम भी बहुत हैं। फिर भी “AI output” को manage और curate करना भी कम काम नहीं है। अभी शुरुआती experiment का दौर है, इसलिए पता नहीं कुछ महीनों बाद भी यही राय रहेगी या नहीं
  • इसी वजह से personal homepage बनाना मुझे बहुत आनंद देता है। सचमुच उसे अपने playground की तरह इस्तेमाल कर सकता हूँ

• LLM को लेकर इतनी नकारात्मक राय देखकर हैरानी होती है। LLM जानकारी को spoon-feed कर देता है। जब कोई नया project शुरू करते हैं, तो स्वाभाविक है कि शुरुआत में सब कुछ पता नहीं होता। पूरी कोशिश करना, असफल होना, फिर पढ़ना, समझना कि क्यों नहीं हुआ, और नए तरीके से adjust करना—यही असली learning है। अगर सब कुछ पहले से जानकर सिर्फ tutorial follow करोगे, तो अलग-अलग approaches की limits और असली pros/cons कभी महसूस नहीं होंगे। उदाहरण के लिए, regex से parser बनाने की कोशिश करते हुए खुद discover करना कि recursive expressions को handle नहीं कर सकते, या complex structures और time complexity issues को हाथ से महसूस करना—यहीं सीख है। खुद optimized compiler बनाते हुए तरह-तरह की optimization tricks में अटकना आपको समझाता है कि real compilers वैसे design क्यों किए गए हैं। खुद layout engine लिखने पर ही width जैसे concept को सही तरह handle करने की मुश्किल समझ आती है। trial and error से सीखने से बेहतर अनुभव कम ही हैं। LLM अगर mistakes रोक भी दे, तो भी आशा है कि लोग important learning opportunities न खो दें

  • बहुत लोग कहते हैं कि LLM का इस्तेमाल नहीं किया तो पीछे रह जाओगे, लेकिन मुझे लगता है कि लंबे समय में LLM का कम इस्तेमाल करना उल्टा बड़ा फायदा दे सकता है

• मैंने भी computer graphics सीखने के लिए कई साल weekends और रातों में अनगिनत अजीब projects किए। एक पैसा नहीं कमाया, लेकिन उसी की बदौलत dream job मिली। कुछ प्रमुख कामों के links:

  • Tiny ray-tracer
  • 2D rigid-body simulator
  • Character animation system
  • Animation curve visualizer
  • Motion capture playback in the web इस पूरे code के पहाड़ का असली मकसद सिर्फ “ज्ञान अर्जन” था

• इस लेख में जो “programming की खुशी” वाली भावना है, वह सच में ज़रूरी लगती है। AI agent coding के दौर में तो और भी कीमती। लेकिन लेखक ने toy projects के लिए जो estimated time दिया है, वह मुझे बहुत कम लगता है। मैं औसत गति वाला भी नहीं हूँ, फिर भी मुझे लगता है कि सूची के ज़्यादातर projects, अगर मान लें रोज़ सिर्फ 2–3 घंटे काम हो, तो कुछ दिनों में खत्म होने वाले नहीं हैं। शुरू करने से पहले research में ही अच्छा-खासा समय चला जाता है। उदाहरण के तौर पर, हाल में मैंने अपने Pelican blog को personal Odin static site generator से replace किया, और रोज़ 2–3 घंटे देकर भी 2 हफ्ते लग गए। जबकि वह सूची के कई दूसरे projects से आसान था

  • तुम्हारा project “toy” project से आगे निकल चुका है। तुम खुद असली customer बन चुके हो, और deploy होने के बाद भी उसके सही से काम करने की उम्मीद रखते हो। वही उम्मीद toy और real tool के बीच की सीमा है। एक घंटे में word processor भी बनाया जा सकता है—शायद इतना absurdly simple कि हर input को बस अलग-अलग संभाले, exit button भी न हो। लेकिन toy word processor के तौर पर वह फिर भी पर्याप्त है
  • अगर “X दिन” के time estimate को 24*X घंटे समझो, तो यह सूची काफ़ी plausible लगती है
  • toy project का एक फायदा यह है कि उसकी कोई deadline नहीं होती। इसलिए आराम से, धीरे-धीरे आगे बढ़ा जा सकता है। मैं भी PEG-आधारित Turing-complete language को COVID के समय से अब तक polish कर रहा हूँ
  • समय कितना लगेगा, इसमें बहुत फर्क पड़ता है कि आपने कहाँ तक 3rd-party libraries इस्तेमाल कीं, क्या खुद बनाया, और कितना सिर्फ core पर फोकस किया। लेखक का GitHub (https://github.com/ssloy?tab=repositories) देखो तो scale छोटा रखने की बहुत tips मिलती हैं। और लेखक की problem domain पर पकड़ पहले से बहुत गहरी है, इसलिए वह इतनी “tight” coding कर पाता है। नया subject हो तो इस तरह implement करना मुश्किल है

• “ऐसे projects में LLM का इस्तेमाल मत करो” वाली सलाह से मैं सहमत हूँ, लेकिन इसे बहुत extreme तरीके से न लेने के पक्ष में हूँ। AI से मदद कैसे लेनी चाहिए, इस पर सलाह का इंसानों से मदद माँगने वाली सलाह से अलग महसूस होना भी दिलचस्प है। अगर ब्लॉग के नीचे लिखा हो, “अगर आपका कोई programming में अच्छा दोस्त है तो उससे कभी मदद मत माँगो,” तो अजीब लगेगा। Expert दोस्त context समझता है और आपको खुद हल निकालने में मदद करता है। AI से भी शायद बहुत कम लोगों ने सच में कहा होगा, “मेरे लिए problem solve मत करो, expert दोस्त की तरह guide करो।” हो सकता है अभी वह इसमें कमज़ोर हो, लेकिन 1–2 साल में इस तरह का guidance बहुत natural हो जाए। इसलिए “मुझे किस तरह की मदद चाहिए” यह साफ़-साफ़ बताने की आदत अच्छी रहेगी। यह तय धारणा बनाने की ज़रूरत नहीं कि LLM सिर्फ गलत answers ही देगा

  • मुझे साफ़ लगता है कि AI अभी expert developer नहीं है
  • LLM को expert दोस्त की तरह इस्तेमाल करना मेरा सबसे आम तरीका है। उसे भरोसेमंद बनाने के लिए prompt या सवाल को खुद भी unbiased बनाना पड़ता है। हाल में Claude और ChatGPT मेरे विचारों से बहुत ज़्यादा सहमत होने की प्रवृत्ति दिखा रहे हैं
  • (लेखक) सच कहूँ तो मैं तो वास्तव में यह भी कहूँगा कि “expert दोस्त से भी मदद मत माँगो।” सिर्फ तब, जब पूरी तरह अटक जाओ, उस विषय पर थोड़ी-सी relevant literature पढ़ लेना बेहतर है। मैं गहराई से मानता हूँ कि खुद कई तरीकों से कोशिश करना, ठोकरें खाना और रास्ता निकालना—यही creativity और problem-solving skill बढ़ाने के लिए ज़रूरी है। वह confused रहने वाला समय भी ज़रूरी है। हालांकि अंततः यह हर किसी का अपना फैसला है
  • मैं सच में LLM से “teacher” की तरह सवाल पूछता हूँ। उससे intern की तरह जवाब नहीं माँगता

• Claude-आधारित vibe coding की वजह से मैंने बहुत लंबे समय बाद फिर से मज़ेदार side projects शुरू किए हैं। Tools और process समझने के बाद, कुछ ही हफ्तों में मैं family calendar/weather dashboard, Bluesky reading app (पहले से पढ़ी posts छिपाने वाला), gamified company PM dashboard, कुछ समय बाद Reddit posts छिपाने वाला Chrome extension, और maintain न किए जा रहे WordPress plugin का replacement app जैसी कई apps तेज़ी से बना रहा हूँ। शुरुआत में मैंने UI improvements वगैरह के लिए Claude पर बहुत भरोसा किया, लेकिन अब 90% completeness पर संतुष्ट रहना और polishing के बजाय नए app features पर ध्यान देना सीख लिया है

  • Claude कभी-कभी bug fix करके भी updated result तुरंत नहीं दिखाता, जिससे काफ़ी परेशानी होती है। एक fix के बाद updated output दिखाने के लिए मुझे 6 बार तक दोबारा कहना पड़ा। क्या किसी और का भी ऐसा अनुभव रहा है?

• यह सूची सच में प्रभावशाली है। लेखक को आसान लगने वाले कई projects मेरे लिए बहुत कठिन होंगे। फिर भी यह मुझे अपने toy projects फिर से शुरू करने की प्रेरणा ज़रूर देती है। बस LLM और learning पर निकला निष्कर्ष थोड़ा अधिक nuanced है। यह पूरी तरह इस बात पर निर्भर है कि आप उसे कैसे इस्तेमाल करते हैं। जैसे “इस problem को बस implement कर दो” कहना learning के लिए सबसे बुरा है, लेकिन “ELF की structure को बहुत उच्च स्तर की abstraction में, ‘क्यों’ पर फोकस करते हुए समझाओ” कहना उल्टा जबरदस्त learning accelerator हो सकता है। हर बार खुद research न करने लगना एक downside हो सकता है, लेकिन अगर आप सच में intellectually engaged हों, तो किसी भी समय Socratic Q&A मिल जाना बहुत बड़ा learning boost है

  • (लेखक) यही तो वह “विशिष्ट प्रकार की learning” है जिसका मैंने मुख्य लेख में ज़िक्र किया था। उदाहरण के लिए, ELF binary structure को सिर्फ अनुमान लगाकर नहीं सीखा जा सकता। उसके लिए history और decision-making process जानना पड़ता है, इसलिए specs, docs, यहाँ तक कि LLM भी reference material के रूप में काम आते हैं। लेकिन मूल बात “constructive learning by building” है। खुद binary format बनाते हुए ठोकर खाना, उसी exploration के दौरान आपको ELF जैसे वास्तविक formats के कारण, समस्याएँ और पूरे design space की समझ देता है। इस तरह की exploratory learning में मैं LLM की मदद न लेने की सलाह दूँगा। “अगर मुझे सिर्फ laptop, text editor, और compiler देकर 10 साल के लिए छोड़ दिया जाए, तो मैं कहाँ तक बना सकता हूँ? कहाँ ऐसी दीवार आएगी जहाँ specific information चाहिए होगी?”

• यहाँ बताए गए projects अच्छे ideas हैं, लेकिन मुझे उनमें से कोई भी दिलचस्प नहीं लगता। ऐसे समय मैं सोचने लगता हूँ कि क्या मुझे सच में कभी programming पसंद थी भी?

  • मैं शायद तुम्हारा उल्टा हूँ। सूची के ज़्यादातर projects मुझे दिलचस्प लगे, और उनमें से कुछ तो ऐसे हैं जिन्हें मैं आज़माना चाहता हूँ या किसी को करते देखना चाहता हूँ। सच कहूँ तो हाल तक मैं भी यही सवाल पूछ रहा था। फिर बच्चा होने के बाद parental leave पर मैंने सच में मज़े के लिए एक “simple” coding project शुरू किया। मैंने तय किया कि सारी dependencies हटाकर सब कुछ शुरुआत से खुद बनाऊँगा, और नतीजा यह हुआ कि चीज़ें सोचे से कहीं ज़्यादा complex हो गईं। लेकिन शायद उसी वजह से, वे कुछ घंटे की coding sessions इतने ज़्यादा इंतज़ार लायक लगने लगे। अचानक coding फिर बहुत मज़ेदार लगने लगी। संभव है कि आप burnout से गुजर रहे हों