पहले अपने टूल्स ठीक करो

 (ochagavia.nl)
1 पॉइंट द्वारा GN⁺ 2026-02-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • open source लाइब्रेरी के bug को ट्रैक करने की प्रक्रिया में debugger के काम न करने की समस्या सामने आई
  • कोड चलने के बावजूद breakpoint के अनदेखा होने की स्थिति दिखाई दी, और समस्या खोजने के लिए दूसरे तरीकों की कोशिश की गई
  • लॉग आउटपुट जोड़ने जैसी अप्रत्यक्ष डायग्नोस्टिक कोशिशें की गईं, लेकिन मनचाही समझ नहीं मिली
  • आखिरकार debugger की configuration गलती को ठीक करने के बाद प्रोग्राम के व्यवहार को बारीकी से देखा जा सका, और इसी से bug हल हुआ
  • समस्या सुलझाने में इतना डूब जाने के कारण टूल की अपनी खराबी को नज़रअंदाज़ कर देने के अनुभव के जरिए यह बात रेखांकित की गई कि डेवलपर को पहले अपने टूल्स ठीक करने चाहिए ताकि समस्या को अधिक कुशलता से हल किया जा सके

bug diagnosis के दौरान आई समस्या

  • मेंटेन की जा रही open source लाइब्रेरी के bug को ढूँढते समय debugger द्वारा breakpoint को अनदेखा करने की स्थिति सामने आई
    • यह पक्का था कि कोड ने उस लाइन को execute किया था, लेकिन प्रोग्राम बिना रुके पूरा हो गया
    • समस्या हल करने पर इतना ध्यान था कि debugger की दिक्कत को अनदेखा कर दूसरे तरीके आज़माए गए
  • कोड में बदलाव और लॉग जोड़कर diagnosis की कोशिश की गई, लेकिन उपयोगी जानकारी नहीं मिली

debugger को ठीक करना और समस्या का समाधान

  • debugger की समस्या को हल करने का फैसला किया गया, और एक लाइन की configuration change से इसे ठीक कर लिया गया
    • ठीक करने के बाद प्रोग्राम के व्यवहार को विस्तार से देखा जा सका
    • इसी जानकारी के आधार पर bug को सफलतापूर्वक हल किया गया

समझ और सीख

  • bug ठीक करने का उत्साह ही उल्टा टूल की समस्या को नज़रअंदाज़ करा देने वाली विडंबनापूर्ण स्थिति बन गया, यह बात समझ में आई
  • यह अनुभव हुआ कि अगर टूल सही से काम न करे, तो समस्या सुलझाने की दक्षता घट जाती है
  • डेवलपर के लिए ज़रूरी है समस्या से पहले टूल्स को जाँचना और ठीक करने की आदत
  • “Fix your tools” वाक्य के साथ यह लेख खत्म होता है, जो सभी प्रोग्रामरों को टूल्स के महत्व की याद दिलाता है

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

