कंप्यूटर कोडिंग से भी कठिन है इंसानों के लिए कोडिंग

 (erikbern.com)
1 पॉइंट द्वारा GN⁺ 2024-09-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डेवलपर टूल बनाना इसलिए अधिक कठिन है क्योंकि इसमें सिर्फ वह logic डिज़ाइन नहीं करना होता जिसे कंप्यूटर चलाएगा, बल्कि वह mental model भी बनाना होता है जिसे दूसरे लोग समझें और इस्तेमाल करें
  • तेज़ onboarding कोई अतिरिक्त सुविधा नहीं, बल्कि लगभग खुद product है; setup, API token, और पहली run की friction इतनी कम होनी चाहिए कि उपयोगकर्ता कुछ ही मिनटों में अपने laptop पर इसे आज़मा सके
  • उपयोगकर्ता लंबे core concepts विवरणों से ज़्यादा काम करने वाले examples बदलकर pattern सीखते हैं, और जितने अधिक problem के क़रीब starting points होंगे, सफलता की संभावना उतनी बढ़ेगी
  • error messages, concepts की संख्या, naming, configuration का तरीका, defaults, magic, और syntax sugar — ये सब उपयोगकर्ता की सफलता की राह बदलते हैं, इसलिए पढ़ने में आसान और customize किए जा सकने वाले design की ज़रूरत होती है
  • अच्छा developer experience सिर्फ features कम करना नहीं है, बल्कि जो बनाया जा सकता है उसकी सीमा बनाए रखते हुए समझने लायक complexity को बहुत कम करना है

इंसानों के लिए लिखा गया कोड mental model तक संभालता है

  • कंप्यूटर के लिए कोड लिखना बड़े business goals को logical statements में तोड़ना है ताकि कंप्यूटर उनका पालन कर सके
  • framework, library, API, SDK, DSL, embedded DSL, और programming language जैसे code, जिन्हें इंसान सीधे इस्तेमाल करते हैं, उनके लिए सिर्फ executable होना काफ़ी नहीं है
  • ऐसे code को कंप्यूटर को निर्देश देने के साथ-साथ यह भी संभालना पड़ता है कि उपयोगकर्ता उसे कैसे पढ़ेंगे और समझेंगे
  • developer tools का design करने में सिर्फ computer science नहीं, बल्कि उपयोगकर्ता कैसे तर्क करते हैं इसकी मनोवैज्ञानिक समझ भी चाहिए

शुरुआती अनुभव ही product है

  • developer tools पर feedback आमतौर पर उन power users से ज़्यादा मिलता है जो product को बार-बार इस्तेमाल करते हैं
  • जो उपयोगकर्ता शुरुआत में ही अटक जाते हैं, वे feedback नहीं छोड़ते, इसलिए survivorship bias पैदा होता है
  • जैसे consumer products onboarding funnel को optimize करते हैं, वैसे ही developer tools को भी first run तक पहुँचने की प्रक्रिया को product का core मानना चाहिए
  • तेज़ onboarding के लिए product की संरचना बदलना भी उचित हो सकता है
    • ज़रूरी configuration हटाना
    • API token setup को बेहद आसान बनाना
    • शुरुआती friction कम करना
    • उपयोगकर्ता को कुछ ही मिनटों में अपने laptop पर product चलाकर देखने देना
  • ऐसे माहौल में जहाँ developer tools बहुत ज़्यादा हो गए हैं, उपयोगकर्ताओं के पास किसी खास LRU cache NPM package के फ़र्क को गहराई से समझने की न ऊर्जा होती है, न धैर्य

examples, core concepts से तेज़ सिखाते हैं

  • इंसान, कंप्यूटर की तरह सख़्त निर्देशों का पालन करने के बजाय, pattern matching में मज़बूत होते हैं
  • कई developer tool docs पहले core data model, relations, atomic concepts, configuration, और execution समझाते हैं, लेकिन इंसान काम करता हुआ example बदलकर और नतीजा देखकर बेहतर सीखते हैं
  • 5,000 शब्दों वाली “core concepts” व्याख्या से कई examples ज़्यादा उपयोगी हो सकते हैं
    • उपयोगकर्ता examples देखकर tool का व्यवहार समझते हैं
    • जिनके पास हल करने के लिए कोई समस्या है, वे काफ़ी क़रीब का starting point ढूँढ़ सकते हैं
    • जितने ज़्यादा starting points होंगे, उतनी ही संभावना होगी कि उन्हें अपनी ज़रूरत के क़रीब example मिल जाए

उपयोगकर्ता को सफलता के गड्ढे में धकेलना

  • programming की default अवस्था अक्सर किसी न किसी तरह की errors ठीक करते रहना ही होती है
  • उपयोगकर्ता tool के साथ अपना ज़्यादातर समय यह समझने में बिता सकते हैं कि “क्या काम नहीं कर रहा”
  • जब developers जल्दी सफल होते हैं तो वे tool को पसंद करते हैं, लेकिन अगर वे लगातार errors में फँसे रहें तो tool को दोष देते हैं
  • हर error उपयोगकर्ता को happy path पर वापस लाने का एक मौका है
    • exception message में code snippet देना
    • जब उपयोगकर्ता कुछ अजीब करने वाले हों तब उपयोगी warnings दिखाना
    • उपयोगकर्ता को सफल होने के लिए ज़रूरी actions देना

