अच्छे टूल दिखाई नहीं देते

 (gingerbill.org)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • अच्छे टूल वे होते हैं जो उपयोगकर्ता के काम में डूबे रहने के दौरान पृष्ठभूमि में गायब हो जाते हैं, और टूल बनाने वालों का लक्ष्य भी यही होना चाहिए कि उपयोगकर्ता टूल को अलग से महसूस न करे
  • अगर किसी टूल की कमियों को “मज़ेदार puzzle” की तरह पेश किया जाए, तो smart लगने की भावना को वास्तविक productivity समझ लेने का जोखिम बढ़ जाता है
  • vim, emacs, Sublime जैसे editors का चुनाव किसी के व्यक्तिगत workflow के हिसाब से सही हो सकता है, लेकिन अगर उनकी कमियों को भी identity signal की तरह defend किया जाए, तो उनके फायदे-नुकसान को ईमानदारी से देखना मुश्किल हो जाता है
  • TUI और GUI की बहस में भी मौजूदा implementation की कमियों को उस category की मूलभूत सीमा नहीं मानना चाहिए; कई समस्याएँ सिर्फ इसलिए होती हैं क्योंकि अच्छा implementation मौजूद नहीं होता
  • अच्छे defaults वह design हैं जो उपयोगकर्ता का समय बचाते हैं, और बहुत अधिक configurability या steep learning curve तभी स्वीकार करने लायक हैं जब उनका बदला वास्तविक productivity में मिले

अच्छे टूल की कसौटी

  • अच्छे टूल दिखाई नहीं देने चाहिए
    • जब उपयोगकर्ता टूल के बारे में सोचे बिना अपना काम जारी रख सकता है, तब टूल पृष्ठभूमि में चला जाता है
    • किसी खास काम में जैसे ही टूल बाधा बनने लगे, उपयोगकर्ता फिर से टूल को महसूस करने लगता है
  • कमियों को “मज़ेदार puzzle” की तरह दोबारा पैक करने का रवैया टूल के मूल्यांकन को धुंधला कर देता है
    • workaround ढूँढ लेने में मज़ा आना, टूल की quality का प्रमाण नहीं है
    • किसी कमी को शौक की तरह enjoy करना और टूल का सचमुच अच्छा होना, दो अलग बातें हैं

टेक्स्ट एडिटर बहस

  • vim सिर्फ एक उदाहरण है; यही तर्क emacs या Sublime जैसे दूसरे editors पर भी लागू होता है
  • कुछ उपयोगकर्ता vim के फायदों से ज़्यादा उसकी कमियों से निपटने की प्रक्रिया को मज़ेदार puzzle की तरह सराहते हैं
    • ऐसा उदाहरण है जहाँ एक बार के text refactoring के लिए macro बनाना मज़ेदार लगा
    • अगर वही काम Sublime के multi-cursor से 1 मिनट में हो सकता था, या एक simple script से हल हो सकता था, तो macro बनाना वास्तविक productivity के हिसाब से कमजोर पड़ता है
  • editor workflow के लिए महत्वपूर्ण हैं, लेकिन किसी editor को “hacker vibe” की वजह से लगभग धार्मिक भाव से अपनाना खतरनाक है
    • vim या emacs से नए परिचित होने वालों को यह माहौल आकर्षक लग सकता है
    • familiarity कमियों को छिपा सकती है, और उन्हें game की तरह दिखाकर गर्व करने की आदत डाल सकती है

Sublime इस्तेमाल करने के कारण और मानी हुई सीमाएँ

  • Sublime वह editor है जिसे 15 साल से इस्तेमाल किया गया है, और इसे चुनने की कुछ वजहें हैं
    • इसके shortcuts graphical OS environment के superset के काफ़ी करीब हैं, इसलिए apps के बीच जाते समय cognitive switching cost कम रहती है
    • multi-cursor, 99.999% मामलों में, macro से बेहतर लगता है
    • multi-cursor सीधा visual feedback देता है
    • text editing workflow में हल करने के लिए “puzzle” सबसे कम हैं
  • Sublime में भी कमियाँ बनी हुई हैं
    • कभी ज़रूरी tool न होने पर plugin इस्तेमाल करना पड़ता है या text transformation के लिए अलग program का सहारा लेना पड़ता है
    • इन कमियों को “मज़ेदार puzzle” नहीं कहा जाता, बस असुविधा माना जाता है
  • vim basic editing में बेहतर हो सकता है, लेकिन grep जैसी चीज़ों को छोड़कर bulk work में कमज़ोर माना जाता है
    • vim motion, Sublime workflow से बहुत ज़्यादा productive लगता हो, ऐसा महसूस नहीं होता
    • terminal में code लगभग लिखा ही नहीं जाता, इसलिए terminal-oriented editor की व्यावहारिक ज़रूरत नहीं पड़ती

जब टूल पहचान बन जाता है

  • टूल का चुनाव इस बात का झंडा बन सकता है कि आप किस तरह के व्यक्ति हैं
  • “hacker vibe” सिर्फ एक aesthetic नहीं, कभी-कभी tribal signal भी बन जाता है
  • जब पहचान टूल से बँध जाती है, तब उसकी कमियों को स्वीकार करना खुद को नकारने जैसा लगने लगता है
    • इसलिए लोग सिर्फ कमियाँ सहते नहीं, उन्हें defend भी करते हैं और उन पर गर्व भी करते हैं
    • जिन लोगों के लिए टूल उनके व्यक्तित्व का हिस्सा बन गया हो, उनसे टूल पर ईमानदार बातचीत करना कठिन हो जाता है