1 टिप्पणियां

 
GN⁺ 2026-02-23
Hacker News की राय

  • मेरे पास 30 साल का करियर अनुभव है, और आजकल development tools बहुत टूटे हुए हैं
    मैं Linux पर Clio में कोड लिखता हूँ, और कई सालों से bugs लगातार बदतर होते जा रहे हैं
    अब तो बस “नहीं चलता तो नहीं चलता” कहकर आगे बढ़ जाता हूँ। ज़िंदगी छोटी है, दूसरों का code ठीक करने का समय नहीं है

  • किसी समस्या को ठीक करने लगो तो आखिरकार ‘yak shaving’ में फँस जाते हो
    एक छोटी समस्या सुलझाने जाओ तो उससे जुड़ी बारीकियाँ लगातार निकलती चली जाती हैं
    संबंधित वीडियो यहाँ देखा जा सकता है

    • ऐसी स्थिति में कोई एक सही जवाब नहीं होता
      कभी tools और libraries को ठीक-ठाक कर लेने से productivity विस्फोटक रूप से बढ़ जाती है, और कभी बस hardcoding करके आगे बढ़ जाना ज़्यादा तेज़ होता है
      AI tools को polish करने में मदद करता है, लेकिन साथ ही scope भी बढ़ा देता है, इसलिए आखिर में tool management पर उतना ही समय चला जाता है
      आखिरकार यह भावनात्मक टालमटोल (procrastination) की समस्या है। कभी पूरे structure के बारे में सोचना नहीं चाहते, इसलिए छोटी-छोटी fixes दोहराते रहते हैं; और कभी उल्टा, overall design टालकर सिर्फ tools की details सँवारते रहते हैं
    • अफसोस है कि ‘yak shaving’ को अक्सर सिर्फ समय की बर्बादी समझ लिया जाता है
      असल में यह ज़रूरी friction और असुविधा से निपटने की प्रक्रिया भी है
      लेकिन यह भी लगातार परखना चाहिए कि वह असुविधा सच में ज़रूरी है या नहीं
      दोहराए जाने वाले काम को automate करने या छोटा करने में 10~15 मिनट लगाना, दरअसल भविष्य का समय खरीदना है
    • वीडियो उम्मीद के मुताबिक था, फिर भी मज़ेदार है
    • इससे जुड़ा XKCD 349 भी याद आता है
    • ऐसा इसलिए होता है क्योंकि tools को बहुत ज़्यादा नज़रअंदाज़ किया गया है, इसलिए सब टूट चुका है
      आखिरकार technical debt कभी न कभी चुकानी ही पड़ती है, इसलिए उसे थोड़ा-थोड़ा करके चुकाने की आदत डालनी चाहिए

  • engineering आखिरकार कुल्हाड़ी को धार देने की एक लगातार चलने वाली प्रक्रिया है
    Kent Beck की बात की तरह, “पहले बदलाव को आसान बनाओ, फिर आसान बदलाव करो” वाला approach मुझे पसंद है

    • मुझे पहली बार देखे गए codebase को बेहतर बनाने का काम मिला था, लेकिन code इतना बेतरतीब था कि आखिरकार मैंने refactoring से शुरू करने का फैसला किया
      सिर्फ feature जोड़ने की तुलना में code को बेहतर बनाना कहीं ज़्यादा संतोषजनक लगा
    • यह approach अभी AI आधारित coding में कमज़ोर है
      AI एक ही code को कई बार दोहराने पर भी उसे अजीब नहीं मानता, इसलिए structuring या reuse नहीं हो पाता
    • कुल्हाड़ी को शुरू से ही 4 घंटे तक धार देना शायद अलाभकारी हो सकता है
      असल में काम के बीच जब वह कुंद हो जाए, तब फिर से धार देना ज़्यादा व्यावहारिक है
    • programming में मैं ‘कुल्हाड़ी’ (vim जैसे न्यूनतम tools) को पसंद करता हूँ, लेकिन पेड़ काटने में chainsaw कहीं बेहतर लगती है
    • ज़्यादातर सहकर्मी तो pipe से पेड़ काटने जैसे काम करते हैं
      “अभी बहुत व्यस्त हूँ, कुल्हाड़ी तेज़ करने का समय नहीं है!” कहते हुए वे लगातार अलाभकारी तरीके से काम करते रहते हैं

  • यह बात प्रभावशाली लगी: “bug ठीक करने की ललक ही अक्सर पहले tools ठीक करने की ज़रूरत को छिपा देती है”
    Kenneth Stanley की 『Why Greatness Cannot Be Planned』 में भी इस phenomenon की चर्चा है

  • शानदार सलाह है। मैं भी इसे हर दिन अमल में लाने की कोशिश करता हूँ
    लेकिन “अब tools ठीक करना बंद करो, और असली समस्या ठीक करो” वाली अगली सलाह पर ठीक से अमल नहीं हो पाता

  • मैं भी ऐसी स्थिति का अक्सर सामना करता हूँ
    छोटी friction ठीक कर लेने से बाद में समय बचता है, लेकिन इसमें अंतहीन सिर्फ tools से छेड़छाड़ करते रहने का जाल भी है
    असली मुश्किल यह तय करना है कि “अब इतना काफ़ी है” और आगे बढ़ जाना चाहिए

  • tools, मेहनत को कई गुना बढ़ाने वाला माध्यम हैं
    लेकिन ‘yak shaving’ और बेकार manual work के बीच संतुलन खोजना मुश्किल है
    अगर लंबे समय तक वही tools इस्तेमाल करने वाले हो, तो 1% सुधार का भी cumulative effect बड़ा होता है, इसलिए शायद सोचे से ज़्यादा yak shaving की ओर झुकना चाहिए

  • सबसे बड़ा सबक यह है कि all-in-one tools ज़्यादातर अच्छे नहीं होते
    content pipeline के लिए मैंने Make, Airtable, n8n जैसे no-code tools सब आज़माए, लेकिन एक तय स्तर के बाद सब टूट जाते हैं
    आखिर में Python scripts से सीधे API calls करना कहीं ज़्यादा स्थिर निकला
    असली समाधान जटिल tools को ठीक करना नहीं, बल्कि उन्हें सरल और पारदर्शी tools से बदलना था

    • मैंने n8n जैसे tools इस्तेमाल नहीं किए हैं, इसलिए सोचता हूँ क्या कोई ऐसा मामला है जहाँ वे Python से बेहतर हों
    • इसलिए मुझे Airflow सच में बहुत पसंद है

  • debugger से code का flow सीधे देखना बहुत उपयोगी है
    static analysis की तुलना में इसे कहीं ज़्यादा सहज रूप से समझा जा सकता है

    • लेकिन debugger हमेशा मददगार नहीं होता
      variables या breakpoints को लगातार बदलते रहने पर समस्या का असली सार छूट जाना आसान होता है
      debugger का इस्तेमाल सिर्फ hypothesis को verify करने के tool के रूप में करना चाहिए। नहीं तो ‘कुछ प्रगति हुई है’ जैसी गलतफ़हमी में फँस जाते हैं

  • अगर आपको ऐसे लेख पसंद हैं, तो मज़ाक में कहूँगा कि Emacs कभी install मत करना