कोड को खुद टाइप करें

• कोड को खुद टाइप करना और उसे याददाश्त से फिर से बनाना, copy करने की तुलना में समझ और याददाश्त की कहीं अधिक सख्त जाँच करता है
• Freecoding वह क्षमता है जिसमें syntax, type और नामों को दिमाग में रखते हुए character-level पर कोड लिखा जाता है, और यह tools के युग में भी ज़रूरी है
• Syntax high-level सोच में बाधा डालने वाला शोर नहीं है, बल्कि सटीक अर्थ को संक्षेप में समेटकर और ऊँचे स्तर की सोच को संभव बनाता है
• Type और schema को केवल ढीले-ढाले ढंग से देखकर काम चलाने पर system design धुंधला हो जाता है, और type model को न समझने पर as any जैसे बचाव बढ़ जाते हैं
• नाम याद रखना और पहले से मौजूद काम को समझना न हो तो agents आसानी से duplicate implementation बना देते हैं, और output व tests की समीक्षा भी कठिन हो जाती है

---

कोड को खुद टाइप क्यों करना चाहिए

• Zed Shaw के “Learn X the hard way” course में उदाहरणों को copy-paste न करके खुद टाइप करने की सलाह दी गई थी, और हाल में यह और ज़ोर देकर कहा गया कि अभ्यास पूरा करने के बाद उसे मिटाकर याददाश्त से फिर से बनाओ
• किसी चीज़ को सक्रिय रूप से पैदा करने पर, उसी चीज़ को निष्क्रिय रूप से ग्रहण करने की तुलना में समझ बेहतर होती है; cognitive psychology में इसे generation effect कहा जाता है
• Richard Feynman के “मैं जो बना नहीं सकता, उसे समझता नहीं” वाले कथन की तरह, याददाश्त के आधार पर कोड को फिर से बनाने का अभ्यास समझ और स्मृति दोनों की एक साथ परीक्षा लेता है
• agent coding के युग में इसका मतलब यह नहीं कि development tools का उपयोग नहीं करना चाहिए, लेकिन कभी-कभी tools की सुविधा के बिना character-level पर कोड लिखने की क्षमता भी विकसित करनी चाहिए
• ऐसे अभ्यास का फोकस syntax, type और नाम जैसे programming के बुनियादी विवरणों को दिमाग में बनाए रखते हुए “freecoding” करने की क्षमता विकसित करना है

Freecoding और दिमाग के भीतर का सूक्ष्म ज्ञान

• Freecoding वह क्षमता है जिसमें आप याददाश्त के आधार पर सीधे कोड लिख सकते हैं, और इसके लिए syntax, type और नाम जैसे मूल तत्वों को दिमाग में बनाए रखना ज़रूरी है

• Syntax और structure

  • keywords, punctuation और language constructs से परिचित होना चाहिए
  • यह केवल grammar रटने की बात नहीं, बल्कि कोड के रूप को सटीक रूप से याद कर पाने की क्षमता से जुड़ा है

• Type और schema

  • type system और data model से गहरी परिचितता और सहजता होनी चाहिए
  • अगर आप project की tables, columns, relations और type structure को हर बार सिर्फ देखकर ही समझते हैं, तो system-level design करना कठिन हो जाता है

• नाम

  • functions, methods, classes, imports, files और packages के नाम सटीक रूप से याद आने चाहिए
  • project और dependencies बदलें तो इस ज्ञान को भी साथ-साथ अद्यतन रखना चाहिए
  • यदि आप दिमाग में बने कोड को एक निश्चित स्तर की सटीकता के साथ टाइप नहीं कर सकते, तो असल में आप उसे स्पष्ट रूप से समझते नहीं, बल्कि केवल यह मानते हैं कि समझते हैं
  • English, code जितनी सटीक भाषा नहीं है; और पर्याप्त रूप से विस्तृत specification अंततः code के क़रीब पहुँच जाती है—यह बात अलग लेख A sufficiently detailed spec is code से भी जुड़ती है

Syntax high-level सोच को संभव बनाता है

