उत्पादकता की मृगतृष्णा

• Facebook के दिग्गज इंजीनियर Bob ने जटिल development environment के बिना भी Facebook Groups लॉन्च किया और hackathon में लगातार नतीजे दिए
• उन्होंने सिर्फ बेसिक Sublime Text और printf logs का इस्तेमाल किया; syntax highlighting गलत थी और live reloading व debugger भी नहीं थे
• दूसरी ओर, आसपास के developers Vim syntax highlighting और snippets, tmux, mosh, hphpd shortcuts, Git aliases जैसी जटिल tool configurations को productivity की कुंजी मानते थे
• Bob की hackathon जीत में editor settings से ज्यादा product sense और intuition, यानी क्या बनाना है यह तय करने की क्षमता, काम आई
• नए काम करने के तरीके बदलाव ला सकते हैं, लेकिन अंतिम परिणाम सही समस्या हल करने से आते हैं

---

जटिल tools और वास्तविक नतीजों का अंतर

• Bob Facebook Groups लॉन्च करने वाले बेहद prolific engineer और hackathon में लगातार output देने वाले legendary व्यक्ति थे
• उस समय productivity पर बहुत ध्यान देने वाले एक सहकर्मी ने Facebook की PHP dialect Hack के लिए खुद बनाई हुई Vim syntax highlighting और snippets का इस्तेमाल किया
  • उन्होंने mosh के ऊपर tmux चलाया, और custom hphpd shortcuts व Git aliases तक configure किए
• इसके उलट Bob का काम करने का तरीका बेहद सरल था
  • वे बिना किसी अलग setup के Sublime Text इस्तेमाल करते थे, जिसमें code colors का करीब आधा हिस्सा गलत दिखता था
  • live reloading या debugger के बजाय वे code में printf डालते और logs आने का इंतज़ार करते थे
• उस दिन hackathon में Bob जीते; याद है कि उनका work Facebook Groups में खरीद-बिक्री posts को support करने वाला feature था
  • यह feature बाद में Facebook Marketplace में विकसित हुआ

कैसे से ज्यादा, क्या बनाया जाए

• जटिल tools पर ध्यान देने से काम करने के तरीके यानी कैसे में फंसकर काम के लक्ष्य यानी क्या को नजरअंदाज किया जा सकता है
• Bob की ऊंची productivity का असली कारण editor settings नहीं, बल्कि product sense और intuition था
• X पर हर दिन कोई नया काम करने का तरीका आता है जो मानो सब कुछ बदल देगा, और उनमें से कुछ सचमुच बदलाव ला भी सकते हैं
• लेकिन सबसे अहम चीज tools या work process खुद नहीं, बल्कि सही समस्या हल करना है

[GN⁺]

Hacker News की राय

