मैं, एक शुरुआती डेवलपर नहीं, आपके (डेवलपर) द्वारा मेरे लिए लिखे गए ट्यूटोरियल को कैसे पढ़ता/पढ़ती हूँ

 (anniemueller.com)
5 पॉइंट द्वारा GN⁺ 2025-09-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह लेख मज़ाकिया अंदाज़ में बताता है कि एक शुरुआती व्यक्ति को डेवलपर्स द्वारा लिखे गए तकनीकी ट्यूटोरियल पढ़ते समय कितनी उलझन और बाधाओं का सामना करना पड़ता है
  • डेवलपर्स द्वारा अक्सर इस्तेमाल किए जाने वाले तकनीकी शब्द और संक्षेप शुरुआती लोगों को बिना किसी संदर्भ वाली किसी एलियन भाषा जैसे लगते हैं
  • ट्यूटोरियल के इंस्टॉलेशन स्टेप्स, फ़ाइल पाथ और टर्मिनल कमांड इतने जटिल होते हैं या इतने कुछ छोड़ देते हैं कि उन्हें समझना मुश्किल हो जाता है
  • लेखिका बताती हैं कि जो बातें डेवलपर की नज़र में बिल्कुल स्वाभाविक लगती हैं, वही शुरुआती लोगों के लिए घंटों की खोज और trial-and-error की दीवार बन जाती हैं
  • यह लेख ट्यूटोरियल लिखने वाले डेवलपर्स को याद दिलाता है कि शुरुआती के नज़रिए से ज़्यादा सहज और स्पष्ट तरीके से समझाना ज़रूरी है

लेख की पृष्ठभूमि और समस्या-बोध

  • लेखिका, जो डेवलपर नहीं बल्कि एक शुरुआती पाठक हैं, बताती हैं कि डेवलपर्स द्वारा लिखे गए ट्यूटोरियल पढ़ते समय कैसा अनुभव होता है
  • ट्यूटोरियल में आने वाले तकनीकी शब्दों और टूल के नामों का क्या मतलब है, इसका बिल्कुल अंदाज़ा न होने की स्थिति को व्यंग्यात्मक ढंग से दिखाया गया है
  • उदाहरण के लिए Hoobijag, Snarfus, Shamrock portal जैसे काल्पनिक तकनीकी नामों का उपयोग करके यह दिखाया गया है कि शुरुआती की नज़र में सब कुछ कितना उलझा हुआ लगता है

मूल पाठ का अनुवाद

“नमस्ते! मैं एक डेवलपर हूँ। मेरा प्रासंगिक अनुभव कुछ ऐसा है: मैं Hoobijag में कोड करता हूँ और कभी-कभी jabbernocks भी इस्तेमाल करता हूँ, और हाँ, ABCDE++++ भी करता हूँ (लेकिन ABCDE+/^+ तो कभी नहीं, वह तो बकवास है, है ना? हाहा!) और मुझे Shoobababoo के साथ काम करना पसंद है और कभी-कभी kleptomitrons भी संभालता हूँ। मुझे Company[1] में Shoobaboo से जुड़ा कोड लिखने का मौका मिला, और उसी ने मुझे Snarfus तक पहुँचाया। चलिए, शुरू करते हैं!

इस ट्यूटोरियल के बारे में

मैंने पहली बार Snarfus में एक बहुत ही सरल चीज़[2] करना शुरू किया था, लेकिन जितना ज़्यादा इस्तेमाल किया, उतनी उसकी क्षमता नज़र आने लगी! chromus थोड़ा उलझा हुआ है, लेकिन असल में यह बहुत versatile है। इसलिए मैंने hoobastank की जगह quagmire से pintafore को argyling करना शुरू कर दिया! पागलपन है, पता है। लेकिन कुछ हद तक यह चला, और सच कहूँ तो काफ़ी मज़ेदार भी था… जब तक कि एक बड़ी रुकावट सामने नहीं आ गई: fisterfunk, shamrock portal से बिल्कुल बात ही नहीं कर रहा था, और Snarfus को beep-boops भी नहीं भेज रहा था! बेशक, आप समझते हैं इसका क्या मतलब है[3]— अब पूरा hoob-टनल gramelions से जाम हो गया है। यह बिल्कुल स्वीकार्य नहीं है।