productive महसूस होना बनाम वास्तविक productivity

  • editor macro का उदाहरण productive महसूस होने और वास्तविक productivity के बीच का अंतर दिखाता है
  • कठिन समस्या सुलझाने पर जो smartness का एहसास होता है, उसे असली output के साथ भ्रमित करना आसान है
    • जो टूल कठिन काम को heroic महसूस कराएँ और smartness को achievement जैसा बना दें, वे शक्तिशाली लग सकते हैं
    • उसी समय वास्तविक काम की गति चुपचाप धीमी हो सकती है
  • ईमानदार कसौटी immersion या smartness नहीं, बल्कि कितना समय लगा और कितनी गलतियाँ हुईं, यह है
    • कई टूल जिन्हें लोग प्रचारक की तरह recommend करते हैं, इस कसौटी पर पीछे रह सकते हैं
  • अगर productivity लक्ष्य है, तो अपनी मान्यताओं पर सचमुच शक करना होगा और देखना होगा कि वास्तव में क्या अधिक productive है

TUI और GUI बहस

  • जो उपयोगकर्ता पूरा दिन terminal में रहते हैं, उनके लिए terminal apps के फायदे स्पष्ट हैं
  • लेकिन ज़्यादातर programmers पूरा दिन terminal में कैद नहीं रहते
  • यह आलोचना कि GUI apps को सिर्फ keyboard से navigate नहीं किया जा सकता, इसका मतलब यह नहीं कि GUI मूल रूप से खराब है
    • कई GUI बस keyboard navigation को पर्याप्त support नहीं करते
    • GUI को keyboard से navigable बनाना कोई मूलभूत रूप से असंभव बात नहीं है
    • कई tool makers या तो इसे implement नहीं करते, या यह नहीं समझते कि mouse बार-बार इस्तेमाल करने की तुलना में keyboard navigation कई बार अधिक productive हो सकती है
  • किसी खास TUI app का किसी खास GUI alternative से बेहतर होना, यह तुलना उचित हो सकती है
  • लेकिन यह मान लेना कि TUI, GUI से मूल रूप से बेहतर है, मौजूदा implementation की सीमाओं को मूलभूत सीमा समझ लेने जैसी गलती है

Linux desktop और configuration का आनंद

  • 2026 में भी “Linux desktop का साल” नहीं आया
  • एक कारण यह है कि कई Linux उपयोगकर्ताओं को config files के साथ छेड़छाड़ करके system बदलना मज़ेदार puzzle लगता है
  • भले कोई खुद उस दौर से गुज़रा हो, समय के साथ वह ऐसे टूल चाहता है जो बस ठीक से काम करें
    • घंटों या दिनों तक configuration करना अब वांछित काम नहीं रह जाता
    • defaults अच्छे होने चाहिए और चीज़ें तुरंत काम करनी चाहिए
    • अगर छोटा adjustment चाहिए भी, तो वह कुछ सेकंड में पूरा हो जाना चाहिए
  • अधिकतम configurability टूल का लक्ष्य नहीं, बल्कि वास्तविक ज़रूरत पड़ने पर इस्तेमाल होने वाला विकल्प होना चाहिए
  • ergonomic tool design का मतलब है अच्छे defaults देना और ज़रूरत पड़ने पर escape hatch भी उपलब्ध कराना

अच्छे defaults और tool makers की ज़िम्मेदारी

  • अच्छे defaults देना tool makers की ज़िम्मेदारी है
  • tool makers आसानी से configuration, tuning और learning का बोझ उपयोगकर्ताओं पर डाल देते हैं
  • यह बोझ अक्सर designer द्वारा निर्णय से बचने का नतीजा होता है
    • “उच्च configurability” कभी-कभी बिना कोई स्पष्ट राय लिए समस्या उपयोगकर्ता पर डाल देने का बहाना बन जाती है
  • अच्छे defaults, उपयोगकर्ता के समय के प्रति सम्मान हैं
    • अगर tool maker एक बार सोच-समझकर निर्णय ले, तो अनगिनत उपयोगकर्ताओं को वही बात बार-बार नहीं सोचनी पड़ती
  • escape hatch उन असली कम मामलों के लिए है जहाँ ज़रूरत असामान्य हो
    • यह सामान्य उपयोग के मामले को सही बनाने का विकल्प नहीं बनना चाहिए

steep learning curve कोई feature नहीं है

  • कुछ लोग यह भी defend करते हैं कि किसी टूल की कठिनाई ही उसकी मूल बात है
    • तर्क यह होता है कि यह गैर-प्रतिबद्ध लोगों को छाँट देता है, और एक बार बाधा पार कर ली तो जीवन भर लाभ मिलता है
  • learning curve एक cost है, गुण नहीं
    • यह cost मूल्यवान हो सकती है, लेकिन उसका प्रतिफल वास्तविक productivity होना चाहिए
    • सिर्फ cost चुका देने से जो संतोष मिलता है, वही reward नहीं होना चाहिए
  • “मैंने इसे महीनों सीखा है, इसलिए इसमें value होनी ही चाहिए, और दूसरों को भी इसे अपनाना चाहिए” — यह तर्क sunk cost को capability की तरह पैक करता है
  • इस स्थिति में puzzle, टूल का इस्तेमाल करके किया जाने वाला काम नहीं रहता, बल्कि टूल खुद बन जाता है