• टूल्स को संजोकर रखने वाले कारीगर और टूल्स के प्रति आसक्त लोगों को दो हिस्सों में बाँटना गलत है। अच्छे टूल्स खिलौने नहीं, बल्कि उद्देश्य तक पहुँचने के साधन होते हैं, और मैंने भी अपने workflow के मुताबिक shell scripts, Emacs functions, window layout tools आदि बनाने में कई दिन लगाए हैं
  नतीजा यह हुआ कि syntax highlighting, code navigation·analysis, screen layout, Git operations सिर्फ कुछ key presses में होने लगे और ध्यान भंग करने वाली चीजें गायब हो गईं। chair, shell prompt, editor जैसे काम के माहौल में निवेश करना चाहिए, लेकिन एक बार आरामदायक हो जाने पर उसे भूलकर असली समस्या पर ध्यान देना चाहिए
  हालांकि, अंतहीन tool tweaking इस बात का संकेत हो सकता है कि आप भारी और गैर-रोचक कामों से बच रहे हैं, और यह टूल्स की गलती जैसा कोई सीधा-सादा मामला नहीं है

  • अगर नई नौकरी में नया tech stack और Windows laptop मिले तो क्या करेंगे? करियर की शुरुआत में मैंने दिए गए माहौल के बुनियादी टूल्स से ही कुशलता से काम करना सीखा था, और वास्तव में टूल्स को खुद चुनने का मौका बहुत कम मिला। cross-platform tools भी JetBrains product line को छोड़कर अक्सर असंगत रहे हैं
  • यह समुराई और निंजा के फर्क जैसा लगता है। समुराई तलवार को आत्मा का विस्तार मानते थे, लेकिन निंजा ज़रूरत पड़ने पर उसी तलवार से चीज़ें मोड़कर खोल भी लेते थे। आज की अर्थव्यवस्था में समुराई-शैली का tool view फिट नहीं बैठता
  • टूल्स का आनंद लेकर इस्तेमाल करना महत्वपूर्ण है। productivity 10 गुना न भी बढ़े, काम पर ध्यान टिके और प्रक्रिया का आनंद मिले, यही मुख्य बात है
    खासकर LLM युग के टूल्स आपको कई agents और terminals के बीच लगातार घूमाते रहते हैं। यह बार-बार context switching आनंद और flow state छीन लेता है, इसलिए अच्छा होगा अगर कोई इसका समाधान ढूँढ़ ले
  • अक्सर लगता है कि शुरुआती लोग मान्यता पाने और गंभीरता से लिए जाने के लिए ज़रूरी चरण छोड़ देना चाहते हैं। ऐसा दिखना और सचमुच वैसा होना अलग बातें हैं, और skill बनाते समय आजीविका भी संभालनी पड़ती है
  • तकनीक में महारत के बाद अच्छे टूल्स स्वयं एक बड़ा आनंद बन जाते हैं। इसके उलट, अनुभवी लोग कभी-कभी अनुपयुक्त टूल्स से भी आश्चर्यजनक रूप से अच्छे नतीजे निकाल लेते हैं

• मैंने बहुत से तकनीकी लोगों को वास्तव में कुछ बनाने से ज्यादा समय environment setup optimization पर खर्च करते देखा है, और मैं खुद भी ऐसा कर चुका हूँ। यह सोचना गलत है कि coding time का 90% typing है, इसलिए input speed बढ़ानी चाहिए; समय का 90% सोचने में, और उसमें से ज़्यादातर पढ़ने में लगना चाहिए

  • software समस्याओं के समाधान का मूर्त रूप है, इसलिए पहले यह तय करना चाहिए कि हल कौन-सी समस्या करनी है। code वर्तमान समस्या-समझ और समाधान की स्पष्टता·उपयुक्तता का एक snapshot है, जो भविष्य के स्वयं सहित सबको दिखता है
    सही समय पर coding, पहले से समझे गए समाधान को मूर्त रूप देने वाली typing के करीब होती है
  • पहले मैं settings को लेकर आसक्त था, लेकिन AI इस्तेमाल करने के बाद अब ऐसी शानदार चीजें बना रहा हूँ जो पहले नहीं बना पाता। दूसरी ओर, base code की समझ और पुरानी skills धीरे-धीरे कमजोर हो रही हैं, और नई तकनीकों पर हैरानी तो होती है पर उन्हें गहराई से सीख नहीं पाता
    इस अर्थ में AI एक और तरह का environment improvement भी है, क्योंकि उसने शुरुआत की बाधा कम कर दी। पहले जब QA role से developer बनने के लिए यूरोप यात्रा करते हुए InterviewCake पढ़ रहा था, तब भी problem solving से ज्यादा समय editor settings सँवारने में बर्बाद किया था
    यह शायद ADHD का लक्षण भी हो सकता है। हाल की दवा-चिकित्सा के बाद productivity बहुत बदल गई, और यह सोचकर आँखों में आँसू आ गए कि असली काम करने के बजाय जीवन का आधा हिस्सा settings को परफेक्ट बनाने में गँवा दिया
  • वास्तविक productivity और productivity का एहसास अलग-अलग चीजें हैं। Vim या Emacs में फुर्ती से code चलाने पर खुद को hacker जैसा महसूस हो सकता है, पर इसका मतलब यह नहीं कि आप productive हैं। भारी token budget के साथ AI agents के दर्जनों समूह चलाने से भी यह गारंटी नहीं मिलती कि output काम करेगा या समस्या सुलझाएगा
  • साधारण CRUD application developers में ज़्यादातर के लिए क्या समय का 90% सोचने और पढ़ने में जाना चाहिए, इस अनुपात की सटीकता को लेकर मुझे यकीन नहीं है
  • सोचना और typing अक्सर साथ-साथ होते हैं। कई लोग code लिखते और बदलते हुए समस्या पर बेहतर तर्क कर पाते हैं, और यही एक कारण है कि LLM द्वारा बनाए गए code को पूरा पढ़ लेने पर भी code understanding काफ़ी घट सकती है

