मेरी 'WTF Notebook' लिखने की विधि (2021)

 (simplermachines.com)
7 पॉइंट द्वारा GN⁺ 2024-04-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • नई टीम में शामिल होने के तुरंत बाद दिखने वाली अजीब बातों को तुरंत इंगित करने के बजाय WTF Notebook में जमा करके रखने से, शिकायत करने वाले व्यक्ति के बजाय टीम की मदद करने वाले व्यक्ति के रूप में भरोसा बनाने का संदर्भ मिल सकता है
  • नोट करने योग्य चीज़ें वे संकेत हैं जो टीम ऑपरेशन और तकनीकी प्रवाह में अटकन दिखाते हैं, जैसे retrospective का बिना action के खत्म हो जाना, local testing न हो पाना, लाल build board, या किसी खास काम का एक ही व्यक्ति पर निर्भर होना
  • समय के साथ सूची छंटकर उन items में बदल जाती है जिनके लिए वाजिब कारण हैं, जिन पर पहले से सुधार चल रहा है, जो टीम की low priority हैं, या जिन्हें आसानी से ठीक किया जा सकता है
  • कुछ हफ्तों बाद भी बची समस्याओं पर team members, team lead और manager से बात करके कारण और इतिहास समझें, और पहले उन समस्याओं को साथ मिलकर हल करें जो लंबे समय से असुविधा दे रही थीं लेकिन अपेक्षाकृत सरल हैं
  • समस्या को तुरंत उछालने के बजाय संदर्भ और priorities इकट्ठा करके रखने से, नया team member भी भरोसा खोए बिना problem-solver की reputation बना सकता है

WTF Notebook इस्तेमाल करने का तरीका

  • टीम में जो reputation बनानी है, वह है “मेरी समस्या हल करने में मदद करने वाला व्यक्ति”, “मेरे लिए महत्वपूर्ण काम पूरा करने वाला व्यक्ति”
  • जब भी नई टीम में शामिल होता/होती हूं, bullet journal के नए पेज पर WTF - [Team Name] लिखता/लिखती हूं, और जब भी कुछ अजीब लगता है, उसे नोट कर लेता/लेती हूं
  • अगर कुछ बदलना चाहता/चाहती हूं, तो उसे अलग task के रूप में भी दर्ज करता/करती हूं
  • पहले 2 हफ्तों में सिर्फ नोट करने पर ध्यान देता/देती हूं
    • टीम जो कुछ गलत कर रही है ऐसा लगता है, वह सब तुरंत नहीं कहता/कहती
    • retrospective में बदलने वाली चीज़ों की सूची नहीं उड़ेलता/उड़ेलती
    • देखता/देखती हूं, सुनता/सुनती हूं, और जो चीज़ गहराई से अजीब लगती है उसे लिखता/लिखती हूं
  • यह तरीका टीम में बदलाव लाते हुए खुद को manage करने और केवल शिकायत करने वाले व्यक्ति जैसा न दिखने की technique है

नई टीम में दिखने वाले अजीब संकेत

  • नई टीम में हमेशा कुछ ऐसा होता है जिसे देखकर “wtf” महसूस होता है
  • आम उदाहरण ये हैं
    • टीम retrospective में गंभीर समस्या पर एक घंटे तक बात करती है, लेकिन action items के बिना खत्म कर देती है
    • tests local machine पर नहीं चलते, और ऐसा लगता है कि किसी को परवाह नहीं
    • build board का बड़ा हिस्सा हमेशा लाल रहता है
    • महत्वपूर्ण और time-sensitive काम केवल एक ही व्यक्ति कर सकता है
    • टीम किसी feature पर बहुत समय लगाती है, लेकिन कोई ठीक से नहीं जानता कि वह क्यों महत्वपूर्ण है या customer की कैसे मदद करता है