concept overload कम करना

  • tool इस्तेमाल करने से पहले समझने पड़ने वाले हर नए concept एक friction point बन जाता है
  • 2–3 concepts स्वीकार्य हो सकते हैं, लेकिन 8 नए concepts सीखने के लिए तैयार उपयोगकर्ता बहुत कम होंगे
  • Kubernetes में शुरुआत में हर concept की ज़रूरत नहीं होती, लेकिन जैसे-जैसे नए concepts बढ़ते हैं, बोझ भी बढ़ता है
  • ऐसे frameworks में एक तरह की सुंदरता होती है जो शक्तिशाली हों, फिर भी सिर्फ 3–5 concepts रखते हों
  • React को पहली बार इस्तेमाल करते समय, एक-दो घंटे बाद conceptual पहाड़ी पार करने पर यह एहसास हो सकता है कि कुछ सरल building blocks से बड़े structures बनाए जा सकते हैं
  • लक्ष्य सिर्फ concepts की संख्या घटाना नहीं, बल्कि क्या बनाया जा सकता है उसकी सीमा बनाए रखते हुए उपयोगकर्ता को समझने पड़ने वाले concepts कम करना है
  • बेहतरीन tools complexity को 90% तक कम करके भी capability को बरकरार रख सकते हैं
  • ऐसा tool भी बुरा नहीं जो complexity को 90% कम करे और capability को सिर्फ 10% घटाए

conceptual duck principle

  • अगर framework में कोई ऐसा element है जो values लेकर नई value निकालता है, तो उसे “compute node”, “valuator”, या “frobniscator” कहने के बजाय function कहना बेहतर है
  • अगर कोई चीज़ बत्तख की तरह चलती है और बत्तख की तरह आवाज़ करती है, तो उसके बत्तख होने की संभावना ज़्यादा है — यह सिद्धांत concept design पर भी लागू हो सकता है
  • भले ही उसमें कुछ सूक्ष्म अंतर हों या values cache होती हों, अगर वह function के काफ़ी क़रीब है तो उसे function कहा जा सकता है
  • मौजूदा terminology इस्तेमाल करने से उपयोगकर्ता के पास पहले से मौजूद mental model से जुड़ना आसान होता है और समझाने की ज़रूरत बहुत कम हो जाती है

इसे programmable बनाइए

  • उपयोगकर्ता codebase के साथ अनपेक्षित काम करते हैं, और framework elements को for-loop, function, या दूसरी structures के भीतर रख सकते हैं
  • इसलिए framework की लगभग हर चीज़ programmable होनी चाहिए
  • इससे जुड़ी design directions एक-दूसरे से जुड़ी हुई हैं
    • CLI से गुज़रे बिना code से सीधे call कर पाना
    • configuration files कम करके उन्हें SDK या API से बदलना
    • सिर्फ एक चीज़ बनाने तक सीमित न रखना, बल्कि parameterize करके n चीज़ें बनाने देना
  • ऐसा design उपयोगकर्ताओं को नए use cases खोजने में मदद कर सकता है
  • framework के ऊपर “hack” करने की इच्छा का उपयोग करने से थोड़ी उलझन ज़रूर हो सकती है, लेकिन इससे अप्रत्याशित खोजें भी हो सकती हैं

magic, defaults, और syntax sugar में सावधानी चाहिए

  • मान लीजिए cloud में Jupyter notebook चलाने के लिए run_notebook function है, और उपयोगकर्ता को यह बताना है कि कौन-सी container image इस्तेमाल करनी है
  • कई विकल्प संभव हैं
    • image=... argument को हमेशा required रखना
    • एक default image देना जिसमें ज़्यादातर data science libraries installed हों, और उपयोगकर्ता उसे override कर सके
    • cell के code को inspect करके ज़रूरी dependencies के आधार पर “magic” तरीके से image चुनना
    • magic तरीके के साथ-साथ उपयोगकर्ता को किसी खास image को चुनने की अनुमति देना
  • input कम करने और सबसे व्यापक use cases को support करने के लिए आख़िरी विकल्प अच्छा लग सकता है
  • लेकिन पहले विकल्प को छोड़कर बाकी में समस्याएँ रहती हैं
    • magic कुछ स्थितियों में टूटता है
    • defaults पर निर्भर code पढ़ने वाला उपयोगकर्ता शायद यह न समझ पाए कि customization संभव है
  • जब तक defaults 97% से ज़्यादा मामलों में सही न बैठें और magic 99% से ज़्यादा बार सही न हो, बहुत सावधान रहना चाहिए
  • coding golf नहीं है, और tool provider का काम सिर्फ यह नहीं कि उपयोगकर्ता को कम से कम code लिखना पड़े
  • Perl ने छोटे code के लिए बहुत optimization किया, लेकिन programs special characters की कतार जैसे लग सकते थे; Python में code 50% लंबा होने पर भी वह पढ़ने और समझने में आसान था
  • लोग code लिखने से 10 गुना ज़्यादा उसे पढ़ते हैं, इसलिए readability बहुत महत्वपूर्ण है
  • syntax sugar को भी इसी कसौटी पर परखना चाहिए
    • आम use cases के लिए special syntax डालने का मन हो सकता है
    • लेकिन इससे consistency कमज़ोर हो सकती है और customization का तरीका कम स्पष्ट हो सकता है
    • अगर syntax sugar 99% से ज़्यादा मामलों में लागू नहीं होता, तो शायद उसे जोड़ना ही नहीं चाहिए