• ऐसे VC-funded कंपनियाँ मौजूद हैं जो असल में ऐसा product नहीं बना पातीं जिसे लोग इस्तेमाल करें या जिसके लिए पैसे दें। वे अपनी valuation को सही ठहराने के लिए यह दिखाती हैं कि वे कितनी व्यस्त और productive हैं, और AI craze भी शायद उसी संदर्भ का हिस्सा है क्योंकि वह क्या बनाया जाए, उससे ज्यादा productivity और methods पर केंद्रित है
  https://components.news/the-gamer-and-the-nihilist/ ऐसे nihilistic startups की तुलना उन game studios से करता है जो ऐसे products बनाते हैं जिनके लिए लोग पैसे देते हैं और जिन्हें वे इस्तेमाल करते हैं। ऐसी अर्थव्यवस्था में जहाँ productivity apps, Product Hunt के लगभग 40% results बनाते हैं, असल में कुछ बनाने की बजाय ऐसा दिखने पर श्रम लगाया जाता है जैसे कुछ बनाया जा रहा हो

  • game developers भी टूल बनाने में भारी मेहनत लगाते हैं, बस उनका मुख्य विषय text editor नहीं होता
  • सोचता हूँ कि इस उपमा में वे लोग कहाँ आएँगे जो game खेलने से ज्यादा perfect gaming setup बनाने में समय लगाते हैं, या वे audio enthusiasts जो संगीत से ज्यादा पूरी ज़िंदगी perfect equipment खोजते रहते हैं
  • इसे bubble से ज्यादा लंबे समय से दोहराई जा रही signal manipulation कहना ठीक होगा। यह हमेशा से था और आगे भी रहेगा

• productivity tools को बस इतना बनाना या इस्तेमाल करना चाहिए कि पीछे न छूटें; उससे ज्यादा को मैं जाल मानता हूँ। पहले मैं तिमाही में एक बार समीक्षा करता था, लेकिन AI के बाद अब हफ्ते में 1~2 दिन tools सुधारने जैसे meta-work में जा रहे हैं, और उम्मीद है कि संबंधित tools standardize होने पर यह कम होगा
  अगर tool expert की छवि बहुत मजबूत हो जाए, तो न सिर्फ असली मूल्य वाले काम छूट सकते हैं बल्कि लोग आपको किसी गुप्त productivity मंत्र वाले व्यक्ति की तरह देखने लगते हैं। अगर फर्क उम्मीद जितना न निकले, तो आपकी दूसरी समझ पर भी भरोसा कम हो सकता है