सूची से हटने वाले items

  • जब सूची पर्याप्त बड़ी हो जाती है, तो items को एक-एक करके हटाना शुरू करता/करती हूं
  • हटने के कारण आम तौर पर चार होते हैं
    • वास्तव में कोई अच्छा कारण होता है
    • टीम पहले से सुधार पर काम कर रही होती है
    • टीम उस समस्या को महत्वपूर्ण नहीं मानती
    • उसे सचमुच आसानी से ठीक किया जा सकता है
  • local tests न चलने की समस्या भी संदर्भ के आधार पर बड़ी समस्या नहीं हो सकती
    • यह पहले से ज्ञात issue हो सकता है और समाधान की कोशिश चल रही हो सकती है
    • टीम सारा काम virtual machines पर करती हो, और chat command से उस machine को आसानी से provision किया जा सकता हो
    • continuous integration system अच्छी तरह मौजूद हो और छोटी changes बार-बार deploy करने की आदत हो, इसलिए local testing न हो पाना दिन में कई बार deployment को रोकता न हो
  • कुछ items के लिए सरल solution दिख जाता है
    • location पता हो तो documentation लिखी जा सकती है
    • सही script मिल जाए तो आसान change हो सकता है
    • आसान solution दिखे तो तुरंत ठीक कर देता/देती हूं

बची समस्याओं को टीम के साथ संभालना

  • कुछ हफ्तों बाद भी अगर अजीब और अनसुलझी समस्याएं बची रहती हैं, तो team members, team lead और manager से बातचीत शुरू करता/करती हूं
  • सवालों का focus यह होता है कि items ऐसी स्थिति में क्यों हैं, और वे ऐसे कैसे बने
  • लक्ष्य है सच में जिज्ञासु और सहानुभूतिपूर्ण व्यक्ति के रूप में भरोसा बनाना, जो धैर्यवान है और colleagues की expertise का सम्मान करता है
  • समस्याएं बची रहने के कारण आम तौर पर कुछ तरह के होते हैं
    • टीम ने ध्यान नहीं दिया
    • टीम इसकी अभ्यस्त हो गई
    • समस्या अपेक्षाकृत नई है, और इससे पहले वाली समस्या कहीं ज्यादा खराब थी
    • ठीक करने का तरीका नहीं पता
    • पहले ठीक करने की कोशिश की थी लेकिन असफल रहे
  • शुरुआती कुछ प्रकार सिर्फ सवालों से ही तुरंत ठीक हो सकते हैं
    • सामने वाला तुरंत ठीक कर देता है या साथ मिलकर समाधान ढूंढता है
    • अगर तकनीकी समस्या है, तो साथ में story या ticket लिखकर काम करते हैं
    • अगर process या social समस्या है, तो retrospective में पूरी टीम के साथ बात करते हैं
  • इस point पर अच्छा है कि नए colleagues में से किसी एक को कुछ समय से परेशान कर रही, और अपेक्षाकृत सरल solution वाली एक-दो समस्याएं खोजी जाएं
    • ऐसी समस्या चुनें जो retrospective board पर डालने पर सिर्फ आपको ही परेशान करने वाली न लगे
    • team conversation के दौरान उस team member ने जो सुझाव दिया हो, उसे तुरंत आजमाए जा सकने वाले action item के रूप में लें
    • टीम महसूस करना शुरू करती है कि नया team member उनकी समस्याएं हल करने में मदद कर रहा है

कठिन समस्याएं और manager से बातचीत

  • समय के साथ उन चिपचिपी समस्याओं तक पहुंचते हैं जिन्हें टीम जानती है, लेकिन जिनसे निपटने से डरती है
  • ये समस्याएं ऐसी हो सकती हैं जिन्हें “इतनी भी बुरी नहीं” माना जाता है, लेकिन जिनके बारे में कोई बात नहीं करना चाहता
    • जरूरी technical capability की कमी हो सकती है
    • केंद्र में कोई जटिल people problem हो सकती है
  • इस चरण में अब तक बनाई सूची manager के पास ले जाकर बात करता/करती हूं
    • कुछ हफ्तों में क्या देखा
    • कुछ चीज़ों में progress है, लेकिन कुछ में ज्यादा समय लगेगा ऐसा लगता है
    • क्या कुछ छूट गया है
    • वे किन areas पर focus चाहते हैं
  • manager भी उन्हीं समस्याओं को लेकर चिंतित रहा हो सकता है, लेकिन टीम बहुत असहज नहीं दिखी इसलिए जोर से push नहीं कर पाया हो सकता है
  • इसके बाद manager की चिंताओं और समस्याओं को साथ में organize कर सकते हैं, और पहले क्या अच्छी तरह काम कर चुका है या नहीं कर चुका, इसके examples पर बात कर सकते हैं
  • manager आपको अच्छे judgment वाला ऐसा व्यक्ति मानना शुरू करता है जो कठिन समस्याएं हल करने में मदद कर सकता है