टूल के चुनाव से ज़्यादा महत्वपूर्ण रवैया

  • यह किसी खास टूल के खिलाफ तर्क नहीं, बल्कि टूल को देखने के तरीके की आलोचना है
  • vim, emacs, Sublime — कुछ भी इस्तेमाल किया जा सकता है
    • कसौटी यह है कि क्या वह टूल पृष्ठभूमि में गायब हो जाता है और उपयोगकर्ता को काम जारी रखने देता है
    • यह कसौटी व्यक्तिगत है
  • समस्या उस कहानी में है जो टूल के चुनाव के आसपास बना दी जाती है
    • सीमाओं को feature की तरह दोबारा पैक किया जाता है
    • कमियों को bypass करने की मेहनत को reward की तरह बेचा जाता है
    • टूल “इस्तेमाल की जाने वाली चीज़” से बढ़कर “स्वयं का हिस्सा” बना दिया जाता है
  • यह सबसे स्पष्ट संकेत कि कोई टूल सही तरह सेवा कर रहा है, वह स्थिति है जहाँ उपयोगकर्ता उसे नोटिस करना बंद कर देता है
  • सबसे बेहतरीन टूल वह नहीं जिसके पास सबसे अच्छी कहानी हो, बल्कि वह है जो उपयोगकर्ता को यह भूलने दे कि वह उसे इस्तेमाल कर रहा है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • डेवलपर टीमों के लिए मैंने काफ़ी internal tools डिज़ाइन किए हैं, इसलिए मैं इससे सचमुच सहमत हूँ
    पहले मुझे लगता था कि यूज़र खुद डेवलपर हैं, इसलिए “अंदरूनी संरचना” खुली रखना बेहतर है, लेकिन असल में इससे टीम के लोगों के अपने मुख्य काम में सिर्फ़ रुकावट ही पैदा हुई
    टीम के लोग मेरे बनाए टूल इसलिए इस्तेमाल करते हैं ताकि कंपनी को जो काम चाहिए वह कर सकें; वे किसी ऐसे छोटे टूल के साथ छेड़छाड़ नहीं करना चाहते जिसे वे कहीं और कभी इस्तेमाल भी नहीं करेंगे, और न ही ऐसा करने की कोई वजह है
    अब भी मैं कई escape hatches छोड़ता हूँ, लेकिन internal tools को इस तरह डिज़ाइन करने की कोशिश करता हूँ कि यूज़र स्वाभाविक रूप से pit of success में गिरें
    और error messages, error messages, error messages, साथ ही आम errors के लिए automatic suggestions बहुत महत्वपूर्ण हैं
    यह देखकर निराशा भी होती है कि बहुत से लोग लेख के सिर्फ़ उदाहरणों से चिपके रहते हैं और उसके मूल आशय को नहीं देखते

    • मेरा मानना है कि configurability इस बात पर निर्भर करती है कि वह टूल जिस core work को संभाल रहा है, वह कितना महत्वपूर्ण है
      अगर वह यूज़र को ऐसा काम सीधे करने में मदद करता है जिसे वे महत्वपूर्ण मानते हैं, तो configurability बहुत मूल्यवान हो सकती है; लेकिन अगर वह सिर्फ़ अपेक्षाकृत कम महत्वपूर्ण समस्या को हटाने वाला टूल है, तो वह उल्टा बाधा बन सकती है
      उदाहरण के लिए, Gusto जिस तरह payroll, taxes, और form filing को संभाल लेता है, वह शानदार है, क्योंकि उसमें लगभग सोचने या हाथ लगाने की ज़रूरत नहीं पड़ती
      लेकिन जिन लोगों का मुख्य काम ही payroll, accounting, या tax है, या जो बड़ी कंपनियों के HR, legal, या finance विभागों में काम करते हैं, उनके लिए ऐसी सादगी नुकसानदेह हो सकती है। तब उन्हें टूल से लड़ना पड़ता है, या कम नरमी से कहें तो उनका काम हद से ज़्यादा सरल बना दिया जाता है
      यह भी बड़ा सवाल है कि वास्तव में पैसे कौन दे रहा है, और वह टूल auditability, security, या unwanted behavior को सीमित करने जैसे defensive purposes के लिए है, या creative purpose के लिए। Creative features ज़्यादा आकर्षक होती हैं, लेकिन उन्हें quantify करना कठिन होता है, और end users आम तौर पर उतना बड़ा पैसा देने को तैयार नहीं होते, चाहे वे उनकी भूमिका में कितनी भी मददगार क्यों न हों
    • मेरा भी यही नज़रिया है। यह progressive disclosure का एक रूप लगता है
      तरीका यह है कि sensible defaults दिए जाएँ और ज़रूरत पड़ने पर customize करने दिया जाए। 80% cases से शुरुआत होनी चाहिए, और चाहें तो लोग बदल सकें; यह optional होना चाहिए
      खासकर developer tools में लोग प्रायः strongly opinionated होने से हिचकते हैं। अगर यह भरोसा न हो कि कोई विकल्प “हमेशा सही” है, तो यूज़र से पूछ लेना ज़्यादा सुरक्षित लगता है, और डेवलपर काफ़ी picky भी होते हैं
      अगर आप सोचते हैं, “95% लोग शायद यही तरीका चाहेंगे, लेकिन 5% के पास भी वाजिब कारण हैं, इसलिए सबके लिए बराबरी से रखना चाहिए,” तो आप बहुसंख्यक यूज़र्स के लिए बदतर टूल बना देते हैं
      customization को support करना सोच से कहीं ज़्यादा जटिल है। यह सिर्फ़ bugs का मामला नहीं है; हर अतिरिक्त विकल्प user experience को polish करना और कठिन बना देता है। Testing का दायरा भी बढ़ता है, और ज़्यादा flexible abstractions को डिज़ाइन करना भी कठिन होता है
    • unobtrusive होना इसलिए महत्वपूर्ण है क्योंकि लोग हर दिन दर्जनों टूल्स के बीच आते-जाते रहते हैं
      फिर भी एक संतुलन बनाना पड़ता है, यानी लोगों को सही तरीका अपनाने पर मजबूर करना
      हमेशा कुछ लोग होते हैं जो सही ढंग से काम करने के कारण रुकने पर शिकायत करते हैं, और वे इसे अक्सर समय की बर्बादी मानते हैं
    • यह framing पर निर्भर करता है। खासकर मज़ेदार और कौशल बढ़ाने वाला काम, लोगों की सोच से ज़्यादा मूल्यवान हो सकता है
      संगठन के नज़रिए से लक्ष्य यह है कि कर्मचारी के कंपनी में रहने के दौरान उसकी performance curve सबसे ऊँची बने, जबकि कर्मचारी के नज़रिए से लक्ष्य पूरे career की performance curve बनाना है
      बहुत कुछ इसमें शामिल लोगों के रिश्ते पर निर्भर करता है। अगर सामान ढोने वाला मज़दूर पिछले दिन कसरत करके muscle soreness के साथ आता है, तो मेरी नज़र में नतीजा धीमा और खराब है; लेकिन moving company के नज़रिए से वह लंबे समय में ज़्यादा मज़बूत होकर अधिक काम कर सकेगा, इसलिए यह अच्छा हो सकता है। लेकिन अगर वह उसी दिन नौकरी छोड़ दे या निकाल दिया जाए, तो फिर से बुरा नतीजा बन जाता है
      असली मूल्यांकन यह नहीं है कि macros बेहतर हैं या Sublime में editing; सवाल यह है कि macros बनाने की सोचने की प्रक्रिया क्या दूसरे कामों में भी मदद करती है, और उससे पहले व्यक्ति कर क्या रहा था
      मेरे अनुभव में, जो समय लोग macros इस्तेमाल करने या Vim सीखने में लगाते हैं, उसे सचमुच अर्थपूर्ण काम में लगाने वाले लोग बहुत कम होते हैं। अक्सर वे ऊब चुके होते हैं या burnout के करीब होते हैं, इसलिए उस पल उन्हें कुछ और सोचना अच्छा लगता है जो अधिक दिलचस्प लगे
      समस्या यह नहीं है कि कर्मचारी random scripts इस्तेमाल कर रहे हैं, बल्कि यह है कि उन्हें अपने मौजूदा काम के प्रति urgency या interest नहीं है

  • interface के “गायब हो जाने” का असर वास्तव में उस interface के भीतर बिताए गए समय का फलन है
    लेखक जिस चीज़ पर प्रतिक्रिया दे रहा है, वह डिज़ाइनर या प्रोडक्ट लोगों द्वारा features या complexity जोड़ने से पैदा होने वाले discretionary friction के अधिक क़रीब लगता है
    लेकिन किसी खास काम को हासिल करने के लिए ऐसा friction ज़रूरी भी हो सकता है। merge conflicts सुलझाने की स्थिति सोचिए। और अगर कोई इसे काफ़ी लंबे समय तक इस्तेमाल करे, तो ऐसे “रुकावट वाले” चरण भी पृष्ठभूमि में गायब हो जाते हैं
    ठोस उदाहरण के तौर पर 737 cockpit controls से बेहद घना भरा होता है। विमान खुद भी कई modes रखता है, और उसमें जानबूझकर रखा गया friction भी बहुत है
    लेकिन अगर आप किसी ऐसे pilot से पूछें जिसने 737 को 10 साल से ज़्यादा समय तक संभाला हो, तो वह कहेगा कि वह interface अब उसकी नज़र से ओझल हो चुका है
    अक्सर “खराब” माने जाने वाला Bloomberg Terminal भी ऐसा ही है। मेडिकल क्षेत्र में भी, जो लोग दिन में 8 घंटे से ज़्यादा MR scanning software इस्तेमाल करते हैं और हर control तक तुरंत पहुँचना चाहते हैं, उनके लिए बटन से भरा interface ही बिल्कुल सही समाधान हो सकता है
    प्रोग्रामर बहुत जल्दी अपनी खुद की experience और preference को सामान्य नियम मानकर दूसरों पर लागू करने लगते हैं
    स्रोत: IDEO में consumer और professional software 10 साल तक डिज़ाइन किया है

    • “discretionary friction, यानी डिज़ाइनर या प्रोडक्ट लोगों द्वारा functionality या complexity जोड़ना” वाली अभिव्यक्ति कहीं ज़्यादा सटीक है
      लेख इसे यूज़र के पक्ष से देखता है, और मानता है कि कुछ यूज़र ऐसे होते हैं जो core functionality की तुलना में अंतिम मूल्य में कम अहम “extra” features को सीखने का आनंद लेते हैं
      “अगर लोग vim, emacs वगैरह को सचमुच अच्छा और productive मानकर इस्तेमाल करते हैं, तो मैं उसकी आलोचना नहीं करूँगा। लोग स्वाभाविक रूप से उसी चीज़ में सबसे सहज होते हैं जिससे वे परिचित हों। लेकिन मैं जिन लोगों की बात कर रहा हूँ, वे उसी परिचय के कारण टूल की कमियाँ देख नहीं पाते, और उन कमियों को किसी गेम की तरह दिखाकर उनकी प्रशंसा करने लगते हैं” — यही हिस्सा मूल बात है

  • लंबे समय से टर्मिनल इस्तेमाल करने वाले के नज़रिए से देखें तो यह ज़्यादा हैरानी की बात नहीं कि लोग इसे नहीं समझते। बातचीत आमतौर पर कुछ ऐसी चलती है
    “टर्मिनल में एक साधारण command से यह-वह काम किया जा सकता है”
    “मेरे FrobnicatorStudio में उसके लिए Ctrl+Alt+So shortcut है”
    और फिर यह अंतहीन रूप से “Vim में चार बार दबाकर 24 लाइनों को मिटाया जा सकता है” बनाम “Sublime में multi-cursor है” जैसी लगभग बेमानी तुलना तक पहुँच जाती है
    शायद सही मुद्दा यह है कि टर्मिनल छोटे-छोटे command-line tools को pipeline में जोड़कर अनगिनत use cases कवर कर सकता है, लेकिन वहाँ तक सहज होने में लगभग एक साल की learning curve लगती है
    उस स्तर पर पहुँचने के बाद आप औसत GUI user से कहीं ज़्यादा productive हो सकते हैं, लेकिन वहाँ तक पहुँचने के लिए समर्पण और तकलीफ़ दोनों चाहिए, और बहुत से लोग यह अपनी मर्ज़ी से नहीं बल्कि मजबूरी में करते हैं
    मेरे मामले में, मेरी पहली नौकरी में ssh के जरिए ग्राहक सर्वर संभालने पड़ते थे, और उन सर्वरों पर बस न्यूनतम चीज़ें installed थीं। कई बार vim भी नहीं, सिर्फ vi होता था, और उस माहौल में असरदार ढंग से काम करना सीखने के अलावा कोई विकल्प नहीं था
    अगर वह अनुभव न होता, तो मुझे यकीन नहीं कि मैं टर्मिनल में काम शुरू करने की शुरुआती तकलीफ़ झेलता

    • इसका रिश्ता कुछ-कुछ Wireshark जैसा है। real-time capture और display, और clickable GUI की आकर्षकता समझ में आती है
      लेकिन एक बिंदु पर लगा कि मैं वहाँ बहुत ज़्यादा समय बर्बाद कर रहा हूँ। फिर tshark और jq, पुराने bash/awk/grep और gnuplot के साथ दोबारा command line पर लौट आया, और बाद में Python इस्तेमाल किया, लेकिन तब भी tshark output ही इस्तेमाल करता रहा
      आखिरकार मैं pcap और pcapng parser, ethernet-ip-udp/tcp handling, और पूरा Java IDE तक बना बैठा, और फिर पीछे मुड़कर नहीं देखा
      जिन भी data capture और exploration tools को बार-बार इस्तेमाल करना पड़ता है, उनमें मैंने यही घुमावदार रास्ता बार-बार तय किया है
      लगता है tool improvement के इस iterative phase से सिर्फ मैं ही नहीं गुज़रता, और काश इसके लिए कोई अच्छा-सा नाम वाला पैमाना होता
    • मुझे नहीं लगता कि यह तर्क ग़लत है, लेकिन FrobnosticatorStudio वाले पक्ष की बात में भी दम है
      टर्मिनल आपको सैद्धांतिक रूप से अनंत ज़्यादा क्षमता देता है, लेकिन हकीकत में जो काम आप नियमित रूप से करते हैं, उनकी संख्या शायद 20 के आसपास ही होती है। अगर वही 20 काम सब कुछ हैं, तो learning curve की वजह से लोगों को मनाना कठिन है
      उदाहरण के लिए, अगर आप टर्मिनल में हैं और build script ढूँढना चाहते हैं, तो cat packages.json | jq .scripts जैसा कुछ कर सकते हैं
      टर्मिनल के भीतर यह काम का है, लेकिन अगर आप VSCode में हैं तो ctrl-p -> packages.json -> ctrl-f -> scr से काम हो जाता है, और असल में keypress भी कम लगते हैं
      लोगों का workflow सचमुच बहुत निजी होता है, इसलिए मैं किसी से इसे बदलने को नहीं कहूँगा, लेकिन मेरे मामले में मुझे ऐसे tools ज़्यादा पसंद हैं जो project structure को समझते हैं, बजाय उन tools के जो project को सिर्फ text की तरह देखते हैं, इसलिए IDE मेरे लिए ज़्यादा उपयुक्त है
    • अगर command-line apps और text user interface apps में फ़र्क करें, तो यह लेख खासकर दूसरे वाले प्रकार की बात करता दिखता है
      command-line apps से मतलब grep, sort, cp, git, ls, tar जैसे tools हैं, जिनसे shell में command लिखकर interaction होता है। इनके सामान्य इस्तेमाल का तरीका पता हो तो इन्हें script में भी इस्तेमाल किया जा सकता है, और इसीलिए इन्हें pipeline में जोड़ा जा सकता है
      text user interface apps से मतलब Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code जैसी interactive apps हैं, जो इस्तेमाल के दौरान टर्मिनल पर पूरा कब्ज़ा कर लेती हैं
      इन्हें pipeline में नहीं जोड़ा जाता। या ज़्यादा सही कहें तो इनके सामान्य इस्तेमाल के तरीके में इन्हें pipeline में नहीं डाला जाता। अगर ऐसा संभव होता भी है, तो शायद इसलिए कि उस app ने TUI से अलग कोई command-line interface भी दिया हो
    • बात ठीक यही है। GUI tools की non-composability और non-standardization सबसे बड़ी समस्या है
      हर समस्या हल करते समय एक ही toolbox इस्तेमाल करने लायक बनने में समय लगता है, लेकिन आखिर में वही ज़्यादा efficient साबित होता है
      फिर भी लोगों को मनाना मुश्किल है। जब तक आप कोई ऐसा मसला command-line tools से हल न कर लें जिसे किसी और तरह सुलझाना कठिन हो, तब तक उसकी सादगी को समझना आसान नहीं होता
    • मैं लगभग 20 साल से command line पर काम कर रहा हूँ, और उनमें से कुछ साल Vim मेरा मुख्य editor था, लेकिन आखिरकार मैं Sublime पर चला गया और फिर पीछे मुड़कर नहीं देखा
      फिर भी मैं हर तरह के काम में command line का बहुत इस्तेमाल करता हूँ। आमतौर पर एक konsole window खुली रहती है, और जब build या test चलाना होता है तो Sublime के “build system” support की बजाय alt+tab करके उधर चला जाता हूँ
      Vim अब सिर्फ तब इस्तेमाल करता हूँ जब ssh चाहिए होता है या फ़ोन पर Termux इस्तेमाल कर रहा होता हूँ
      Sublime, VSCode जैसे extensible GUI tools भी अनगिनत use cases कवर करते हैं, बल्कि वे अक्सर ज़्यादा stable और reproducible execution environment देते हैं
      मुझे लगता है यह बहस कभी खत्म नहीं होती क्योंकि लोग आम तौर पर बंद सोच रखते हैं। दूसरे के नज़रिए से देखना मुश्किल होता है, और यह गंभीरता से मानना उससे भी कठिन कि शायद आप ग़लत हो सकते हैं
      आखिरकार यह मुद्दा सिर्फ beginners के लिए महत्वपूर्ण है। जब आप काफ़ी अभ्यस्त हो जाते हैं, तब चाहे जो इस्तेमाल करें, productivity bottleneck tool नहीं रह जाता। हाँ, अगर tool ed हो तो शायद बात अलग हो

  • “लोग यह नहीं समझते कि keyboard navigation बार-बार mouse पकड़ने से कहीं ज़्यादा productive है” — इस दावे पर, जो लोग खुद को ज़्यादा productive बताते हैं उनमें से काफ़ी लोगों ने वास्तव में इसे कभी मापा ही नहीं होता
    वर्षों से keyboard बनाम mouse navigation पर बहुत प्रतिस्पर्धा और बहस होती रही है, और test design की बारीकियों के हिसाब से कभी एक पक्ष जीतता है, कभी दूसरा, और कई बार अंतर काफ़ी बड़ा भी होता है
    असली नतीजे देखने से पहले, उपयोगकर्ता जिस तरीके को ज़्यादा productive बता रहे थे, वही हार जाता है — ऐसा भी कम नहीं हुआ

    • जिस क्षण आपको लगे कि इसे मापना चाहिए, शायद उसी क्षण आप मूल बात चूक गए
      मकसद किसी absolute productivity metric का पीछा करना नहीं, बल्कि ऐसा माहौल पाना है जो flow न तोड़े
      बहुत से लोगों के लिए mouse पकड़ना flow तोड़ देता है और अटपटा लगता है, और यह सिर्फ 1 सेकंड धीमा होने से भी बुरा हो सकता है, क्योंकि यह दिमाग़ में चल रहे context से बाहर कर देता है
      मेरे मामले में, काम करते समय mouse इस्तेमाल करना स्वाभाविक है, इसलिए पूरे workflow को इस तरह बदलना कि हर navigation keyboard से हो, सिर्फ इस उम्मीद में बहुत बड़ा अतिरिक्त प्रयास है कि शायद कुछ स्थितियों में थोड़ा-सा समय बचे
    • मुझे यह काफ़ी reductionist रवैया लगता है। अगर किसी tool का मुख्य उपयोग text-based है, तो keyboard navigation ज़्यादा productive हो सकती है
      word processor, IDE, file manager जैसे tools में, जहाँ पढ़ना, टाइप करना, और पढ़े-लिखे गए text को process करना केंद्र में होता है, यह दिखाया जा सकता है कि shortcut सीख लेने पर keyboard navigation ज़्यादा तेज़ और स्वाभाविक हो जाती है
      इसके उलट, जिन tools में text नहीं बल्कि visual information मुख्य होती है, वहाँ keyboard बनाम mouse की बहस काफ़ी हद तक mouse के पक्ष में झुक जाती है
      फिर भी ऐसे क्षण आते हैं जब असरदार shortcuts menu और icons से कहीं ज़्यादा उपयोगी होते हैं। CAD या 3D modeling software को देखें: उपयोगकर्ता के 90% काम में visually represented spatial data से काम लेना होता है, लेकिन अगर tool बदलने या tool setting संशोधित करने वाले shortcuts पता हों, तो काम बहुत तेज़ हो जाता है और nested menus में बार-बार खोदना नहीं पड़ता

  • चिंता इस बात की लगती है कि लेखक अपनी चुनी हुई tool से परिचित होने को उसके बेहतर होने के सबूत से गड़बड़ा रहा है
    व्यावहारिक रूप से हर tool में trade-off होते हैं, और अगर कोई user tool X को tool Y से ज़्यादा पसंद करता है, तो इसका कारण उसका मूर्ख होना नहीं बल्कि यह हो सकता है कि वह उस tool की उन affordances का बेहतर इस्तेमाल करता है जिन्हें सिर्फ़ अनुभवी लोग समझते हैं
    अगर किसी developer को vim, emacs, और Sublime Text में से हर एक को 10-10 साल इस्तेमाल करने दिया जाए, तो शायद वह यक़ीन से न कह पाए कि कौन बेहतर है। उसकी निजी पसंद ज़रूर होगी, लेकिन वह यह भी समझा पाएगा कि दूसरे लोग अलग tool क्यों पसंद करते हैं
    यह बहस कुछ ऐसी लगती है जैसे किसी ने अपरिचित software को कभी सच में ठीक मौका ही न दिया हो
    मेरे हिसाब से लंबे समय से काम कर रहे अनुभवी लोगों की पहचान यह है कि उनमें हर software और उसे बेहतर बनाने के वादों के प्रति एक हल्का-सा अविश्वास आ जाता है। लंबे समय में हर software साधारणपन की ओर सिमट जाता है

    • लेख किसी खास tool की नहीं, बल्कि एक mindset की आलोचना कर रहा था। इसने कहीं नहीं कहा कि Sublime, Vim से बेहतर है
      बस इतना कहा गया था कि tool की friction को feature की तरह देखने वाली सोच से सहमति नहीं है
      उसी तर्क को लेकर मैं यह भी दिखा सकता हूँ कि Vim मेरे लिए एकदम सही editor है। क्योंकि जब मैं Vim इस्तेमाल करता हूँ, तो वह दिखता नहीं है, और कुछ हद तक इसलिए भी कि मैंने Vim को अपनी पसंद का tool बना लिया है
      उसने Sublime को अपनी पसंद का tool बना लिया। फिर भी मूल बात वही रहती है। अगर आप कोई ऐसी चीज़ बना रहे हैं जिसे दूसरे लोग इस्तेमाल करेंगे, तो उस tool को user के लिए अदृश्य बना देना एक बहुत शक्तिशाली गुण है
    • “लंबे समय में हर software साधारणपन की ओर सिमट जाता है” इस बात को दूसरे नज़रिये से भी देखा जा सकता है। शायद यह ठीक ही है, और शायद अनुभवी लोग यही जानते हैं
      साधारण का मतलब है “औसत या सामान्य गुणवत्ता”
      अगला CRUD app बनाते समय ज़रूरी नहीं कि आपको सबसे नया, सबसे बेहतरीन, असाधारण tech ही चाहिए हो
    • “लेखक परिचित होने को अपने tool के बेहतर होने के सबूत से गड़बड़ा रहा है” — यह सचमुच ऐसी बात नहीं है जो मैंने कही या संकेत की हो। कृपया वह हिस्सा quote करें जहाँ ऐसा कहा गया हो
      अगर मेरी लिखी पंक्ति quote करें, तो वह यह है: “जो बात मुझे हैरान करती है, वह यह है कि बहुत से लोग उस friction — यानी tool की सीमाओं को पार करने की मेहनत — को ‘मज़ेदार’ हिस्सा मान लेते हैं, और उसे ऐसे पेश करते हैं जैसे वही tool की महानता का सबूत हो।”
      इसका संबंध इस बात से नहीं है कि मैं या कोई और किसी tool को क्यों चुनता है; यह उस रवैये के बारे में है जिसमें खामियों को puzzle game की तरह bypass करने वाली चीज़ समझा जाता है

  • अच्छे tools के maintainers अक्सर उन्हें users जिस तरह देखते हैं, उससे कहीं अधिक नकारात्मक ढंग से चीज़ों को ग्रहण करते हैं
    “आज 10 लोगों ने bug या missing feature की शिकायत की और 9990 लोगों ने बिना समस्या के इस्तेमाल किया” और “आज 10 लोगों ने शिकायत की और सिर्फ़ 90 लोगों ने बिना समस्या के इस्तेमाल किया” — इन दोनों में फ़र्क समझना मुश्किल होता है। लेकिन user satisfaction को 90% से 99.9% तक ले जाने के लिए जिस मेहनत की ज़रूरत होती है, वह बहुत अलग होती है
    मुझे गहरा शक है कि यही कई open source maintainer burnout का बड़ा कारण है
    असंतुष्ट users, संतुष्ट users की तुलना में कहीं ज़्यादा नज़र आते हैं, और नए users बढ़ने की रफ़्तार की तुलना में bug reports और feature requests पैदा करने वाले असंतुष्ट users का अनुपात घटता जाता है
    आख़िर में maintainer को एक तरह का भ्रम होने लगता है कि चाहे जितना सुधार करो, कुल गुणवत्ता का महसूस होना बदलता ही नहीं, और आगे काम करते रहने की प्रेरणा कम होने लगती है
    इस समस्या का अच्छा समाधान मुझे नहीं पता। साफ़ जवाब यह है कि जब चीज़ें अच्छी तरह काम करें तो उनकी ज़्यादा बार तारीफ़ की जाए, लेकिन व्यवहार में यह उस तरह की collective action problem के क़रीब है जो आसानी से हल नहीं होती
    निजी तौर पर, जब कोई चीज़ अच्छी तरह काम करती है, तो मैं जानबूझकर बार-बार और उत्साह से positive feedback देने की कोशिश करता हूँ, लेकिन जब तक सब लोग ऐसा न करें, बड़ा फ़र्क लाना मुश्किल है

  • यह उद्धरण याद आता है
    “हम हमेशा उस झुके हुए, घबराए हुए, दीन-हीन व्यक्ति को देख लेते हैं, और शायद कहते हैं, ‘कितना विनम्र है!’ लेकिन सचमुच विनम्र व्यक्ति दिखता ही नहीं। दुनिया उसे जानती ही नहीं।”
    ~ Tito Colliander

  • “कि कोई tool आपकी अच्छी सेवा कर रहा है, इसका सबसे साफ़ संकेत यह है कि आप उसके प्रति सचेत रहना बंद कर देते हैं — यानी वह अदृश्य हो जाता है। आप उसकी खामियों को शौक़ में नहीं बदलते, इसलिए उनकी प्रशंसा भी नहीं करते; बस हल्की झुंझलाहट के साथ उन्हें bypass कर लेते हैं” — यह बात tool से ज़्यादा user dependency पर आधारित लगती है
    बेशक अलग-अलग tools अलग-अलग users को आकर्षित करेंगे, और शायद कोई मज़बूत correlation भी मापा जा सके
    साथ ही, इस दृष्टिकोण में संतुलन की कमी लगती है। tool कभी भी पूरी तरह perfect नहीं होता; कभी-कभी आपको एहसास होता है कि उसे बेहतर बनाया जा सकता है, और फिर आपको उस बदलाव को लागू करने और उसके आपकी आदतों पर पड़ने वाले असर के बीच संतुलन बैठाना होता है
    जितना लंबा समय आप उसे इस्तेमाल करेंगे, शायद ऐसे बदलाव उतने छोटे होते जाएँगे, लेकिन इस्तेमाल करने का तरीका पूरी ज़िंदगी में बदलता रहता है, और tool का उसके साथ बदलना स्वाभाविक है

  • यह काफ़ी अनोखी व्याख्या है
    यह अजीब है कि लेखक Vim के “दिखाई देने” पर अटका हुआ है, जबकि यह संकेत देता है कि Sublime के multi-cursor और features ऐसे नहीं हैं। सिर्फ़ इसलिए कि दिमाग़ को अब उसके बारे में न सोचने की ट्रेनिंग मिल गई है, इसका मतलब यह नहीं कि वह कम दिखाई देने वाला है
    multi-cursor बहुत-से tools में default feature नहीं है, और उसे प्रभावी ढंग से इस्तेमाल करना भी सीखना पड़ता है। Vim key bindings की तरह ही
    इसके अलावा Vim सिर्फ़ terminal-only users के लिए एक TUI विकल्प से बढ़कर है। यह उन लोगों के लिए key bindings भी है जिन्होंने keyboard को अपने शरीर का स्वाभाविक विस्तार बना लिया है और जो mouse पर बार-बार आगे-पीछे नहीं जाना चाहते। जैसे 15 साल से Sublime इस्तेमाल करने वाले user के लिए multi-cursor ऐसा हो सकता है

    • मेरा मतलब वह नहीं था। मैंने पूरे Vim का नहीं, बल्कि Vim macros का उदाहरण दिया था
      “मैंने लोगों को यह कहते देखा है कि one-off text refactoring problems को संभालने के लिए macro बनाना कितना ‘मज़ेदार’ है। लेकिन जब मैंने देखा कि वे क्या कर रहे हैं और उसमें कितना समय लग रहा है, तो मेरी ईमानदार प्रतिक्रिया यही थी: मैं यह Sublime के multi-cursor से 1 मिनट में कर लेता, या बस एक छोटा script लिख देता।”
      और “जो बात मुझे हैरान करती है, वह यह है कि बहुत-से लोग उस friction, यानी tool की limitations को bypass करने की कोशिश को, ‘मज़ेदार’ हिस्सा मानते हैं और उसे tool के महान होने के सबूत की तरह पेश करते हैं।”
      अगर आप Vim macros को प्रभावी ढंग से इस्तेमाल कर सकते हैं, तो अच्छी बात है। लेकिन अगर आप दशकों तक Vim इस्तेमाल करने के बाद भी ऐसा नहीं कर पाते, तो उसे ‘मज़ेदार’ हिस्सा बताकर प्रचार नहीं करना चाहिए
    • ख़ास तौर पर अजीब बात यह है कि मुझे लगभग याद नहीं कि मैंने किसी को Vim को सुलझाने में मज़ेदार puzzle के रूप में वर्णित करते सुना हो
      सबसे आम भावना यही होती है कि इसकी learning curve है, लेकिन आख़िरकार यह उसके लायक है
    • लेख में लिखा है, “99.999% मामलों में multi-cursor सचमुच macro से बेहतर है। क्योंकि यह direct visual feedback देता है”
      इसका मतलब मुझे समझ नहीं आया। Vim macro भी बनाते समय direct visual feedback देता है। आप recording करते हुए सामान्य तरीके से edit करते हैं, और बाद में उसी edit को replay करते हैं
      यह तकनीकी रूप से संभव है या नहीं कि text पर पड़ने वाला real-time effect देखे बिना macro इस्तेमाल किया जाए, मुझे नहीं पता, लेकिन मैंने कभी ऐसा नहीं किया
      जिज्ञासावश मैंने multi-cursor देखा, और इसका फ़ायदा शायद यह लगता है कि यह एक ऐसा interface है जिसे समझाना आसान है। व्यवहार में, इसकी जगह कई Vim commands इस्तेमाल की जाएँगी
      मैं इस बात से सहमत हूँ कि ज़्यादातर उन कामों में जहाँ multi-cursor इस्तेमाल किया जा सकता है, वहाँ वह macro से बेहतर हो सकता है। लेकिन आम तौर पर मैं ऐसे कामों के लिए macro इस्तेमाल नहीं करता
      macro से मैं जो ज़्यादातर काम करता हूँ, वे multi-cursor से हो ही नहीं सकते, ऐसा लगता है
      अगर कोई उदाहरण हो कि “इस स्थिति में multi-cursor शानदार है और Vim में उसका अच्छा विकल्प नहीं है”, तो मैं ग़लत साबित होना चाहूँगा
    • सहमत हूँ। पहले मैं Vim macros का काफ़ी इस्तेमाल करता था, लेकिन Helix पर जाने के बाद से मैं हमेशा multi-cursor इस्तेमाल करता हूँ और macros लगभग नहीं के बराबर
      इसका यह मतलब नहीं कि multi-cursor की कोई learning curve नहीं है। अभी भी आपको सोचना पड़ता है कि cursor को सही जगह कैसे रखा जाए
    • पढ़ते-पढ़ते बीच में आकर लगा कि ज़्यादातर बातें AI की बकवास जैसी हैं

  • “अदृश्य” वाली अभिव्यक्ति मैंने पहले emacs magit का वर्णन करते समय इस्तेमाल की थी
    यह git output के ऊपर एक पतली layer की तरह है, जो प्रकट होती है, UI state से parameters का अनुमान लगाती है, सामान्य git command चलाती है, और फिर गायब हो जाती है
    हल्का और तेज़ है। बड़े projects में शायद नहीं, लेकिन ऐसा कहा जाता है