• जितना कम समय मैं कंप्यूटर के सामने रहा, उतना ज्यादा काम निपटाया, और monitors को 3 से 1 करने पर productivity काफ़ी बढ़ गई। सब्ज़ियाँ काटते हुए या घास काटते हुए मैं ज़्यादातर समस्याएँ हल कर लेता हूँ; चमकदार तकनीक के सामने बैठे रहने से निर्णय तेज़ या बेहतर नहीं हो जाते
  client की dev team से बेहतर परिणाम देने की वजह भी यही है कि मैं full-time employee नहीं हूँ, इसलिए रुककर धीरे-धीरे सोच सकता हूँ। Teams की status light हरी बनाए रखने का दबाव जैसी productivity theater बहुत-सी संस्थाओं में मूर्खतापूर्ण फैसले पैदा करती है

  • 15 साल तक मैंने California के La Jolla समुद्र-दृश्य वाली चट्टान पर स्थित दो कंपनियों में काम किया। मैं चट्टान और पार्क में चलते हुए काम के बारे में सोचता था, और अगर whiteboard की ज़रूरत न हो ऐसी गंभीर चर्चा करनी होती, तो सहकर्मी से साथ चलने को कहता था। Rich Hickey का hammock talk फिर से सुनने लायक है
  • username देखकर सोच रहा हूँ कि क्या यह लेख में आने वाले Bob ही हैं

• productivity के अस्तित्व के कारण पर सोचते-सोचते मैं इस परिकल्पना पर पहुँचा कि यह दर्द कम करने की कोशिश है। programmer productivity समेत कई performance optimizations अक्सर problem domain की अस्पष्टता, organizational politics, अनिश्चितता, और failure risk जैसे दर्दों से बचने का engineer का आश्रय बन जाते हैं
  लेकिन वास्तविक समस्याएँ हल करनी हों तो user workflow को उबाऊ लगने लायक बारीकी से देखना पड़ता है, साझा रणनीति को स्पष्ट रूप से प्रस्तावित करना पड़ता है ताकि दूसरे लोग सहयोग करें, यानी वास्तविकता का सामना करना पड़ता है। दर्द का महिमामंडन करने की ज़रूरत नहीं, लेकिन अच्छे परिणामों में खिलाड़ी जैसी ट्रेनिंग अंतर्निहित होती है, और मैदान में ज़रूरी दर्द को संभालने की क्षमता विकसित करनी पड़ती है

• मूल बात यह है कि क्या उसे पहचानना आसान है। चमकदार टूल्स को कोई भी देखकर प्रभावित हो सकता है, लेकिन खाली editor या skeleton code में किसी शानदार नए product·feature को पहचानने वाले लोग बहुत कम होते हैं। इसलिए नज़र आने वाले टूल्स पर ध्यान जाता है, जबकि कठिन और अस्पष्ट “क्या बनाया जाए” को नज़रअंदाज़ कर दिया जाता है
  टूल्स पर मैं Marie Kondo वाला मानदंड लागू करता हूँ। अगर उसे इस्तेमाल करने में आनंद नहीं आता और वह जीवन आसान नहीं बनाता, तो उसे छोड़ देता हूँ; अगर बनाता है, तो रखता हूँ

• 2004 में, ज्यादातर junior developers वाली एक छोटी टीम को बेहतरीन और व्यापक Java training मिली। training से पहले IntelliJ और Eclipse settings को लेकर गहरे जुनून और तीखी बहसें होती थीं, लेकिन trainer ने हैरान करते हुए सलाह दी कि केवल बुनियादी JDK tools और Notepad इस्तेमाल करो
  मकसद यह था कि हमें भीतर क्या हो रहा है, यह सीखने दिया जाए, और उनका कहना था कि productivity में शायद बहुत बड़ा फर्क भी नहीं होगा

• environment optimization पर आसक्ति का कारण यह है कि केंद्रित प्रयास और इनाम का रिश्ता दिखने वाला, ठोस और भौतिक होता है। इसके उलट abstract learning ऐसी नहीं होती। chair optimize करने जैसी चीज़ों से ज्यादा learning tasks हैं, इसलिए अच्छा होगा अगर abstract learning को भी और ठोस महसूस कराने का कोई तरीका हो

• यह productivity की नहीं, बल्कि खिलौनों के साथ खेलने के मज़े की बात है