अगले दिन आसान प्रवाह के लिए काम को थोड़ा अधूरा छोड़ें
दिन के अंत में कोड को “थोड़ा अधूरा” छोड़ना इस तरह प्रस्तुत किया गया है कि अगली सुबह फिर से प्रवाह में लौटना आसान हो जाए, और इसके लिए failing tests, जानबूझकर compile errors, या TODO टिप्पणियाँ भविष्य के काम के लिए breadcrumbs की तरह छोड़ी जाती हैं। कई इंजीनियर बताते हैं कि पूरा होने से पहले रुकने से उनका अवचेतन रात भर समस्या पर काम करता रहता है और फिर से शुरू करने की रुकावट कम होती है, जबकि दूसरे कहते हैं कि अधूरा काम तनाव, अनिद्रा, या उनके closure और साफ़ handoff की ज़रूरत से टकराता है। व्यापक चर्चा यह दिखाती है कि उत्पादकता की तकनीकें बहुत व्यक्तिगत होती हैं, और वे अंतिम लक्ष्यों के प्रति उत्साह, work-life boundaries, तथा “कम-प्रभाव” लेकिन ज़रूरी कार्यों के बारे में टीम की अपेक्षाओं जैसे कारकों से जुड़ती हैं।
मुख्य विचार: काम को थोड़ा अधूरा छोड़ना
- कई लोग जानबूझकर तब रुकने का वर्णन करते हैं जब अगला कदम साफ़ हो (“थोड़ा अधूरा, लेकिन पूरी तरह समझा हुआ”), ताकि अगले दिन फिर से प्रवाह में लौटना आसान हो।
- कुछ लोग इसे “ढलान की ओर मुंह करके पार्क करना” या ऐसी लेखन तकनीकों जैसा मानते हैं जहाँ आप बीच में ही रुक जाते हैं ताकि आपको बिल्कुल पता हो कि आगे क्या करना है।
बताए गए लाभ
- सुबह की रुकावट कम होती है: आप एक छोटी, अच्छी तरह परिभाषित कार्रवाई से शुरू करते हैं, न कि एक खाली स्लेट से।
- यह रात भर मानसिक मॉडल को बनाए रखने में मदद करता है और जटिल कोडबेस में संदर्भ को तेज़ी से फिर से बनाने में सहायक होता है।
- मूल कारण मिलने के बाद लेकिन फ़िक्स लिखने से पहले समाप्त करना, आपको समाधान पर सोने देता है और कभी-कभी अधिक सूक्ष्म समस्याएँ पकड़ने में मदद करता है।
- कुछ लोग कहते हैं कि उनका “रात का दिमाग” प्रोसेसिंग जारी रखता है, जिससे सुबह तक अंतर्दृष्टि या पूरी समाधान तक मिल जाते हैं।
लागत और कब यह उल्टा पड़ता है
- कई लोगों का कहना है कि कोई भी अधूरा काम मन में चलता रहता है, अनिद्रा या असंतोष की भावना पैदा करता है; वे मज़बूत समापन को पसंद करते हैं।
- जिन्हें “बंद करना” मुश्किल लगता है (संभावित ADHD सहित) वे बताते हैं कि अधूरा काम काम के बाहर भी उनके विचारों पर हावी रहता है।
- उपयोगकर्ता प्रभाव को लेकर चिंता: लगभग-समाप्त फ़िक्स को छोड़ देने से मूल्य मिलने में देरी हो सकती है और कभी-कभी ग्राहक का समय बर्बाद होता है।
- कुछ लोग तर्क देते हैं कि दिन के अंत में गुणवत्ता गिर सकती है; जबकि दूसरे इसका उल्टा बताते हैं, कि ताज़ा संदर्भ होने पर देर-दोपहर का कोड अधिक उच्च गुणवत्ता का होता है।
ठोस तरीके
- कोड को जानबूझकर non-compiling छोड़ दें: गायब delimiters, अधूरे कथन, या source में एक सादा-भाषा वाली पंक्ति, ताकि compiler यह दिखा दे कि फिर कहाँ से शुरू करना है।
- अगले कदम के रूप में एक failing या non-compiling test छोड़ें (TDD सलाह की तरह, failing test लिखने के बाद रुक जाएँ)।
- ऐसे uncommitted या cleanup-later टिप्पणियाँ / TODOs उपयोग करें जो साफ़ तौर पर बताती हों कि आगे क्या करना है और कहाँ।
- कुछ लोग सुबह के लिए आधे-अधूरे काम के बजाय एक छोटा, एक घंटे से कम का कार्य कतार में रखना पसंद करते हैं।
नींद, offloading, और नोट्स
- कई लोग “अपना दिमाग खाली करने” की सलाह देते हैं, नोट्स, टिप्पणियों, या sticky notes में संदर्भ डालकर भूल जाने की चिंता को कम करने के लिए।
- इस बात पर मतभेद है कि चीज़ें लिख लेना बाद में अवचेतन प्रसंस्करण में मदद करता है या भूलने का कारण बनता है; अधिकांश लोग इसे सहायक मानते हैं।
व्यापक उत्पादकता और काम के अर्थ पर बहस
- एक उप-चर्चा का तर्क है कि अगर आप अपने अंतिम लक्ष्यों को लेकर सचमुच उत्साहित हैं, तो आपको उत्पादकता के हथकंडों की ज़रूरत नहीं; दूसरे जवाब देते हैं कि अधिकांश वास्तविक नौकरियों में काफी उबाऊ लेकिन ज़रूरी काम शामिल होता है।
- एक और उप-चर्चा “कम-प्रभाव वाले कार्यों को न कहने” की आलोचना करती है, यह देखते हुए कि अनदेखे रखने योग्य reliability या maintenance काम से बचना किसी व्यक्ति को खराब teammate बना सकता है, भले ही कुछ संगठनों में इससे करियर को कभी-कभी फायदा हो।