• IDE या coding agent syntax को सही कर सकते हैं, फिर भी syntax को सीधे संभालने की क्षमता अब भी महत्वपूर्ण है
• यदि आपको parentheses मिलाने में कठिनाई होती है, तो यह सवाल उठ सकता है कि क्या आप किसी और के logical premises और conclusions को भी fluently जोड़ पाते हैं
• विवरणों को नज़रअंदाज़ करने का रवैया, शब्दों के अर्थ को स्पष्ट रूप से परखने के बजाय माहौल के आधार पर संवाद करने वाली functional illiteracy से जुड़ सकता है
• LLM prompt के उदाहरण ऊपर-ऊपर से ठीक लगते हैं, लेकिन ध्यान से पढ़ने पर उनमें एक-दूसरे के विपरीत निर्देश साथ-साथ मौजूद होते हैं
  • “ऊपर सूचीबद्ध skills में शामिल नहीं किसी बाहरी tool या alternative का सुझाव मत दो”
  • “यदि काम उपलब्ध skills से परे क्षमता माँगता है, तो ऐसा कहो”
• छोटी grammar, spelling और structure को सटीक रूप से संभालने की क्षमता और बड़ी तस्वीर को सही ढंग से समझने की क्षमता अलग-अलग नहीं हैं
• Syntax high-level सोच में बाधा डालने वाला विवरण नहीं, बल्कि ऊँचे स्तर की सोच को संक्षेपित और संभव बनाने वाला मानसिक tool है
• natural language explanation की तुलना में type notation अधिक सटीक और संक्षिप्त हो सकती है

  x ऑब्जेक्ट्स की एक array है, और हर ऑब्जेक्ट में strings को रखने वाला आवश्यक domain property और numbers को रखने वाला वैकल्पिक port property है
  

  x : { domain: string, port?: number }[]
  

Type और schema system design के मुख्य संकेत हैं

• Fred Brooks ने The Mythical Man-Month में कहा था कि यदि आप tables दिखा दें, तो अक्सर flowchart के बिना भी structure स्पष्ट हो जाता है
• यदि आप database इस्तेमाल करते हैं, तो project की tables, column names और relations आपको अच्छी तरह याद होने चाहिए
• इस जानकारी को ज़रूरत पड़ने पर ढीले-ढाले ढंग से देखने के बजाय पहले से समझकर दिमाग में रखना, प्रभावी system-level design के लिए ज़रूरी है
• ऐसा प्रयास न करने पर, सोच जितनी उलझी होगी, database schema भी उतना ही duplicate या मिलते-जुलते data से भरा denormalized structure बन सकता है
• Rust या Haskell जैसी strongly typed languages का अनुभव, types के मज़बूत mental model के लाभ को अच्छी तरह दिखाता है
• एक सटीक “mental type checker” या “mental borrow checker” विकसित करने का अभ्यास, weakly typed languages का उपयोग करते समय भी मदद करता है
• यदि आप इस तरह की abstract reasoning की muscle का उपयोग नहीं करते, तो invalid states को unrepresentable बनाना जैसी data modeling की बुनियादी बात भी आसानी से छूट सकती है
• यदि types आपस में कैसे फिट होते हैं यह समझ नहीं आता, तो TypeScript code में as any इधर-उधर छिड़कने लगते हैं
• यदि normal path में types के बारे में सोचने की असुविधा नहीं झेल सकते, तो type errors को debug करने वाला abnormal path और भी कठिन लगेगा
• इसका मतलब यह नहीं कि Haskeller या Rustacean हमेशा बेहतर code लिखते हैं, लेकिन बाकी शर्तें समान हों तो types में fluency मददगार होती है

नाम याद हों तभी reuse संभव है

• project या dependency में अक्सर इस्तेमाल होने वाले functions, methods, classes, imports, packages और files के नाम आसानी से याद आने चाहिए
• यह पहले से बने हुए, यानी prior art से परिचित होने के अधिक सामान्य सिद्धांत का एक विशेष रूप है
• बहुत से लोग coding agents पर इसलिए निर्भर होते हैं क्योंकि उन्हें ऐसा reusable prior art पता नहीं होता जो पहले से उनकी चाही गई functionality करता हो; नतीजतन वे agent से पहिया दोबारा बनवाते हैं
• यदि आपको SaaS boilerplate projects के अस्तित्व का पता नहीं है, तो आसानी से लग सकता है कि agent को सब कुछ scratch से scaffold करना होगा
• इस उद्देश्य के लिए बने और परखे हुए open source projects को clone करना, उसी काम के लिए agent से कहने की तुलना में अधिक तेज़, सस्ता और भरोसेमंद हो सकता है
• जब कोई यह भविष्यवाणी करता है कि कुछ वर्षों में LLM पूरा browser बना सकेगा, तो इसका जवाब यह हो सकता है कि Chromium को fork करके यह आज ही संभव है, और उसे modify व maintain करना भी आसान है
• उसी project या company के भीतर code reuse के लिए भी नाम याद रखना महत्वपूर्ण है
• अगर आपको यह ही नहीं पता कि क्या खोजना है, तो आप सहकर्मियों के काम पर आगे निर्माण नहीं कर सकते