पहली बार इस्तेमाल करने वालों के लिए design principles

  • इंसानों के लिए code लिखने में अभी भी कई design समस्याएँ बची हुई हैं
    • ज़्यादातर चीज़ें immutable होनी चाहिए, लेकिन सब कुछ नहीं
    • scaffolding, यानी code generation, से बचना
    • feedback loop को बेहद तेज़ बनाना
    • उपयोगकर्ता को deprecated features से आसानी से निपटने देना
    • docs और examples के code snippets पर automated tests चलाना
  • पहली user experience को design करना pop song बनाने जैसा है
  • producer भले ही गाना हज़ार बार सुन चुका हो, उसे 999वीं बार भी यह कल्पना करनी पड़ती है कि पहली बार सुनने वाले को यह कैसा लगेगा
  • developer tools में भी, जो व्यक्ति चीज़ को बार-बार बना चुका है, उसके लिए पहली बार इस्तेमाल करने वाले उपयोगकर्ता के अनुभव की कल्पना करना बहुत कठिन होता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-28
Hacker News राय

  • हर व्यक्ति का सीखने का तरीका अलग होता है। मुझे examples में जाने से पहले पहले मुख्य concepts चाहिए होते हैं। अगर मुख्य concepts बहुत सरल न हों, तो यह और भी ज़रूरी हो जाता है
    कई tutorials हाथ पकड़कर Lego जोड़ने जैसे होते हैं। अंदाज़ कुछ ऐसा होता है: “यहाँ Lego का टुकड़ा है, मैं एक toy project बनाता हूँ, तुम follow करो, और दिन खत्म होते-होते तुम्हें Lego करना आ जाएगा”
    यह तरीका मेरे लिए ठीक से काम नहीं करता। मैं जानना चाहता हूँ कि फैसले कैसे और क्यों लिए जाते हैं, और लेखक के नजरिए से देखना चाहता हूँ। मैं समझना चाहता हूँ कि Lego के हर टुकड़े का स्वभाव क्या है, वे आपस में कैसे जुड़ते हैं, और किसी खास design तक कैसे पहुँचा जाता है
    न्यूनतम high-level concept explanation के बिना tutorial follow करना ऐसा लगता है जैसे किसी ऐसी चीज़ की reverse engineering कर रहा हूँ जिसकी जरूरत नहीं होनी चाहिए। जब मैं कोई नई library या framework देखता हूँ, तो intro article पढ़ता हूँ और “getting started” code examples छोड़ देता हूँ। आम तौर पर “advanced” section में concepts पर ज्यादा चर्चा होती है, इसलिए वहीं से शुरू करता हूँ; फिर API reference देखकर महत्वपूर्ण interfaces समझता हूँ; और आखिर में tutorial की शुरुआत वाले basic code examples पर लौटता हूँ

    • पहले मुझे लगता था कि मैं “मुख्य concepts” वाला व्यक्ति हूँ, लेकिन बाद में समझ आया कि मैंने इसे बहुत आगे तक खींच दिया था। जब तक मुझे पहले से यह महसूस न हो कि मैंने सब कुछ सच में समझ लिया है, मैं अक्सर comfort zone के बाहर का काम करने से इनकार कर देता था
      आजकल मैं कहीं ज्यादा बार सीधे कूदकर examples पर काम शुरू कर देता हूँ, और मुझे लगता है कि मेरी productivity भी ज्यादा है। कुछ हद तक यह भरोसे का मामला है। भरोसा कि quality software बनाने वालों ने common use cases में internals को गहराई से खोदे बिना interface को समझने लायक बनाने के लिए पर्याप्त सोच-विचार किया होगा
      बेशक, अक्सर ऐसे blockers मिलते हैं जहाँ और गहराई में जाना पड़ता है। लेकिन ऐसी स्थिति इसलिए आती है क्योंकि सतही impression के आधार पर ही मैं 10 दूसरी चीजें सफलतापूर्वक पार कर चुका होता हूँ। इसलिए जब सच में गहराई में जाना पड़ता है, तब भी आम तौर पर उसे समय की बर्बादी नहीं मानता
    • पूरी तरह सहमत हूँ। शुरुआत में मुझे create-react-app जैसे “project generators” पसंद नहीं थे। यह सिर्फ एक उदाहरण है, और मुझे खुशी है कि मैंने React इसे आने से काफी पहले सीखा
      ऐसे tools एक खास folder structure, template files और पहले से configured tools बना देते हैं। अगर generated files क्या करती हैं और उन्हें वैसा क्यों बनाया गया है, इसका high-level समझ तुरंत न हो, तो बहुत ज्यादा अनसमझ magic होने की वजह से असहजता होती है
      जब भी कोई नई चीज़ आती है, मुझे एक high-level introduction चाहिए जो उसका उद्देश्य उन concepts से जोड़कर समझाए जिन्हें मैं पहले से जानता हूँ। कम से कम उस black box के मुख्य interface की मोटी समझ होने से पहले मैं किसी जादुई black box से निपटने में सहज नहीं होता। उदाहरण के लिए, अगर मैं शुरू से create-react-app सीखता, तो तुरंत Babel या ESLint जैसे उन tools के उद्देश्य की छानबीन शुरू कर देता जिन्हें वह configure करता है
    • मैंने उस तरह से कोशिश की है, और मुझे नहीं पता कि मैंने computer science की पढ़ाई ऐसे करके कैसे पास कर ली। मैं solutions reproduce कर सकता था, लेकिन उन्हें समझता नहीं था
      कई साल बाद, जब मैंने बहुत सारे अच्छे practical examples देखे, तब जाकर समझ आया कि concepts क्या कह रहे हैं। उस अहसास के बाद मैंने अपना सीखने का तरीका सुधारा
      पहले मुख्य concepts को सरसरी तौर पर देखता हूँ, फिर कई examples आज़माता हूँ जब तक यह समझ न आ जाए कि वे concepts क्यों जरूरी हैं, और फिर naive examples में छूटे edge cases हटाने के लिए मुख्य concepts को ध्यान से पढ़ता हूँ
    • मेरे साथ भी कुछ ऐसा ही है। Maven क्यों काम नहीं कर रहा, यह समझने की कोशिश करते समय भी मुझे यही समस्या हुई। मुझे “how to get started” tutorial नहीं, बल्कि basic principles चाहिए थे ताकि समझ सकूँ कि हो क्या रहा है
      हालांकि मुझे लगता है कि examples से शुरू करना अच्छे API design में मदद कर सकता है। अगर API को “मुख्य concepts पहले” के हिसाब से design किया जाए, तो अंत में अक्सर ऐसी API बनती है जिसे मुख्य concepts समझने के बाद ही इस्तेमाल किया जा सके, और यह कभी-कभार इस्तेमाल करने वाले users के लिए अच्छा नहीं होता
    • अच्छी तरह समझाया। खासकर “इंसान इस तरह नहीं सीखते” वाले वाक्य से ही शक शुरू हुआ
      hacker-style में कोई citation नहीं था। मैंने शिक्षा-शास्त्र थोड़ा ही देखा है, लेकिन यह एक विशाल और परिपक्व field है जो Dewey और Piaget की experiential psychology से आधुनिक principles खींचती है। इसमें कहने को इतना कुछ है जो एक blog post तो क्या, किसी blog post के एक section में भी समा नहीं सकता
      जैसा बताया गया, सबसे बड़ी समस्या यह है कि लोग अलग-अलग होते हैं। अगली बड़ी समस्या यह है कि हमें पक्का यह भी नहीं पता कि ये फर्क क्यों पैदा होते हैं, या समय के साथ कितने स्थिर रहते हैं। लेख खुद अच्छा लिखा गया है और किसी खास teaching strategy की व्यावहारिकता को अच्छे से खंगालता है, लेकिन इसमें थोड़ी और humility होती तो अच्छा होता

  • दो हफ्ते भी नहीं हुए थे कि ऐसा ही एक लेख था: https://news.ycombinator.com/item?id=41566097
    इंसानों के लिए लिखना आखिरकार दो skills में सिमटता है: empathy और writing
    थोड़ा-बहुत code लिखने और कोई application या product लिखने के बीच बड़ा फर्क है। यह लेख भी कम खुलकर सही, आखिर वही बात कर रहा है। empathy इसलिए अहम है क्योंकि वही self-centeredness और बाहरी नजरिए का फर्क बनाती है
    self-centered developer ज्यादातर आसानी, सुविधा, code vanity, और दूसरे subjective criteria में रुचि रखता है। आखिर में वह सिर्फ अपनी delivery effort को देखता है। बाहरी-उन्मुख developer मुख्यतः architecture और documentation में रुचि रखता है, क्योंकि वह सफलता को इस बात पर निर्भर मानता है कि दूसरे लोग उसके output को कैसे ग्रहण करते हैं
    simplicity, ease से ज्यादा महत्वपूर्ण है। क्योंकि बाहरी-उन्मुख developer दूसरों का मन नहीं पढ़ सकता और यह नहीं जान सकता कि उन्हें क्या आसान लगेगा, लेकिन वह steps की संख्या घटाना और code को छोटा रखना जानता है
    पूरे product के नजरिए से application लिखना, दिमाग के भीतर, essay, article या book लिखने से अलग नहीं है। मूल बात organization और function है। code बाद में आता है, जैसे page पर शब्द। जो लोग सिर्फ code snippets लिखते हैं, वे वह higher-level organizational skill विकसित नहीं कर पाते जो सब कुछ एक साथ जोड़ती है
    इसलिए मुझे frameworks से बहुत नफरत है। frameworks developers से वह practice छीन लेते हैं जो original software लिखने के लिए चाहिए, और नतीजतन वे organizational skills नहीं बढ़ा पाते। संबंधित व्यक्ति को यह दिखता नहीं, लेकिन जिसे दिखता है उसके लिए यह एक बहुत बड़ा और साफ gap है

    • बात सही है, और यह एक dilemma भी है। frameworks बनाने वाले लोग ऐसा इसलिए करते हैं ताकि दूसरे लोग products को आसानी से launch कर सकें। framework बनाने की प्रक्रिया में वे खुद बेहतर developers बनते हैं
      लेकिन अब दूसरों को उनकी abstractions सीखनी पड़ती हैं, और वे underlying concepts से उतने ही दूर हो जाते हैं। तब framework से आगे जाने के लिए जरूरी core skills सीखना और मुश्किल हो सकता है। Rails सीखते समय मुझे ऐसा ही लगा था, और आखिर में यह समझकर कि वह बहुत कुछ छिपा देता है, मैंने उसे छोड़ दिया और शुरुआत से करके देखा
    • मैं code snippets लिखने में काफी अच्छा हूं, लेकिन जब application पर्याप्त complex हो जाती है, तो मैं समस्या पर बार-बार गोल-गोल घूमते हुए rewrite करने के तरीके से हमला करने लगता हूं। complexity बढ़ने पर कभी-कभी rewrite infinite loop में फंस जाता हूं
      यह समझना कि यह पूरी तरह अलग skill है, आंखें खोल देने वाला अहसास है। कहें तो अब यह known unknown बन गया है
    • empathy अच्छी है, लेकिन cognition को समझना जरूरी है। वरना empathy गलत जगह लग जाती है
      जब boss गला दबा रहा हो, या रात 2 बजे कोई operations issue ठीक कर रहा हो, तब यह code उसे कैसा दिखेगा? उस जवाब की असल जरूरत पड़ने तक आपको उसकी कीमत पता नहीं चलती। और जिस क्षण जरूरत पड़ती है, उस जवाब के लिए आपको भारी कीमत चुकानी पड़ती है। बशर्ते आप ऐसा कर सकने वाला कोई व्यक्ति ढूंढ पाएं। ऐसे लोग दुर्लभ होते हैं

  • “इंसान core concepts से नहीं, examples से सीखते हैं” इस बात से मैं सहमत नहीं हूं। यह शायद nitpick हो, लेकिन सभी इंसान ऐसे काम नहीं करते
    जो लोग general से specific की दिशा पसंद करते हैं, उन्हें primary और secondary education में पहले ही बड़े पैमाने पर नजरअंदाज किया जाता है, और higher education में जाकर ही शायद चीजें उनके लिए ठीक बैठनी शुरू होती हैं। वे पहले ही काफी अलग-थलग किए जा चुके हैं, इसलिए उनके अस्तित्व को ही नकारने की जरूरत नहीं है

    • हाल ही में girlfriend और उसके पिता के साथ यात्रा करते हुए मैंने manual transmission चलाना सीखा। girlfriend ने सिर्फ यह बताया कि clutch कब दबाना है और कब छोड़ना है, और उससे बिल्कुल मदद नहीं मिली
      मुझे यह nuance समझ नहीं आ रहा था कि कब क्या करना है, कौन-सी चीजें पूरी तरह साथ-साथ करनी हैं और कौन-सी तुरंत बाद करनी हैं। तभी girlfriend के पिता ने संक्षेप में समझाया कि clutch असल में क्या करता है, और wheels व engine का connection दोनों तरफ क्या असर डालता है
      उसी क्षण मुझे समझ आ गया, और किसी खास situation में क्या करना है, इसके निर्देश सुनने की जरूरत भी नहीं रही। करीब 20 मिनट बाद मैं manual transmission की सबसे मुश्किल चीजों में से एक कर पा रहा था: पीछे की ओर ढलान वाली चढ़ाई पर handbrake से start करके car चलाना। कुछ लोगों के लिए first principles से यह समझना कि चीजें कैसे काम करती हैं, कहीं ज्यादा उपयोगी होता है, और मेरा मानना है कि software engineers में ऐसे “कुछ लोग” काफी हैं
    • मुझे दोनों चाहिए। मेरे लिए असली learning core concepts सीखना है, लेकिन examples उस understanding को verify करने के लिए known-answer cases हैं
      अगर example में कोई चौंकाने वाली बात हो, तो इसका मतलब है कि मेरा model अभी पूरा नहीं है। या फिर example गलत है
    • शायद मैं औसत engineer से धीमा हूं, लेकिन मुझे दोनों चाहिए। अभी काम का बड़ा हिस्सा इसलिए frustrating है क्योंकि यह एक बड़ी company है, और हर नई task मिलने पर सिर्फ यह example दिया जाता है कि पहले वाले व्यक्ति ने इसे कैसे किया था
      “हम जो हासिल करना चाहते हैं वह यह है, यह ऐसे काम करता है, और हम इसे ऐसे करते हैं” के बजाय, practitioner को हमेशा सिर्फ “हम इसे ऐसे करते हैं” ही दिखता है। जरा-सा भी अंतर आ जाए तो reason करके adjust करना और समस्या हल करना मुश्किल हो जाता है
      जो काम अक्सर किए जाते हैं उनके लिए कुछ documentation तो है, लेकिन वह आम तौर पर पुरानी या अधूरी होती है। यह wiki नहीं है, इसलिए कोई भी कभी भी उसे ठीक नहीं कर सकता, और docs ठीक करने के लिए झुंझलाहट भरी प्रक्रिया से गुजरना पड़ता है, इसलिए वे आखिर update नहीं होतीं। सोचता हूं तो यह सेना में बिताए समय से काफी मिलता-जुलता है
    • मैं भी सहमत हूं। मेरी learning style को metaphorically कहें तो reference manual को शुरू से अंत तक पढ़ना है। जब भी मैं कुछ नया सीखना चाहता था, recommended introductory material अक्सर मेरी तलाश के ठीक उलट निकला
      अभी भी Drizzle ORM सीखने के लिए समय निकालते हुए यही हो रहा है। सबसे पहले मिले सारे resources “छह query examples” थे, और मैं इस बात से परेशान हो गया कि वह syntax क्यों इस्तेमाल किया जाता है, दूसरे options क्या हैं। ऐसे resources बंद करके, docs के हर page को पढ़ने के बाद कुछ करना—मेरा अपना तरीका—मुझे कहीं ज्यादा comfortable लगता है
    • स्कूल में चीजें मेरे लिए तभी ठीक चलनी शुरू हुईं जब मैंने दिमाग में theory construction का अभ्यास शुरू किया। hypothesis बनाना, test करना, और refine करना
      अब भी मुझे नहीं पता कि मैं यह real time में कर सकता हूं या नहीं। यह तरीका काफी thinking cycles लेता है, इसलिए अभी मुझे text पढ़ना या video रोककर process करना ज्यादा सही pace लगता है
      कई बार मुझे उन लोगों को मौके पर ही सिखाना पड़ा जो अभी समझ नहीं पाए थे। अगर आपके पास system के बारे में theory हो, तो आप ऐसे सवालों के भी जवाब दे सकते हैं जिनका जवाब सिर्फ rote memorization से थोड़ा आगे बढ़े classmates नहीं दे पाते

  • यह Code Complete की पंक्ति है: “Programming के काम का छोटा हिस्सा ऐसे program लिखना है जिन्हें computer पढ़ सके, और बड़ा हिस्सा ऐसे लिखना है जिन्हें दूसरे इंसान पढ़ सकें।” पेज 733
    लगभग 20 साल से याद में है

    • “Programs इंसानों के पढ़ने के लिए बनाए जाते हैं, और computer द्वारा उन्हें execute करना सिर्फ एक अतिरिक्त बात है।”
      यह Abelson और Sussman की Structure and Interpretation of Computer Programs के पहले संस्करण की भूमिका में कही गई बात है, और Code Complete से 10 साल पहले की है
      यह वह कहावत है जिसका मैं पालन करने की कोशिश करता हूँ, लेकिन employers अजीब तरह से हमेशा उस हिस्से पर जोर देते दिखते हैं जिसे computer execute करता है
    • SICP के लेखकों में से एक Abelson ने भी कुछ ऐसा ही कहा था। आशय यह था कि code इंसानों के समझने के लिए लिखा जाना चाहिए, और computer का समझना सबसे आखिर में होना चाहिए

  • थोड़ा विषयांतर है, लेकिन कुछ दिन पहले Unity गेम बनाते हुए मुझे लगा कि IDE पिछले 10–20 सालों में शायद सचमुच बहुत ज़्यादा आगे नहीं बढ़े हैं
    बेसिक IntelliSense निश्चित रूप से काफ़ी बेहतर हुआ है, लेकिन उसके अलावा कुछ छोटी-मोटी बातों को छोड़ दें तो coding की पूरी अवधारणा पहले जैसी ही लगती है
    सबसे बड़ा सकारात्मक बदलाव editor के बाहर है। libraries और documentation तक पहुंच अब कहीं ज़्यादा आसान है, users के सवाल-जवाब बेहद ज़्यादा हो गए हैं, और कभी-कभी उन जवाबों को इकट्ठा करके ठीक-ठाक जवाब देने वाले ChatGPT जैसे नए tools भी आ गए हैं
    लेकिन कुल मिलाकर code लिखने की क्रिया ठहरी हुई लगती है। इसलिए अभी मैंने game पर काम थोड़ी देर के लिए रोककर कुछ experiments शुरू किए हैं। मैं नई language बनाना नहीं चाहता; बस जितने भी छोटे-मोटे झंझट हैं, उन्हें computer को देकर creation पर focus करना चाहता हूं
    पहली बार test करना चाहता हूं ऐसी तीन चीज़ें ये हैं। brackets या terminators जैसे छोटे language details की चिंता मैं क्यों करूं, tool उन्हें autocomplete क्यों नहीं कर सकता। private-public access chains या unsafe जैसे modifiers के लिए भी tool सबसे efficient set अपने-आप तय क्यों नहीं कर सकता। जब मैं आपस में interact करने वाले करीब 5 methods पर focus कर रहा हूं, तो कई windows खोलकर VS के horizontal/vertical sliders से जूझे बिना उन सबको एक ही screen पर देखना चाहता हूं। अगर मैंने HashSet बनाया और फिर उसे Dictionary या Tuple में बदलना पड़े, तो वह बस बदल दे, और जहां judgment की जरूरत हो केवल वही दिखाए ताकि मैं approve कर सकूं या खुद ठीक कर सकूं। Unity में ऐसा भी हो सके कि किसी method या data set पर click करके उसे Burst Job और उससे जुड़े NativeData set में बदलने का निर्देश दे सकूं

    • coding की पूरी अवधारणा पहले जैसी ही है, क्योंकि programming languages की पूरी अवधारणा भी बहुत बदली नहीं है। दो बड़े स्तंभ हैं: Turing machine और lambda calculus; उसके बाद सब abstractions हैं। abstraction अच्छी हो तो उसे paradigm कहते हैं
      लेकिन आखिर में सब abstraction ही है, और हम बस एक बेहद बेवकूफ machine को data compute करने के लिए instructions लिख रहे हैं
      आपने कहा कि brackets या terminators tool autocomplete कर दे तो क्या दिक्कत है, लेकिन computer सच में बहुत सरल चीज़ है और programming language हमारे मन के विचारों को पहुंचाने का माध्यम है। ऐसे delimiters language keywords जितने ही महत्वपूर्ण हैं, क्योंकि वे rules का हिस्सा हैं। उन्हें autocomplete करने के लिए और rules और और delimiters चाहिए होंगे
      अगर आप आपस में interact करने वाले कई methods को एक screen पर देखना चाहते हैं, तो Vim और Emacs, या Pharo जैसी Smalltalk IDE मौजूद हैं
      data transformations Vim और Emacs macros से किए जा सकते हैं। लेकिन सच्चाई यह है कि data encoding बहुत महत्वपूर्ण है। computer के लिए सब bits हैं; हम ही उन bits को अर्थ देते हैं और उस अर्थ के अनुसार manipulate करने के rules बनाते हैं। rules के एक set से दूसरे set में shape बदलने के लिए और rules चाहिए होते हैं
      live programming environment आज़माने की सलाह दूंगा। जैसे Common Lisp का SLIME, Smalltalk का Pharo, JavaScript का web inspector। यह जमीन पर नाव रखकर sailing कैसी होगी कल्पना करने के बजाय समुद्र के बीच खड़ी नाव पर काम करने जैसा है
    • मुझे लगता है text editor experience बहुत बेहतर न होने की वजह यह है कि वह अक्सर bottleneck नहीं होता
      programming का सबसे कठिन हिस्सा सोचना और सीखना है। तेज़ typing से बहुत बड़ी मदद नहीं मिलती
    • autocomplete के बारे में सहमत हूं। कम-से-कम 35 साल पहले MS-DOS के लिए editor Brief भी arbitrary templates define करके autocomplete कर सकता था
      उदाहरण के लिए C program लिखते समय “f” को “for (=; <=; ++) {;}” या अपनी पसंद की indentation शैली में expand कराया जा सकता था
      आधुनिक programming editors में भी ऐसी user settings support करने वाले बहुत हैं, लेकिन दुर्भाग्य से कई मामलों में प्रक्रिया बहुत पुराने समय की तुलना में अधिक जटिल है
      अगर programming language की syntax verbose है, तो editor में कम-से-कम keystrokes से किसी भी program structure को जल्दी लिखने के लिए templates define करने में समय लगाना जरूरी लगता है
    • brackets या terminators जैसी चीज़ें syntax को explicit बनाती हैं और tool support को काफी बढ़ाती हैं। आमतौर पर editors में इन्हें डालने की सुविधा होती है। लेकिन कुछ मामलों में जो मुझे obvious लगता है, वह असल में कई valid choices में से एक होता है, इसलिए design document जैसी कोई चीज़ न हो तो tool दिमाग नहीं पढ़ सकता
      HashSet, Dictionary, Tuple में से क्या इस्तेमाल करना है, इसमें performance impact होता है, और abstract रूप से हमेशा साफ़ नहीं होता कि किसे इस्तेमाल करना चाहिए। Java जैसी explicit languages, और शायद C# में भी, method calls को refactor किया जा सकता है ताकि वे दूसरा type लें। तब एक method बदलकर उसके सभी calls refactor किए जा सकते हैं
      मैंने Gemini pro और ChatGPT o1 के साथ experiment किया, और दोनों Python और JavaScript coding में सच में बहुत खराब हैं। वे buggy code लिखते हैं, और एक bug ठीक करते-करते अक्सर दूसरा bug डाल देते हैं। दोनों requirements पर सोचने के बजाय जवाब देने की जल्दी में लगते हैं। हमारे चाहने के तरीके से “दिमाग पढ़ने” या क्या महत्वपूर्ण है और क्या नहीं, यह समझने वाले tools तक पहुंचने में अभी कुछ दूरी है
      इससे भी बुरी बात training data हो सकती है। ज्यादातर code below-average और average coders बनाते हैं, इसलिए ऐसे tools average coder के thinking patterns अपना लेते हैं। अगर उन्हें सिर्फ सबसे उच्च quality code पर train किया जाए, तब भी यह साफ़ नहीं कि ज्यादातर coders सही prompt दे पाएंगे या नहीं। इसलिए अगर आप 10–20 साल से coding कर रहे हैं, तो instant magic की उम्मीद रखने वाले किसी tool से हमेशा कुछ निराश होने की संभावना काफी है
      फिर भी non-AI static analysis tools बहुत समय से शानदार रहे हैं और आगे और बेहतर होंगे। उनमें AI जोड़ने से और सुधार हो सकता है। अगर tool को specification फेंककर ठीक-ठाक result पाने वाले artist की तरह नहीं, बल्कि मुझे artist बनने में मदद करने वाली चीज़ की तरह सोचें, तो अच्छा experience मिल सकता है
      editor से आप जो काम और कराना चाहते हैं, वह AI को बताकर settings में मदद मांगने का experiment भी मज़ेदार हो सकता है। plugins में बहुत सारे non-AI tools हैं। आपकी lifestyle के अनुसार plugins चुनने के लिए large language model का इस्तेमाल करना शायद सबसे efficient हो सकता है
    • कई files के हिस्सों को edit करते हुए आपस में interact करने वाले करीब 5 methods को एक screen पर देखना चाहते हैं, तो haystack interesting हो सकता है
      https://haystackeditor.com/
      मैंने खुद इस्तेमाल नहीं किया है, लेकिन आज़माने का सोच रहा हूं

  • लेख का title विवादित हो सकता है। क्योंकि code केवल humans के लिए लिखा जाता है। computer को “code” की जरूरत नहीं होती, खासकर high-level code की तो बिल्कुल नहीं। computer के लिए machine-language instructions ही पर्याप्त हैं
    हम code इसलिए लिखते हैं क्योंकि machine-language instructions इंसानों के लिए लिखना बहुत कठिन है, और पढ़ना उससे भी कठिन
    code को computer के साथ interact करने के तरीके के रूप में नहीं सोचना चाहिए। code वह तरीका है जिससे humans अपने विचारों को formalize करते हैं, ताकि वे इतने unambiguous हों कि machine भी उनका पालन कर सके

  • पिछले हफ्ते लिखे और शेयर किए गए ब्लॉग पोस्ट को परोपकारी ढंग से प्रमोट कर रहा हूँ
    Move Fast & Document Things [1]
    इरादा कोई दार्शनिक लेख लिखने का नहीं था, बल्कि असली tips शेयर करने का था कि हमारी छोटी टीम [2] automation या AI से नहीं, बल्कि गहरी और कठिन review के ज़रिए अपने लिए और एक-दूसरे के लिए code writing culture कैसे enforce करती है
    दूसरे संगठनों में engineering leaders के रूप में काम करने वाले मेरे निजी दोस्तों ने कहा, “हम भी बिल्कुल यही करते हैं, लेकिन तुमने इसे सचमुच लिख दिया।” अगर आपको इसमें value लगी हो तो recommend करने की गुज़ारिश है
    [1] https://olshansky.substack.com/p/move-fast-and-document-thin...
    [2] https://github.com/pokt-network/poktroll/graphs/contributors

  • “बहुत सारी programming किताबें और tutorials ‘चलो शुरुआत से एक-एक ईंट जोड़कर घर बनाते हैं’ जैसे होते हैं, जबकि मुझे चाहिए ‘यहाँ एक चलने वाला घर है, चलो कुछ बदलकर देखते हैं कि क्या होता है’”
    मैंने programming खुद इसी तरीके से सीखी। कई साल छोटे, सरल और थोड़े घटिया programs को अच्छे से इस्तेमाल करने में बिताए
    बाद में पता चला कि मैं बेहतर software development नौकरियों के लिए उपयुक्त नहीं था। वजह यह थी कि software design, programming languages और computers की बुनियादी समझ बिल्कुल नहीं थी। चूँकि मैंने उबाऊ तरीके से नहीं सीखा था, interview room से निकलते समय यह समझना कि मुझे कितना कुछ नहीं पता, बहुत विनम्र बना देने वाला अनुभव था
    हमेशा पूरी manual पढ़नी चाहिए, और हमेशा fundamentals सीखने चाहिए

  • मेरा सारा code इंसानों के लिए लिखा जाता है
    चाहे वह इंसान मैं ही क्यों न होऊँ, या कुछ साल बाद मेरी मंशा समझने की कोशिश करता कोई बेचारा व्यक्ति हो
    मेरे हिसाब से code लिखना अपने आप में मुश्किल नहीं है। असली प्रतिभा उन हिस्सों में दिखती है जहाँ समस्या पर व्यापक रूप से reasoning करनी होती है, दूसरे stakeholders के साथ collaborate करके सबसे अच्छा रास्ता ढूँढना और उन्हें lead करना होता है, नई mathematics या industry conventions जैसी specialized skills सीखनी होती हैं, efficient algorithms बनाने होते हैं, और program की structure व patterns को साफ़ और elegant boundaries के साथ communicate करना होता है
    आखिरकार बहुत कुछ communication और clarity पर निर्भर करता है

  • इस लेख का बड़ा हिस्सा documentation के बारे में है, और अगर इसमें 4doc model का संदर्भ दिया गया होता तो बहुत मदद मिलती: https://docs.divio.com/documentation-system/
    मूल बात यह है कि सिर्फ reference docs न दें, usage docs भी दें। और चूँकि आम तौर पर users पूरे documentation में सबसे पहले वही हिस्सा देखना चाहते हैं, इसलिए उसे आगे रखें
    बेशक यह सामान्य तौर पर कहा जा रहा है; मैं खुद अक्सर सीधे reference material पर जाता हूँ, लेकिन हमेशा नहीं
    इसका मतलब यह नहीं कि 4doc कोई सर्व-समाधान या प्रकृति का नियम है। Hillel Wayne ने यहाँ इसकी समस्याओं पर भी अच्छी तरह बात की है: https://www.hillelwayne.com/post/problems-with-the-4doc-mode...