मैं लगभग हार मानने ही वाला/वाली था/थी, लेकिन तभी मुझे समझ आया: अगर backside Snarfus stagnator को backside shamrock Klingon troglodyte emulater से जोड़ दें, तो बात बन जाती है! सब कुछ beep-boops और ding-dongs करने लगता है, और तब जाकर हम ट्यूटोरियल के असली विषय तक पहुँचते हैं। और फिर आप अपनी मनचाही तरह से वह बहुत ही सरल चीज़ कर सकते हैं! काफ़ी शानदार है, है ना[4]।

तो इसे सेट अप करने का तरीका यह है:

  1. टर्मिनल में ajkl;gawgor;iqeg;iJLkqen. wl;R aw;oeiga 4648664 arjarwgj;llj;ja fadgfgajkljl; wlj;sdjk;lfas टाइप करें
  2. अब folder/hidden/deep/in/the/file/system/surprise!.file पर जाएँ और फ़ाइल की सामग्री कॉपी करें। अगर वह वहाँ नहीं है, तो संभव है कि वह library/library/library/llibrary/liiiiiibrarrrary/llllliiiiibrary/hidden/hidden/hiding/you can’t find me/hidden/nope/never/hahahahereiam.file में हो
  3. फिर से टर्मिनल पर लौटें, फ़ाइल की सामग्री पेस्ट करें, और 64A786AGR45JAR; rdja;jg [[]][[]][[]][[]]][[]()()()()()()()()(){{}{}{}|{}{|}{}{|}{ ////////////////!! !!!! !! //// !!! agjlkargji;lwej;OI [ASRGASG[]ASGDASG[]EAEadgasg[]EAGE[edaga][]ahgr-0-0=-0-=0-=0=0-0=-0-=0=-0-=0=-0=-0!!! टाइप करें
  4. Boop![5]
  5. Snarfus खोलें और अभी बनाई गई फ़ाइल अपलोड करें
  6. बस मज़े के लिए, अगर आप chronostatiomatrix के sham को अनसेट करना चाहते हैं — ()()(]]asdg a=-do —cd go cd stay —sususudododo baby shark—][] भी चला सकते हैं। यह वैकल्पिक है
  7. हो गया!

बताइए कि यह आपके लिए कैसा काम करता है। और यह भी जानने की जिज्ञासा है कि क्या कोई इस तरीके को GewGawGamma या ometer2.7 के साथ भी इस्तेमाल कर रहा है।”

फ़ुटनोट की व्याख्या

  1. कोई मशहूर कंपनी लगती है, लेकिन मैं इसे नहीं जानता/जानती
  2. यह बिल्कुल भी सरल नहीं है
  3. मुझे नहीं पता इसका क्या मतलब है
  4. शानदार तो है, लेकिन मुझे समझ नहीं आया। फिर भी अच्छा है कि आप यह कर पाए
  5. शुरुआती 3 स्टेप्स में शायद लगभग 7 घंटे और 193 बार सर्च करना पड़ेगा। लेकिन जब आप Boop! तक पहुँचते हैं, तो वह काफ़ी रोमांचक होता है

समापन

  • “यह बस मज़ाक के लिए लिखा गया है। ज्ञान साझा करने और ट्यूटोरियल लिखने वाले सभी लोगों का मैं दिल से आभार मानता/मानती हूँ।”

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

1 टिप्पणियां

 
GN⁺ 2025-09-23
Hacker News टिप्पणी

  • मैं इस तरीके की ज़ोरदार सिफारिश करता/करती हूँ कि किसी ऐसे व्यक्ति से, जिसे बस न्यूनतम जानकारी हो, दस्तावेज़ को फॉलो करवाया जाए और आप बगल में बिना कुछ बोले बस देखते रहें। इस दौरान बिल्कुल मदद न करें, सिर्फ़ observe करें। इस प्रक्रिया में पता चलता है कि user कहाँ अटकता है, लेखक किन बातों या settings को अपनी अधिक familiarity की वजह से मानकर चल गया और लिखना भूल गया, जैसी कई समस्याएँ सामने आती हैं। अगर user बिना ज़्यादा stress के लक्ष्य तक पहुँच जाए, तो documentation पास मानी जा सकती है। नहीं तो जहाँ-जहाँ failure हुआ, उन सभी points को बिना कुछ छोड़े दर्ज करना चाहिए, हर issue को सुधारना चाहिए, और फिर किसी नए व्यक्ति के साथ दोबारा test करना चाहिए। मैंने FAANG जैसी बड़ी कंपनियों के docs भी इस कसौटी पर fail होते देखे हैं। हमारी organization ने ऊँचा standard रखा है, इसके लिए मैं सच में आभारी हूँ। इस तरह docs बनाने से बार-बार होने वाली meetings, support requests, और video calls कम होते हैं, और users खुद समस्याएँ हल कर पाते हैं

    • Apple के docs इस्तेमाल करते समय मुझे यह समस्या अक्सर दिखती है। documentation में definitions कई बार बस नाम को ही दोहरा देती हैं और बिना explanation आगे बढ़ जाती हैं; इसे ज़्यादा concrete तरीके से लिखा जाना चाहिए
    • "कुछ मत बोलो, सिर्फ़ observe करो" वाला नियम आसान लगता है, लेकिन असल में बहुत लोग खुद को रोक नहीं पाते और समझाने या hint देने लगते हैं। कुछ ने तो सीधे mouse पकड़ लिया। ऐसी मानवीय प्रतिक्रिया से बचने के लिए यह भी मददगार हो सकता है कि एक अलग neutral moderator हो, और author/developer सिर्फ़ observe करे। लेकिन 'बस देखते रहना' यह skill सीखना महत्वपूर्ण है, और अगर आगे बढ़ना हो तो "think-aloud protocol" के बारे में देखना recommend करूँगा/करूँगी
    • ज़्यादातर company teams की onboarding docs की quality बहुत खराब होती है, और वही पहले से असली work burden की झलक दिखा देती है। जिन तीन teams में मैं हाल में जुड़ा/जुड़ी, वहाँ docs या तो लगभग थीं ही नहीं या बहुत outdated थीं, इसलिए मुझे खुद लोगों को ढूँढ-ढूँढकर ज़रूरी access permissions या deployment pipeline की जानकारी लेनी पड़ी। उस दौरान नए docs लिखे भी जाते हैं, लेकिन जैसे ही system या permissions बदलती हैं, वे फिर outdated हो जाती हैं — यह एक vicious cycle है। सिर्फ़ एक team ने दो दिन में पूरा environment set up करवा दिया था, और वह experience बेहतरीन था। अब मैं एक नई devex team में हूँ और documentation environment को ही बेहतर बनाने की कोशिश कर रहा/रही हूँ
    • खराब setup docs पढ़ते हुए onboarding करना सचमुच 10 गुना ज़्यादा stressful लगता है। मैं हमेशा encourage करता/करती रहा/रही हूँ कि new hires जिस issue से गुज़रें, उसे अपनी first contribution के रूप में तुरंत fix करें। नए लोगों के पास कोई context नहीं होता, इसलिए वे सबसे अच्छे reviewers बन सकते हैं
    • हमारी organization भी यही workflow इस्तेमाल करती है। कम experience वाले व्यक्ति से docs follow करवाई जाती हैं, और उसके बाद सभी को लगातार docs सुधारने के लिए encourage किया जाता है। क्योंकि लंबे अनुभव वाले लोगों में जो blind spots बन जाते हैं, उन्हें नए लोग अच्छी तरह पकड़ लेते हैं। मेरे अनुभव में, user confidence को manage करना भी बेहद महत्वपूर्ण है। इसलिए जब हम "यह shell command चलाइए" जैसे steps देते हैं, तो default रूप से कुछ sections collapsible रखते हैं (जैसे: successful output का example, ignore की जा सकने वाली warnings, संभावित errors की list और उनके fixes, जटिल command की explanation आदि)। कुछ steps के साथ तो पूरे एक page जितनी detail जुड़ जाती है, लेकिन onboarding के दौरान यह विस्तार वास्तव में बहुत मदद करता है

  • ब्लॉग पोस्ट का शीर्षक "मैं, एक गैर-डेवलपर, आपके द्वारा लिखे गए डेवलपर ट्यूटोरियल को पढ़ता/पढ़ती हूँ" था, लेकिन HN title बदलकर "मैं, एक beginner developer..." कर दिया गया। गैर-डेवलपर और beginner developer बिल्कुल अलग होते हैं। उदाहरण के लिए, HR team या पूरी तरह non-technical background वाले व्यक्ति के लिए internal terminology या concepts भी पूरी तरह अनजाने हो सकते हैं। ऐसे में अगर developer ने पूरी तरह disconnected explanation लिखी हो, तो उसकी आलोचना जायज़ है। दूसरी तरफ़ beginner developer, चाहे चीज़ें कठिन हों, नए terms और concepts खुद खोज सकता/सकती है, और समय के साथ नए आने वाले beginners के लिए docs update भी कर सकता/सकती है

    • संदर्भ के लिए, पोस्ट को मूल रूप से "गैर-डेवलपर" शीर्षक के साथ submit किया गया था, लेकिन बीच में इसे "beginner developer" में बदल दिया गया। लेखिका एक non-technical blogger हैं, और website या CSS के साथ काम करने के लिए उन्हें कई technical docs देखनी पड़ी होंगी। शायद website publishing और non-expert docs की कमी पर चर्चा करना ज़्यादा उचित होता, लेकिन HN community चर्चा को दूसरी दिशा में ले जाए तो वह भी ठीक है
    • यह distinction बहुत महत्वपूर्ण है। लेखिका Annie ने खुद कहा है कि वह "content/documentation से जुड़ा काम" करती हैं और CSS उनका hobby भी है, इसलिए वे "non-professional hobby developer" श्रेणी में आती हैं। मुझे लगता है यह क्षेत्र आगे और बढ़ेगा। जब beginner/non-developer को शामिल करने वाले tutorials लिखें, तो "cd ~/.snarfus(अगर folder न हो तो बना लें)" जैसी line में बस एक बहुत छोटा सा अतिरिक्त explanation जोड़ देना भी काफी होता है। मैंने भी Debian install करते समय ऐसे छोटे explanations से बहुत मदद पाई थी
    • जब मैं programming में नया/नई था/थी, तो जिस site ने मुझे सबसे ज़्यादा प्रभावित किया, वह "FromZero" थी। वह गैर-डेवलपर्स के लिए IDE install करने से लेकर console खोलने तक सब कुछ step-by-step समझाती थी, और अपरिचित terms के लिए यह भरोसा भी देती थी कि "इसे हम बाद में cover करेंगे, अभी चिंता न करें" — यह शानदार था। बेशक, documentation लिखने में बहुत समय और मेहनत लगती है, इसलिए कभी-कभी कुछ explanation होना भी, बिल्कुल न होने से बेहतर है। मेरा मानना है कि beginner developers के लिए docs, non-developers जैसी संवेदनशीलता के साथ लिखी जानी चाहिए
    • कुछ लोग मानते हैं कि अगर हर चीज़ बेहद आसान भाषा में न समझाई जाए तो वह gatekeeping है, और वे यह अनदेखा कर देते हैं कि बिना किसी prior knowledge के कोई भी चीज़ तुरंत समझ आना संभव नहीं है
    • अगर यह beginner developers के लिए tutorial है और professional developers के लिए नहीं, तब भी हर एक "Hoobijag" या "shamrock portal" जैसे concept को विस्तार से समझाने की अपेक्षा करना अजीब है। सच तो यह है कि हम सबने शुरुआत में अनजाने terms को Google करके ही सीखा था

  • ज़्यादातर tutorials गैर-डेवलपर्स के लिए नहीं होते, बल्कि साथी developers के बीच information exchange जैसे होते हैं, और इस अर्थ में वे academic papers की तरह किसी खास knowledge community के लिए लिखे documents के समान स्थिति रखते हैं। यह तरीका भी बुरा नहीं है। बल्कि, मैंने जो चीज़ें पहले note की थीं, उन्हें बाद में फिर से देखना भी आसान होता है। इसी वजह से beginners के लिए अलग courses और study materials मौजूद हैं। अगर हर tutorial को हर बार 30,000 शब्दों के पूरे background explanation से शुरू करना पड़े, तो कोई भी उसे अंत तक नहीं पढ़ेगा। उल्टा, आप जितना भी ज़्यादा background जोड़ दें, किसी न किसी को वह फिर भी अपर्याप्त लगेगा

    • मेरा बेटा (17) programming में बहुत रुचि रखता है, और हाल में मैंने उसे public/private/internal/static concepts के साथ recursion भी समझाया है। अब मैं मन ही मन यह देखने का इंतज़ार कर रहा/रही हूँ कि अगली प्रतिक्रिया क्या होगी
    • मैं इस बात से सहमत नहीं हूँ कि "ज़्यादातर tutorials गैर-डेवलपर्स के लिए नहीं होते"। मैं स्पष्ट करना चाहता/चाहती हूँ कि इस tutorial की headline खुद साफ़ तौर पर गैर-डेवलपर्स को target करती है। open source projects install करते समय संघर्ष करने और इस बात पर आवाज़ उठाने की बहुत ज़रूरत है कि कम-से-कम बुनियादी installation guides भी beginners के लिए follow करना आसान हों। छोटे-छोटे steps छूट जाएँ तो किसी अनजाने क्षेत्र में कई घंटे बर्बाद हो सकते हैं
    • बल्कि, मैं नहीं मानता/मानती कि docs को सबके लिए अधिक friendly तरीके से लिखना कोई बुरी बात है। अच्छी documentation सिर्फ़ beginners ही नहीं, developers के लिए भी उपयोगी होती है। accessible docs न होने का कारण बस इतना है कि लोग थोड़ा extra effort नहीं करना चाहते। और developer docs में समस्या, papers के विपरीत, यह भी है कि वे अक्सर बहुत संक्षिप्त लिखी जाती हैं या लेखक reader की ज़रूरत का ध्यान ही नहीं रखता। नतीजा यह होता है कि docs अंततः experts के अलावा किसी के काम की नहीं रह जातीं। यह एक failure है
    • मैं इस बात से सहमत हूँ कि beginners के लिए context को धीरे-धीरे build करने वाली docs की ज़रूरत है। लेकिन, आजकल DX (developer experience) को "आसान बनाने" पर इतना focus किया जाता है कि पहले काम आने वाले logs या error messages search करने जैसी चीज़ों की बलि चढ़ जाती है, और नतीजतन अनुभव सिर्फ़ beginners के हिसाब से optimize हो जाता है जबकि existing users के लिए असुविधाजनक बन जाता है
    • आजकल tutorials कई बार वास्तव में "मैंने X project में contribution किया" जैसी résumé-building content ज़्यादा लगते हैं। बेहतर होगा कि लेखक 3 महीने बाद खुद अपनी tutorial दोबारा follow करे; तब missing pieces बहुत साफ़ नज़र आएँगे और बड़ी improvement हो सकती है

  • बहुत से technical writers 'curse of knowledge' को सही तरह से पहचान ही नहीं पाते। मुझे पहले WoW (World of Warcraft) guild चलाने का अनुभव है। 40 लोग एक साथ dungeon में जाते थे और मिलकर कई bosses से लड़ते थे, जहाँ बहुत छोटी गलती से पूरी टीम wipe हो सकती थी। इसलिए हम सब Teamspeak पर इकट्ठा होकर strategy पहले से विस्तार से समझाते थे। वहाँ सबसे बड़ा lesson था: "मानकर चलो कि सामने वाले को यह नहीं पता कि मैं क्या कह रहा/रही हूँ" और "जो एक बार कहा है, उसे दोहराओ भी"। ज़्यादातर लोग कुछ न समझने पर भी बीच में टोककर सवाल नहीं पूछते, इसलिए लगातार खुद से यह पूछना कि 'मैं कौन-सा term बोल रहा/रही हूँ?' और 'क्या सामने वाला इस concept से अनजान हो सकता है?' और फिर accordingly explanation जोड़ना, बहुत प्रभावी साबित हुआ। इस तरह का communication experience technical communication में भी सीधे लागू होता है, और अगर आप 'curse of knowledge' से पार पाने की आदत विकसित कर लें, तो दूसरों की समझ को काफ़ी बेहतर बना सकते हैं

    • अपनी पुरानी raid guild में 18 साल के guild leader को अलग-अलग time zones से adults को इकट्ठा करते, loot distribution, strategy और scheduling सब कुछ smoothly handle करते देखकर मुझे लगा था, "इस लड़के को तो सीधे manager की नौकरी मिलनी चाहिए"
    • 40-लोगों वाली raid चलाने का अनुभव रखने वाला कोई भी व्यक्ति project manager के रूप में top-tier capability रखता है। यह सचमुच बिखरी हुई बिल्लियों के झुंड को बिना अफ़रा-तफ़री के संभालने जैसा काम है

  • बहुत से project homepages या GitHub README इस अंदाज़ में लिखे जाते हैं मानो "जो यह पढ़ रहा है, उसे सब पहले से पता है"। docs देखते समय मैं चाहता/चाहती हूँ कि कुछ बारीकियाँ ज़रूर मिलें: 'यह tool क्यों चाहिए', 'यह किस problem को solve करता है', 'दूसरे समान tools से यह कैसे अलग है', 'क्या यह अभी भी actively used है', और 'क्या इसके फायदे-नुकसान समझने लायक पर्याप्त material दिया गया है'। सिर्फ़ 5 मिनट लगाकर अगर कोई यह सोच ले कि "एकदम beginner क्या जानना चाहेगा?", और वही लिख दे, तो accessibility बहुत बढ़ जाती है। कई साल लगाकर बनाए गए project के लिए यह सच में दुखद है कि users बस इस वजह से छोड़ दें क्योंकि उन्हें यह समझ ही न आए कि आगे कैसे बढ़ना है। और documentation के अलग-अलग प्रकार की भूमिका समझना भी महत्वपूर्ण है। https://diataxis.fr/ एक अच्छा शुरुआती बिंदु है

    • ROS (robot software) क्षेत्र में READMEs की कमी से मैं हमेशा तनाव में रहा/रही हूँ। project name के अलावा कोई hint नहीं होता, इसलिए उसका use case समझना भी मुश्किल हो जाता है। यह सिर्फ़ open source की समस्या नहीं है; workplace में भी मेरा यही अनुभव रहा है, और कई बार लगता है README में explanation जोड़ने वाला/वाली मैं ही अकेला/अकेली हूँ। monorepo वाले पुराने दिन शायद ज़्यादा सुखद थे
    • मैं समझता/समझती हूँ कि developers प्यार और मेहनत से tools बनाते हैं, लेकिन अगर वे docs पर थोड़ा ध्यान दें, तो entry barrier बहुत कम हो सकता है। ऊपर से अगर stack के दूसरे components की docs भी कठिन हों, तो learning curve घातीय रूप से और तेज़ हो जाता है
    • पहले HN पर एक ऐसा project भी आया था जिसमें यह तक नहीं लिखा था कि वह है क्या

  • documentation लिखते समय सबसे महत्वपूर्ण बात है 'target reader के knowledge level' को साफ़-साफ़ तय करना। baseline ऊँची रखें या नीची, इससे फ़र्क नहीं पड़ता, लेकिन अगर आप उस baseline से बहुत दूर चले गए, तो कुछ readers ज़रूर असंतुष्ट होंगे। ऐसी स्थिति में आप बहाने चुन सकते हैं, या समाधान खोज सकते हैं। सच यह है कि आजकल AI, Google, books आदि से लगभग हर चीज़ तुरंत खोजी जा सकती है। अगर आपको जानना है कि 'Shoobababoo क्या है' या 'quagmire क्यों इस्तेमाल होता है', तो search कर सकते हैं। बेशक, आदर्श यह है कि documentation जहाँ तक संभव हो external information के बिना self-contained हो, लेकिन दुनिया हमेशा इतनी उदार नहीं होती

    • यही वजह है कि अलग-अलग setup guides का "अब exe file पर double-click करें और next दबाते जाएँ" से शुरू होना भी एक अलग समस्या है। guide की baseline setting वास्तव में बहुत महत्वपूर्ण है
    • मैं ज़्यादातर internal sensitive systems के लिए docs लिखता/लिखती हूँ, और कभी-कभी documentation की शुरुआत में साफ़ लिख देता/देती हूँ: "यह guide मानकर चलती है कि आपको x, y, z का उपयोग पहले से आता है। अगर नहीं आता, तो आपको यह काम नहीं करना चाहिए।" access restrictions तो होती ही हैं, लेकिन DR scenarios जैसी स्थिति में कोई अपरिचित व्यक्ति इसका उपयोग कर सकता है, इसलिए कभी-कभी जानबूझकर ऐसी boundary भी छोड़नी पड़ती है कि 'अगर यह भी समझ नहीं आता, तो यह बिल्कुल मत करो'

  • लंबे समय तक mentoring करते हुए मेरा मुख्य सिद्धांत रहा है: "जो जानते हो, उसे बाँटना सबसे अच्छा है"। अगर आपको कुछ पता है, तो उसे समझाइए; अगर सामने वाले को पहले से पता होगा, तो बस उसकी पुष्टि हो जाएगी, और अगर नहीं पता होगा, तो बहुत मदद मिलेगी। कभी-कभी लोग शिकायत करते हैं कि मैं बहुत verbose हूँ, लेकिन जब मैं कहता/कहती हूँ, "यह इसलिए था क्योंकि शायद कोई junior, customer, या manager भी इसे देखे", तो ज़्यादातर लोग समझ जाते हैं। यह सिद्धांत development, reporting, people management — हर जगह लागू होता है

    • बेशक, कुछ लोग वह चीज़ explain किए जाने से बेहद चिढ़ते हैं जो उन्हें पहले से पता हो। अगर signal-to-noise ratio बहुत खराब हो जाए, तो communication खुद बाधित हो सकता है
    • अपने बेटे को billiards सिखाने के अनुभव में भी मुझे ऐसा ही लगा। सतर्कता छोड़कर teammates के बीच tips खुलकर बाँटने की संस्कृति growth में बहुत मदद करती है। mentoring में सीधे answer देने के बजाय सवालों के ज़रिए व्यक्ति को खुद वहाँ तक पहुँचने देना, उसके अपने realization के समय असली प्रगति लाता है
    • हर किसी को हर बात समझाना कभी-कभी "mansplaining" समझ लिया जाता है, या फिर ऐसा लग सकता है कि आप "सब कुछ जानने का दिखावा" कर रहे हैं, जिससे office politics में जोखिम पैदा हो सकता है। कई workplaces में सिर्फ़ तब जवाब देना ज़्यादा सुरक्षित होता है जब कोई आपसे सवाल पूछे

  • हाल में मैंने Gitlab से DigitalOcean Kubernetes पर app deploy करने की कोशिश की। इसमें 3-4 third-party tools implement करने पड़े, बिना यह बताए कि वे क्या करते हैं, और command line में कौन-सा नाम या path डालना है, यह भी खुद समझना पड़ा। किस चीज़ को baseline मानना है और किससे match करना है, इसकी भी कोई explanation नहीं थी। Docker में मेरी skill काफ़ी अच्छी है, फिर भी इन tools की docs इतनी unfriendly लगीं कि लगता था बिना docs के ही बेहतर होता

  • मैंने किताबें लिखना छोड़कर tutorial website बनाने का मुख्य कारण यही था कि tutorials को अधिक लोगों के लिए accessible बनाने में तरह-तरह के interactive tools (<abbr> element आदि) मदद कर सकते हैं। फिर भी, आज का web content अब भी paper book की सीमाओं में अटका हुआ लगता है, यह निराशाजनक है। click, hover, collapsible sections, video, user response जैसी इतनी सारी सुविधाएँ होने के बावजूद अब भी दीवार जैसी लंबी text blocks ही भरी रहती हैं। यहाँ तक कि OP भी footnotes पर click करने पर page के नीचे scroll कराने वाला तरीका इस्तेमाल करता/करती है, जो web की संभावनाओं का पूरा उपयोग नहीं लगता

    • मैं अभी अपने blog को upgrade करने की कोशिश कर रहा/रही हूँ; अगर आप ऐसे sites recommend कर सकें जो इस तरह के interactive, अच्छी तरह बनाए गए tutorials में अच्छे हों, तो आभारी रहूँगा/रहूँगी

  • सच कहें तो, ज़्यादातर tutorials न गैर-डेवलपर्स के लिए होते हैं, न developers के लिए; वे बस 'अनावश्यक रूप से लंबा text' होते हैं जिनमें अंततः एक-दो अहम steps छूट जाते हैं। मेरे हिसाब से सबसे बड़ा कारण यह है कि लोगों के लिए ऐसे लिखना कठिन होता है जैसे वे सच में किसी और को समझा रहे हों। जो बातें सिर्फ़ आपके दिमाग़ में हैं, अगर उन्हें आप लिखकर बाहर नहीं लाएँगे, तो reader उन्हें कभी नहीं जान पाएगा। 'tutorial' की जगह 'cookbook' शैली में लिखना ज़्यादा उपयोगी हो सकता है, क्योंकि वह व्यावहारिक इस्तेमाल के लिए बेहतर होता है और version upgrade के बाद बेकार हो जाने से भी कुछ हद तक बचाता है

    • विडंबना यह है कि आजकल online recipes/cookbooks में भी कई बार non-developer blogs से ज़्यादा अनावश्यक भूमिका और बकवास भरी होती है