Agent output की समीक्षा के लिए मानवीय समझ ज़रूरी है

• agents नाम खोजने और code generation में मदद कर सकते हैं, लेकिन अब नया प्रश्न यह है कि क्या आप उनके output की अर्थपूर्ण समीक्षा कर सकते हैं
• यदि आपको existing functionality का पता नहीं है, तो यह तय करना कठिन होगा कि agent feature को duplicate implement कर रहा है या नहीं
• यदि आपकी code समझ agent से भी कमज़ोर है, तो उसके output की quality की ठीक से समीक्षा करना भी मुश्किल है
• आप agent से tests बनवाने को कह सकते हैं, लेकिन यदि बने हुए tests को ध्यान से नहीं देखते, तो test खुद ही अर्थहीन code बन सकता है
• एक वास्तविक उदाहरण में test implementation code को call ही नहीं करता था, बल्कि arrays और strings पर सीधे some या includes लगाकर केवल expected value की पुष्टि कर रहा था

  describe("abort detection logic", () => {
    it("detects aborted stopReason in messages", () => {
      const messages = [
        { role: "assistant", stopReason: "aborted", content: [] },
      ];
      const isAborted = messages.some((m: any) => m.stopReason === "aborted");
      expect(isAborted).toBe(true);
    });
  
    it("detects abort in error string", () => {
      const error = "The operation was aborted";
      const isAborted = error.includes("abort");
      expect(isAborted).toBe(true);
    });
  
    it("does not false-positive on normal errors", () => {
      const error = "Network timeout";
      const isAborted = error.includes("abort");
      expect(isAborted).toBe(false);
    });
  
    it("does not false-positive on normal stop reasons", () => {
      const messages = [
        { role: "assistant", stopReason: "stop", content: [] },
      ];
      const isAborted = messages.some((m: any) => m.stopReason === "aborted");
      expect(isAborted).toBe(false);
    });
  });
  

• software development में रोज़मर्रा की रुकावटें बहुत होती हैं, और यदि आप नाम याद रखने जैसी छोटी रुकावट भी पार न करने का चुनाव करते हैं, तो tests की समीक्षा जैसी बड़ी रुकावट भी पार नहीं करेंगे
• coding agents उपयोगकर्ता के निर्देशों को मुख्य context मानते हैं, इसलिए बौद्धिक रूप से आलसी उपयोगकर्ता agent को भी उसी तरह की आलसी दिशा में धकेल सकता है

धैर्य और कौशल अलग नहीं हैं

• Eustress लाभकारी तनाव है; जब आप खुद को नई और कठिन चीज़ें करने के लिए आगे बढ़ाते हैं, तो छोटी असुविधाओं के प्रति सहनशीलता बनती है और बड़ी असुविधाएँ भी पार की जा सकती हैं
• यदि आप हमेशा असुविधा से बचते हैं, तो असहायता और निराशा का एक दुष्चक्र गहराता जाता है
• एक क्षेत्र में सटीकता, स्मृति और संरचनात्मक सोच विकसित करने से दूसरे क्षेत्रों की क्षमता भी साथ में सुधरती है
• जैसे LLM training data से generalize करता है, वैसे ही मनुष्य भी एक क्षेत्र में विकसित आदतों और क्षमताओं को दूसरे क्षेत्रों में generalize करता है
• software development का स्वभाव ही ऐसा है कि उसमें नियमित रूप से comfort zone से बाहर जाना शामिल है, और यह संबंधित लेख Software engineers are not (and should not be) technicians के उसी संदर्भ से जुड़ता है