तुरंत इंगित न करने का कारण

  • इच्छित reputation यह है कि “Nat मेरी समस्या हल करने में मदद करता/करती है”, “Nat मेरे लिए महत्वपूर्ण काम पूरा करता/करती है”
  • ऐसी reputation अगले साल के performance review में इच्छित परिणाम दिलाने और कुछ साल बाद recommendation तक ले जाने में मदद कर सकती है
  • पहले समस्या दिखते ही तुरंत बोल देता/देती था/थी
    • नतीजतन “हमेशा शिकायत करता/करती है”, “सोचता/सोचती है कि हम कभी कुछ सही नहीं करते” जैसी reputation मिली
    • लोगों ने सुनना बंद करना शुरू कर दिया, मैं व्यक्तिगत रूप से निराश हुआ/हुई और पेशेवर रूप से भी यह ineffective था
  • अगर नया team member किसी ऐसी चीज़ पर बड़ा हंगामा करता है जो असल समस्या नहीं है, जिसे टीम समस्या नहीं मानती, जिस पर पहले से समाधान चल रहा है, या जिसका सरल समाधान शुरुआत में उसे दिखा नहीं, तो भरोसा तेजी से टूटता है
  • टीम में सुधार की जा सकने वाली समस्याएं हमेशा बहुत होती हैं, लेकिन वास्तव में हल की जा सकने वाली केवल कुछ ही होती हैं
  • जिस क्रम में समस्याएं दिखती हैं, वही सबसे प्रभावी समाधान क्रम हो, ऐसा कम ही होता है
  • WTF Notebook “अभी तुरंत ठीक करना है” वाली impulse को कुछ समय के लिए रख देती है, और किस चीज़ से शुरुआत करनी है यह तय करने का संदर्भ बनने तक इंतजार करवाती है

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