[GN⁺]

Lobste.rs की राय

• पूरी तरह सहमत हूँ। अभ्यास प्रश्न खत्म करने के बाद जो अभी किया है उसे मिटाकर सिर्फ याददाश्त से फिर से करना वाकई बहुत महत्वपूर्ण है
  अगर अटकें तो संकेत देख लें, लेकिन अभी-अभी किए गए काम को जितना हो सके याद से दोबारा बनाने की आदत जितनी ज़रूरी है, उतनी कम चीज़ें हैं

• commit messages और documentation सीधे खुद टाइप करना बेहतर है
  प्रोग्रामर अक्सर इस तरह की writing पसंद नहीं करते, इसलिए आसानी से कहते हैं, “LLM से लिखवा लो।” लेकिन जब आप खुद लिखते हैं, तो user experience और implementation decisions एक ही जगह सामने आते हैं। “X करने के लिए -Y पास करना होता है… एक मिनट, क्या यही सबसे अच्छा तरीका है?” “यह Y से X को ठीक करता है… लेकिन क्या Z से भी नहीं हो सकता?” जैसी समीक्षा होने लगती है

  • इसे अक्सर tutorial-driven development कहा जाता है। बाद में user experience के बारे में सोचने के बजाय, आप जिस user experience को चाहते हैं उससे शुरू करते हैं, tutorial लिखते हैं, और फिर उल्टी दिशा में काम करते हैं

• “अगर आपको parentheses का balance मिलाना मुश्किल लगता है, तो इस पर शक होता है कि आप किसी और की logical premises और conclusions को कितनी fluently जोड़ पाएँगे” वाली बात पर हँसी भी आई, और थोड़ी चुभन भी हुई
  सफाई में इतना कहूँगा कि कभी-कभी functions बहुत ज़्यादा बड़े हो जाते हैं

• जिस vibe coding कचरे को आप समझते नहीं हैं, उसे ठीक करना भी वास्तव में सीखने का अच्छा तरीका है। इसमें बहुत typing होती है, और आप निर्वात में नहीं बल्कि असली context में काम करते हैं

  • हाल में मैंने vibe coding से कुछ ऐसा बनाया जो किसी हद तक चलता था, लेकिन अच्छा नहीं था, और code सचमुच बेतरतीब था
    उसे हाथ से दोबारा लिखते हुए मैंने इसे पिछले 8 महीनों में जंग खा चुकी अपनी programming sense को फिर से तेज़ करने का मौका बनाया। rewritten नतीजा मुझे पसंद आया और वह वास्तव में बेहतर चलता है। LLM अब भी समझाने या अटके हुए हिस्से खोलने में उपयोगी है, लेकिन यह महसूस होना कि पूरी codebase मुझे पता है, कहीं बेहतर है
  • यह case पर depend करता है। कभी-कभी सूअर पर दोबारा lipstick लगा दें, तब भी वह आखिर सूअर ही रहता है

• “सूचीबद्ध capabilities में न होने वाले किसी external tool या alternative का कभी सुझाव मत दो। अगर काम के लिए उपलब्ध capabilities से बाहर की functionality चाहिए, तो यह कहो” — मुझे समझ नहीं आता कि यह prompt परस्पर विरोधी निर्देश क्यों हैं
  “दी गई capabilities से मैं यह नहीं कर सकता” कहना दोनों निर्देशों के साथ सुसंगत है। अगर आखिरी वाक्य यह होता कि “कौन-सी capability चाहिए, यह बताओ”, तब टकराव होता, लेकिन मौजूदा वाक्य में मुझे विरोधाभास नहीं दिखता

  • यह सही व्याख्या लगती है, लेकिन संभव है कि prompt लिखने वाले की मंशा यह रही हो कि LLM सिर्फ “माफ़ कीजिए, दूसरी capability चाहिए लेकिन मैं बता नहीं सकता” न कहे, बल्कि क्या चाहिए यह भी बताए। बेशक, यह भी हो सकता है कि उनका मतलब सचमुच वही रहा हो जो वाक्य में लिखा है
  • मेरे हिसाब से “दी गई capabilities से यह नहीं किया जा सकता” वाला जवाब दूसरे निर्देश के साथ सुसंगत नहीं है
    दूसरा वाक्य इस तरह पढ़ा जाता है कि मॉडल ज़रूरी external tools या alternatives के अस्तित्व को नकारात्मक ढंग से इशारा न करे, बल्कि रचनात्मक रूप से उनके अस्तित्व की पुष्टि करे

• “जो लोग किसी चीज़ को functional clarity के साथ व्यक्त नहीं कर पाते, वे लगभग बिना अपवाद spelling या grammar की दृष्टि से सही वाक्य भी नहीं लिख पाते” — यह बात dyslexia वाले लोगों या बस अलग तरह से सोचने वालों के प्रति काफ़ी कठोर पूर्वाग्रह जैसी लगती है
  बेशक, यह नहीं कहा गया कि spelling या grammar न आना सीधे functional clarity की कमी के बराबर है, लेकिन किसी भी तरह से कहें तो यह बहुत उदार phrasing नहीं है
  इसे ज़्यादा रचनात्मक ढंग से देखें तो node editors के बारे में सोचा जा सकता है। node-based systems में मौजूदा implementations के साथ बहुत समस्याएँ हैं, लेकिन अगर उन्हें अच्छी तरह बनाया जाए, तो वे program लिखने के तरीके को नियंत्रित करके कुछ syntax errors को शुरू से ही रोक सकते हैं। उदाहरण के लिए, अगर कोई node string लेता है, तो उसमें number नहीं दिया जा सकता। ऐसा build time या runtime पर constraint लागू करके नहीं, बल्कि इसलिए कि उस जगह number को “कहा” ही नहीं जा सकता। गलत loop ranges, argument count errors, parentheses imbalance जैसी चीज़ों को भी संरचना के स्तर पर असंभव बनाया जा सकता है
  अगर आप software ऐसे tool से लिखते हैं जो कुछ constraints को संरचनात्मक रूप से लागू करता है, तो इसका मतलब यह नहीं कि आप उन constraints को समझते नहीं। इसका बस इतना मतलब है कि उस तरह की errors में गलती से गलत input देने की चिंता कम हो जाती है। और अगर function की braces की गिनती या logical blocks की indentation जैसी syntax details को tool अपने-आप संभाल न रहा हो तो उससे झुंझलाहट महसूस होने का मतलब यह भी नहीं कि आप नहीं समझते कि इन syntax बातों पर ध्यान देना क्यों ज़रूरी है
  मैंने node systems का उदाहरण इसलिए दिया, क्योंकि वे LLM वाले “फेंको और भूल जाओ” या दिमाग बंद करके vibe coding करने वाले तत्व को हटाकर सिर्फ syntax problems को अलग करके दिखाते हैं। LLM को हटा दें तो syntax पर केंद्रित यह तर्क काफ़ी कमज़ोर हो जाता है
  बाकी लेख से मैं सहमत हूँ, लेकिन syntax skill को किसी की code समझने की क्षमता या अच्छा code लिखने की क्षमता का बुनियादी संकेतक मानना मुझे बहुत गलत दिशा लगता है

  • मेरा मतलब यह नहीं था कि जो spelling या grammar की दृष्टि से सही वाक्य नहीं लिख पाते, वे functional clarity भी नहीं रख सकते
    मैं समझता हूँ कि यह सद्भावना से दी गई प्रतिक्रिया है, और मैं रक्षात्मक नहीं दिखना चाहता। मुझे लगा था कि मैंने इसे इस तरह कहने की कोशिश की है कि यह ऐसी कठोर और गैर-उदार बात न लगे, लेकिन अगर इसी बात को बेहतर ढंग से कहने के लिए कोई और phrasing या संरचना हो, तो मैं उसके लिए तैयार हूँ
    फिर भी, मैं उस बिंदु को पूरी तरह हटाना नहीं चाहूँगा। जो मुख्य बात मैं कहना चाहता हूँ, वह यह है कि जब कोई व्यक्ति मानसिक असुविधा से अनुभवात्मक परिहार के ज़रिए बचना शुरू करता है, तो आमतौर पर सबसे पहले spelling और grammar ही टूटते हैं। मुझे लगता है कि इस दावे को इस तरह समायोजित किया जा सकता है कि dyslexia वाले लोगों को इस प्रक्रिया में नुकसान न हो