1 टिप्पणियां

 
GN⁺ 2024-04-19
Hacker News की राय

  • लगता है यह लेख एक बात पर पर्याप्त ज़ोर नहीं देता: नए व्यक्ति की नज़र सिर्फ़ एक बार मिलती है
    किसी प्रोडक्ट की usability का सही आकलन कर पाना इसलिए मुश्किल होता है क्योंकि हमें उसका इस्तेमाल पहले से आता है, और हम गलतियों व कमियों के प्रति सुन्न हो चुके होते हैं
    नया टीम मेंबर अभी उस स्थिति में नहीं होता, इसलिए वह क्या पूछता है, कहाँ अटकता है, और कहाँ उसे सच में मदद की ज़रूरत पड़ती है, इसे देखकर टीम को बहुत insights मिल सकते हैं

    • हमारे यहाँ सबसे अच्छी बातों में से एक यह है कि हम प्रोडक्ट यूज़र के साथ बैठकर उसे वास्तव में प्रोडक्ट इस्तेमाल करते हुए देख सकते हैं
      हम नोटबुक लेकर बैठते हैं, लिखते जाते हैं, और यूज़र के प्रोडक्ट इस्तेमाल करते समय उससे बात करते हैं
      चाहे आप telemetry data के कितने भी terabytes इकट्ठे कर लें, असली यूज़र से बात करने जितनी समझ उससे नहीं मिलती कि लोग प्रोडक्ट को कैसे इस्तेमाल करते हैं
      tech industry को दूसरे इंसानों से डरने वाली अपनी प्रवृत्ति से थोड़ा बाहर आना चाहिए
    • हर कोई अपने प्रोडक्ट की अजीब बातों के प्रति अंधा हो सकता है
      यह वैसा ही है जैसे कोई अनुभवी प्रोफ़ेसर भूल जाता है कि शुरुआती छात्र को क्या-क्या समझाना पड़ता है
      लेकिन हर कोई इसमें एक जैसा कमजोर नहीं होता; इसमें यह बहुत मायने रखता है कि किसी में शुरुआती की जगह खुद को रखने लायक सहानुभूति और रुचि है या नहीं
      Bash shell को अनगिनत बार इस्तेमाल कर चुके दो लोग भी इस बात की समझ में पूरी तरह अलग हो सकते हैं कि शुरुआती को क्या अजीब और गैर-स्वाभाविक लगेगा
      नई नज़र से देखना भी एक कौशल है, और जैसे असली रोशनी और वस्तुओं को देखकर चित्र बनाना सीखा जाता है, वैसे ही अभ्यास से इसमें सुधार हो सकता है
    • मूल लेख शायद इस बात पर अधिक ज़ोर देता है कि “नई नज़र सिर्फ़ एक बार मिलती है” वाला दृष्टिकोण नए सहकर्मियों को बार-बार “ये क्या है?” चिल्लाने पर मजबूर कर सकता है, और नतीजतन वे ज़ोर-ज़ोर से शिकायत करने वाले व्यक्ति जैसे लग सकते हैं
      उसे तुरंत बोल देने के बजाय लिखकर रखने से आपको यह सीखने का समय मिलता है कि चीज़ें ऐसी क्यों हैं, और संगठन की बनावट समझने का भी समय मिलता है
      जब account, permissions, approvals जैसी चीज़ें व्यवस्थित हो जाती हैं, तब उस सूची के आधार पर आगे बढ़ा जा सकता है
      तब टीम भी आपको “हर समय उछलकर WTF चिल्लाने वाला व्यक्ति” नहीं बल्कि मदद करना चाहने वाले इंसान के रूप में देखने की अधिक संभावना रखती है
    • मैं पहले एक बहुत छोटे, self-funded startup में काम करता था, जहाँ नए hire के onboarding के दौरान आई समस्याओं को ठीक करने के लिए documentation और process अपडेट करवाए जाते थे
      12–15 लोगों की टीम में यह बहुत अच्छी तरह काम करता था, लेकिन बड़े scale पर यह उतना अच्छा चलेगा या नहीं, पता नहीं
    • नई नज़र सिर्फ़ एक बार मिलती है, लेकिन ऐसी journal शुरू करना और सूची को जमा होने देना शायद उन समस्याओं के प्रति फिर से संवेदनशील बनने का अच्छा तरीका हो सकता है जिन्हें हल किया जा सकता है
      लिख लेना और इंतज़ार करना तुरंत किया जा सकने वाला, कम बोझ वाला काम है, और “सूची लंबी हो गई” जैसा छोटा-सा इनाम भी देता है, इसलिए अगर इसे व्यवस्थित अभ्यास बनाया जाए तो इसे फिर से सीखना आसान हो सकता है
      मुझे यह बात पसंद है कि पहचानने और दर्ज करने के चरण को, और बाद में नक्शा बनाने, देखने-समझने-सीखने, और उसी चिंता वाले लोगों को जुटाकर आगे बढ़ाने के चरण को अलग रखा जाता है

  • काम का journal लिखना हमेशा अच्छा विचार है, लेकिन इस लेख के tone में कुछ खटकता है
    मैं किसी ऐसे व्यक्ति के साथ काम नहीं करना चाहूँगा जो Borg की तरह बर्ताव करे या 『How to Win Friends and Influence People』 से निकली हुई किसी script पर चल रहा लगे
    अगर लगे कि कोई मुझे manipulate करने की कोशिश कर रहा है, तो कम से कम उस क्षण के बाद से उस पर भरोसा करना मुश्किल हो जाता है

    • अपने बारे में लोगों की धारणा को जानबूझकर manage करना बहुत लोगों को असहज लग सकता है
      फिर भी, सिर्फ़ उस तात्कालिक अस्वीकृति के पीछे बह जाना ठीक नहीं
      मैं भी इस बात को लेकर लक्ष्य रखता हूँ कि stakeholders मुझे किस तरह महसूस करें, और यह व्यवहार के मानदंड के रूप में काफ़ी उपयोगी रहा है
      तकनीकी रूप से काम में अच्छा होने के बावजूद, जब मैंने मानवीय रिश्तों के पहलू को नज़रअंदाज़ किया तो समस्याएँ हुईं; कौन-सी अफ़वाहें चल रही हैं, लोग मुझे कैसे देखते हैं, और मेरे काम को कैसे पेश किया जाता है, यह वास्तव में मायने रखता था
      “बस अपना काम अच्छी तरह करो” से यह सच खत्म नहीं हो जाता कि मेरा काम और दूसरों पर मेरा प्रभाव दोनों महत्वपूर्ण हैं
    • मुझे जिज्ञासा है कि इसमें कौन-सा tone खटका
      मैंने 『How to Win Friends and Influence People』 नहीं पढ़ी, लेकिन मुझे यह लेख खुद काफ़ी अच्छी तरह लिखा हुआ लगा
    • मेरे हिसाब से बात का सार यह है कि जब आप नई leadership भूमिका लेते हैं, तो यह बुनियादी बात होती है
      चाहे आप अनुभवी individual contributor हों, नए manager हों, या कोई officer, शुरुआत के 30–90 दिनों में कुछ भी बदलने के बजाय यह समझने की कोशिश करनी चाहिए कि काम कैसे चलता है, और उससे भी ज़्यादा महत्वपूर्ण, क्यों चलता है
      इससे संगठनात्मक रूप से बहुत फायदे मिलते हैं, और संक्षेप में कहें तो व्यवहार में यही तरीका काम करता है
      engineers अक्सर खराब managers के नीचे काम कर चुके होते हैं, और भले वे ठीक-ठीक न बता पाएँ कि वे खराब क्यों थे, उन्हें उसका एहसास रहता है
      वह “खराब manager” वाला एहसास अक्सर tactical leadership की कमी से आता है, और engineering की तरह leadership भी सीखी जा सकने वाली skill है
      समस्या यह है कि सेना या senior executive training जैसी जगहों को छोड़ दें तो इसे इरादतन सिखाने वाली जगहें बहुत कम हैं
      अगर आप अच्छे manager के नीचे काम करना चाहते हैं, तो असल में आप अच्छे leader के नीचे काम करना चाहते हैं, और leadership उतनी ही tactical skill है जितनी efficient C++ code लिखना
      यह लोगों को इस तरह align और lead करने का काम है कि वे मिलकर ऐसा लक्ष्य हासिल करें जो टीम के सदस्य अलग-अलग रहकर जो कर सकते हैं उससे बड़ा हो, इसलिए कुछ कोणों से यह manipulation जैसा लग सकता है
      फिर भी, जो व्यक्ति टीम को बाहर की बेवकूफ़ी से बचाए, ज़रूरी resources दिलाए, सार्वजनिक रूप से प्रशंसा करे और निजी तौर पर आलोचना करे, अत्यधिक micromanage किए बिना दिशा दे, उपलब्धियों को माने और पुरस्कृत करे, और मानक से नीचे की चीज़ों को यूँ ही न छोड़ दे — आम तौर पर engineers ऐसे leader को पसंद करते हैं
      दूसरी ओर, अगर कोई तकनीक न समझने वाला MBA पृष्ठभूमि का करिश्माई political player इन्हीं तकनीकों का बुरे कारणों से इस्तेमाल करे, तो वह ऐसा व्यक्ति बन जाता है जिसके साथ काम नहीं करना चाहेंगे
      जो लोग technical भूमिका से manager तो बन गए, लेकिन यह मानने को तैयार नहीं कि management, technical skill से अलग चीज़ है, वे भी अक्सर नापसंद किए जाते हैं
      अंततः अगर पूरी industry में सक्षम leaders बढ़ाने हैं, तो ऐसे लेखों की तरह leadership को किसी धुंधली जन्मजात समझ के रूप में नहीं, बल्कि समझाई जा सकने वाली tactics के रूप में देखना होगा
    • मेरी पहली प्रतिक्रिया थी, “यह व्यक्ति कितनी बार नौकरी बदलता होगा?”

  • “Nat मेरी समस्या हल कर देता है” जैसी प्रतिष्ठा मिलना recommendations के लिए अच्छा हो सकता है, लेकिन career के लिए खतरनाक भी हो सकता है
    मैंने 20 साल तक कई departments में ऐसा किया, लेकिन हर बार उन्होंने मुझे problem solver के रूप में पकड़े रखा, promotion candidate के रूप में आगे नहीं बढ़ाया
    40 साल काम करके retire हुए एक सहकर्मी भी ऐसे ही थे, जो किसी भी समस्या को हल कर देते थे और managers से कहीं ज़्यादा सक्षम थे, लेकिन उन्हें promotion नहीं मिला
    वे सबके तुरुप का इक्का थे, लेकिन उन्हें शायद ही कभी पहचान मिली; समस्याएँ हल करना “स्वाभाविक” मान लिया गया और उसका कोई reward भी नहीं मिला
    उसी grade के दूसरे लोगों पर इससे कहीं कम मानदंड लागू होते थे, और आख़िरी performance review में भी manager ने कहा, “मैं तुम्हारा मूल्यांकन सहकर्मियों से नहीं, लक्ष्यों के मुकाबले performance से करता हूँ”
    मैंने भी दूसरे manager से यही बात सुनी थी, इसलिए यह कोई संयोग नहीं था

    • पिछली नौकरी में मैं ऐसा ही व्यक्ति था, लेकिन मेरा अनुभव कहीं बेहतर रहा
      सबसे बढ़कर, मेरा manager हमेशा मेरी तरफ़ खड़ा रहता था जब उसे ऐसे requests रोकने होते थे जो उसी की ओर से नहीं आए हों
      अगर कोई अनजान व्यक्ति कोई गैर-तुच्छ काम कह देता और मेरे पास समय न होता या रुचि न होती, तो मैं बस कह देता, “अभी इसे देखने का समय नहीं है। अगर इसे priority देनी है तो मेरे manager से बात कीजिए।” और 100 में 99 बार बात manager तक जाती ही नहीं थी
      department या पूरी company में go-to person बन जाने का सबसे बड़ा फ़ायदा यह है कि जान-पहचान और contacts का network बन जाता है
      जब team के बाहर से जानकारी चाहिए होती है, या किसी अहम काम के लिए bureaucracy को पार करना पड़ता है, तो यह एक छोटी superpower की तरह काम करता है
      नए मौक़े खोजते समय संपर्क करने लायक network भी बन जाता है, और private sector में 15 साल काम करते हुए मुझे मिली सारी नौकरियाँ इसी तरह के connections से आईं
    • यह दिलचस्प नज़रिया है
      लेकिन यह भी कहा जा सकता है कि इन दो तरीकों में से एक promotion process को अच्छी तरह पार कर जाता है, और दूसरा नहीं
    • बीच का रास्ता यह है कि मददगार इंसान बनो, लेकिन जब समय न हो तो ना कहने की क्षमता भी सीखो
      यह आसान नहीं है, लेकिन boundaries तय करना एक अहम skill है
    • यह करने के लिए ज़रूरत पड़ने पर सख़्ती से मना कर पाने की क्षमता भी होनी चाहिए

  • “जैसे ही कोई समस्या दिखी, मैं तुरंत बोल पड़ता था, और इससे Nat की ऐसी छवि बन गई कि वह हमेशा शिकायत करता है और उसे लगता है कि हम जो भी करें वह ग़लत है” — यह हिस्सा लेख के काफ़ी ऊपर होना चाहिए
    इस स्तर की self-awareness सच में ऐसी skill है जिसे सीखना चाहिए
    पूर्व astronaut Chris Hadfield ने भी अपनी किताब में कहा है कि नई mission और नई team में शामिल होते समय उन्होंने कुछ ऐसा ही तरीका अपनाया था
    पहले observation mode में जाओ, फिर सीखो कि WTF moments सच में जायज़ हैं या नहीं; यह नए team member के रूप में लोगों को irritate न करने का भी तरीका है
    पढ़ने लायक है

    • यह approach सचमुच काम करती है
      लंबे समय तक एक ही भूमिका में काम करने के बाद, यह ऐसा स्थान दे देती है जहाँ शोर को छानकर रख सको ताकि कम से कम वह दिमाग़ में वैसे का वैसा अटका न रहे
      यह सिर्फ़ यह तय करने भर की बात नहीं है कि कोई समस्या वैध है या नहीं, बल्कि कुछ चीज़ों को छोड़ देना सीखने के क़रीब भी है
    • जानना चाहूँगा कि क्या यह Chris Hadfield की किसी किताब में है
      अगर बता सकें कि कौन-सी किताब है, तो अच्छा होगा

  • जब भी मैं किसी पहले से चल रही स्थिति में प्रवेश करता हूँ, आम तौर पर इसी तरह आगे बढ़ता हूँ
    पहले हफ़्ते मैं हर चीज़ की समीक्षा करते हुए सवाल और observations लिखता हूँ
    सिर्फ़ “WTF” moments ही नहीं, बल्कि जो चीज़ें अच्छी चल रही हों और जो वाक़ई अच्छे ideas लगें, उन्हें भी नोट करता हूँ
    उसके बाद ही मैं समीक्षा करता हूँ, priorities तय करता हूँ और फिर चर्चा में जाता हूँ

  • यह Chesterton’s Fence से अच्छी तरह मेल खाने वाला सिद्धांत लगता है
    कहानी यह है कि जो व्यक्ति किसी बाड़ को हटाना चाहता है, उससे कहा जाता है: “अगर तुम्हें इसका उपयोग नहीं पता, तो मैं तुम्हें इसे हटाने नहीं दे सकता। जाओ, सोचो, और जब यह कह सको कि तुम इसका उपयोग समझते हो, तब इसे हटाना ठीक है।”
    ज़्यादा साफ़ शब्दों में, इसका मतलब है कि अगर कोई चीज़ अटपटी दिखे, तो पहले यह मान लेना बेहतर है कि जो लोग पहले आए थे वे मूर्ख नहीं थे और उसके पीछे कोई वजह थी
    वह वजह अब पुरानी पड़ चुकी हो सकती है, लेकिन अगर उसे समझे बिना आगे बढ़ोगे, तो वही ग़लती फिर दोहराने का ख़तरा रहेगा

  • जिन चीज़ों को आप ठीक करना चाहते हैं उनकी सूची बनाए रखने के अलावा, यह इसलिए भी अच्छा विचार है कि समय के साथ छोड़े रहने पर समझ में आता है कि कुछ चीज़ें वैसी क्यों हैं
    कई बार चीज़ें जल्दबाज़ी में बनाई गई होती हैं या ग़लती से हुई होती हैं, लेकिन कभी-कभी सचमुच छिपी हुई complexity होती है जिसे सिर्फ़ code की एक line देखकर तुरंत समझना मुश्किल होता है

    • अनुभव बढ़ने पर आप कुछ हद तक असली “आख़िर यह ऐसे क्यों किया गया?” वाले WTF और “अच्छा, यहाँ कोई subtle complexity है” वाले WTF में फ़र्क करना सीख जाते हैं
      पहला साफ़ नाकामी है, जबकि दूसरा आम तौर पर उस environment में काफ़ी डूबने के बाद समझ में आ जाता है
      फिर भी, दोनों को लिखकर रखना उपयोगी है

  • इसी हफ़्ते मैं दो सहकर्मियों से कह रहा था कि मैं अपने computer पर “How the F” नाम की file रखता हूँ
    यह लेखक की बात से बिल्कुल एक जैसी नहीं है, लेकिन बहुत मिलती-जुलती है, और जब भी मैं किसी नई team में शामिल होता हूँ, तो हर उस चीज़ को लिख लेता हूँ जिस पर लगता है, “अरे, यह फिर से कैसे करना था?”
    मैं इसे मूल लेख की तरह manager के पास नहीं ले जाता, लेकिन इससे team और company की bottlenecks समझने और समय देकर उन्हें हल करने का नज़रिया मिलता है

  • मैं इस तरह जीता हूँ कि जो भी ideas दिमाग़ में आएँ, उन्हें सूची में लिख दूँ
    कोई ख़ास क्रम नहीं होता; बस काग़ज़ या text file में जोड़ता जाता हूँ
    ideas ज़रूरत के समय सामने नहीं आते; वे तो दिन भर तब आते रहते हैं जब आप कुछ और कर रहे होते हैं, और अगर मैं उन्हें लिख न लूँ तो कम से कम मुझे वे याद नहीं रहते
    जब सच में कुछ करना होता है, तो बस एक-एक करके काटते जाओ; फिर यह सोचने की ज़रूरत नहीं रहती कि अगला क्या करना है, और ideas कभी ख़त्म नहीं होते, इसलिए काफ़ी बड़ा productivity burst संभव हो जाता है

    • मुझे ठीक से समझ नहीं आ रहा कि यह मूल लेख से कैसे जुड़ता है
      यह ज़्यादा एक personal to-do list व्यवस्थित करने की बात लगती है, जबकि मूल लेख team के भीतर ढलने और communication के तरीक़े पर है
    • मैं Apple Notes और Android के Notally में लगभग यही note-taking strategy इस्तेमाल करता हूँ
      ज़िंदगी notes को व्यवस्थित करने के लिए बहुत छोटी है; मेरी राय में सब कुछ बस लिख लो, फिर reverse chronological sorting और search पर भरोसा करो
      विडंबना यह है कि मुझे पता है कि मेरे पास शानदार ideas का ख़ज़ाना पड़ा है, लेकिन इस उम्र में मैं उन्हें 20s की तरह अमल में लाने जितनी परवाह अब नहीं करता