- छोटी-छोटी automation बार-बार करते-करते एक समय ऐसा आता है जब हर tool और system ठीक किए जाने वाली चीज़ की तरह दिखने लगते हैं — यह cognitive threshold है
- जैसे-जैसे तकनीकी क्षमता बढ़ती है, समस्या को केवल पहचानने से आगे बढ़कर वह जिम्मेदारी जैसा महसूस होने वाला भावनात्मक बोझ बन जाती है
- कुछ ठीक करने की इच्छा केवल productivity बढ़ाने तक सीमित नहीं रहती, बल्कि कभी-कभी भावनाओं को नियंत्रित करने का साधन बन जाती है, और कई बार इंसान अपने ही बनाए system में फँस जाता है
- समय के साथ system टूटते ही हैं, और पूर्ण समाधान जैसा कोई भ्रम वास्तविक नहीं होता
- आखिरकार सच में ज़रूरी skill सब कुछ ठीक कर देना नहीं, बल्कि कुछ चीज़ों को बिना ठीक किए भी सहन कर सकने की मानसिक गुंजाइश है
शुरुआत छोटी automation से
- file name बदलने वाले Python script या
gitcommand shortcuts जैसी छोटी productivity improvements से शुरुआत होती है - system की असुविधा को खुद ठीक कर लेने के बाद, दुनिया की हर चीज़ सुधार के लक्ष्य जैसी दिखने लगती है
- एक समय के बाद यह “कर सकता हूँ” से आगे बढ़कर “करना ही चाहिए” वाली नैतिक बाध्यता में बदल जाता है
तकनीकी क्षमता का भार
- programming से पहले खराब software को बस नज़रअंदाज़ किया जा सकता था, लेकिन अब समस्याएँ बहुत साफ़ दिखने लगती हैं
- दूसरे developers के ढीले-ढाले code या hardcoded settings आलोचना जैसे महसूस होते हैं
- हर system और software ठीक किए जाने वाली TODO list की तरह दिखने लगता है
लगातार refactor करते रहने वाली ज़िंदगी
- हर बार “इसे मैं इससे बेहतर बना सकता हूँ” सोचते हुए इंसान अपने tools बनाने में डूब जाता है
- बेतरतीब code directories, अनगिनत कोशिशें और अधूरे छोड़ दिए गए प्रयोग, और अंतहीन architecture redesign कभी-कभी स्वयं को बाँध लेने वाला श्रम बन जाते हैं
- Kafka की “पिंजरा बनाकर चिड़िया का इंतज़ार करना” वाली उपमा की तरह, इंसान बिना स्पष्ट उद्देश्य के tool बनाते रहने में फँस सकता है
software सड़ता है
- जो script कभी परफेक्ट लगती थी, वह भी किसी दिन बाहरी बदलावों की वजह से बेकार हो जाती है
- website layout बदल जाना, package version बदलना, dependency errors आदि
- समस्या आने पर यह सिर्फ असुविधा नहीं रहती, बल्कि अपराधबोध भी पैदा होता है
- अंत में लगातार maintenance की ज़रूरत वाली वास्तविकता का सामना करना पड़ता है
automation का भ्रम
- “एक बार setup कर दो, फिर दोबारा हाथ नहीं लगाना पड़ेगा” जैसी झूठी उम्मीद बार-बार पैदा होती है
- हम programming को problem-solving की जीत मानते हैं, लेकिन यह दरअसल कभी न खत्म होने वाला युद्ध है
- completion जैसा कोई विचार नहीं है; हम बस हमेशा पानी से भरती रहने वाली खाइयाँ खोदते रहते हैं
जब coding भावनाओं को संभालने का साधन बन जाती है
- tools बनाना कभी-कभी ज़िंदगी की अव्यवस्था को नियंत्रित करने की मनोवैज्ञानिक प्रतिक्रिया होता है
- system जितना जटिल होता है, कभी-कभी उतना ही लगता है कि सब कुछ व्यवस्थित है
- जटिल जीवन से बचने के लिए इंसान नई app या refactoring की कोशिश करता है और खुद को सांत्वना देता है
बिना चेतावनी के burnout
- burnout सिर्फ ज़्यादा काम से नहीं, बल्कि हद से ज़्यादा जिम्मेदारी महसूस करने से पैदा होता है
- “जिसे मैं ठीक कर सकता हूँ, उसे ठीक क्यों नहीं कर रहा?” जैसी आत्म-आलोचना stress को और बढ़ाती है
- अंतहीन तकनीकी जिम्मेदारी आत्म-विनाशकारी बोझ की तरह काम करती है
छोड़ देना भी सीखना
- हर समस्या का समाधान करना ज़रूरी नहीं है
- कभी-कभी यह जानना कि कुछ चीज़ों को ठीक करना ज़रूरी नहीं, उससे भी बड़ा control देता है
- कमियों को स्वीकार करना और चीज़ों को वैसे ही इस्तेमाल करना भी एक सचेत चुनाव हो सकता है
असली skill है भावनात्मक स्पष्टता
- ठीक करने की तकनीकी skill से ज़्यादा महत्वपूर्ण बिना ठीक किए भी शांत रह सकने की मानसिक skill है
- कब रुकना है, और कौन-सा project सिर्फ आत्म-सांत्वना के लिए है — यह पहचानने की क्षमता
- हर चीज़ को ठीक करने की बाध्यता से निकलकर, अपूर्णता के बीच भी सहज रहना सीखना ज़रूरी है
आखिरकार programming में सबसे कठिन skill यह है,
"टूटी हुई चीज़ को वैसे ही छोड़ देना सीखना"
21 टिप्पणियां
हर चीज़ का एक उद्देश्य होता है। अगर उद्देश्य हासिल हो गया है, तो उसे और ठीक करने की ज़रूरत नहीं है। लेकिन अगर उद्देश्य हासिल नहीं हुआ है, तो उसे ठीक करना चाहिए.
प्रोजेक्ट के उद्देश्य को स्पष्ट रूप से समझना ही शुरुआत होगी।
दुनिया में यह समझ लेने से मन हल्का हो जाता है कि कुछ ऐसी कंपनियां भी हैं जिनकी कीमत सिर्फ बैंकों और payment companies की बेतरतीब APIs को एक साथ बांधकर व्यवस्थित कर देने भर से ही हजारों करोड़ तक पहुंच जाती है, lol
कूx..
VB 6.0 और COM + OLE + ActiveX से बना सिस्टम आज भी ठीक-ठाक चलता देख अगर आपको घबराहट हो और उसे फिर से लिखने की इच्छा होने लगे, तो कष्ट आपको ही झेलना पड़ेगा।
आख़िरकार प्रोग्रामिंग में सबसे मुश्किल स्किल यह सीखना है,
"जो टूटा हुआ है उसे बस वैसे ही छोड़ देना"
पूरी तरह सहमत हूँ। मैं चीज़ें शुरू कर देने वाले टाइप का हूँ, इसलिए हमेशा परेशान होता हूँ...
किसी साधारण programmer की जैसे-तैसे जोड़ी गई automation का टूट जाना तो तय ही है।
अच्छी सामग्री
बर्नआउट डॉटडेम
: जब बड़ी मेहनत से काम ऑटोमेट किया, तो उसका फायदा बगल वाला सहकर्मी देखता है, और खुद को दूसरे कामों के ऑटोमेशन में झोंक दिया जाता है;
15 मिनट का काम था, उसे automate करने में 2 दिन लगा दिए, तो सैलरी खाकर टाइमपास करने वालों में मैं भी एक हूँ
अत्यधिक जिम्मेदारी की भावना प्रोग्रामर की एक तरह की occupational disease जैसी होती है, इसलिए इसे system के जरिए हल किया जाना चाहिए.
Quality Assurance टीम को ही assure करना चाहिए.
क्या QA डेवलपर की अत्यधिक जिम्मेदारी की भावना को नियंत्रित करने में मदद कर सकता है? मुझे यह ठीक से समझ नहीं आ रहा है।
जब डेवलपर से लापरवाही का सवाल पूछते हुए "तुमने coding गलत की" जैसी बातें जमा होती जाती हैं,
तो डेवलपर ज़िम्मेदारी के दबाव में नए प्रयासों से बचने लगता है,
और आखिरकार बिना प्रगति वाले सिर्फ़ सुरक्षित code ही लिखने लगता है।
इसी का मतलब है कि QA को assure करना चाहिए।
विकासोन्मुख coding करने के लिए कुछ न कुछ risk उठाना ही पड़ता है,
और उसकी जाँच करके उसकी ज़िम्मेदारी लेना ही QA की भूमिका होनी चाहिए।
आप इस लेख को इस तरह भी पढ़ सकते हैं? मेरी नज़र में, अगर ज़ोर देकर कहें, तो यह लेख दरअसल yak shaving की आलोचना करने वाला लेख लगा था।
roxie जी ने जैसा कहा, वह मुख्य लेख के बारे में याक शेविंग की बात ही है,
लेकिन अपने व्यक्तिगत अनुभव के आधार पर लिखते-लिखते मेरी बात मूल लेख की सामग्री से थोड़ा अलग दिशा में चली गई।
क्या इसे NIH(not invented here) फ़िनॉमेनन से भी समझाया जा सकता है? मेरा मानना है कि यह नहीं भूलना चाहिए कि maintenance अपने आप में एक fixed cost है, और इस cost में लोगों की मेहनत भी शामिल होती है।
इसे लंबे समय तक करते रहने के लिए, अत्यधिक ज़िम्मेदारी की भावना से पैदा होने वाली compensatory mindset के जाल में फँसने से पहले
कभी-कभी ज़िम्मेदारी और भावनाओं का बोझ थोड़ा नीचे रख देने का अभ्यास भी ज़रूरी लगता है।
मुझसे भी यह चीज़ अच्छी तरह balance नहीं हो पाती, haha... अच्छी बात कही है।
यह काफ़ी अच्छा पॉइंट लगता है। ज़िम्मेदारी का मतलब सचमुच ज़िम्मेदारी महसूस करना ही है, इसलिए अपने आप में वह किसी प्रतिफल की मांग नहीं करती। लेकिन समय बीतने पर, शरीर और मन थकते जाते हैं जबकि ज़िम्मेदारी की भावना आसानी से खत्म नहीं होती, और लगता है कि उस फ़ासले को भरने के लिए (हालाँकि दोनों को इस तरह जोड़ना नहीं चाहिए) इंसान बदले में कुछ पाने की अपेक्षा करने लगता है। वह भी अनजाने में।
खैर, "टूटी हुई चीज़ को बस ऐसे ही छोड़ देना" की बजाय शायद थोड़ा बेहतर समझौता यह होगा कि "जब तक वह टूट न जाए, तब तक उसे छेड़ो मत" :)
Hacker News की राय
थिएटर करते समय सीखा हुआ एक उद्धरण है। उसमें कला की प्रक्रिया को इस तरह समझाया गया था कि कठिन चीज़ों को आदत बनाना, आदतन चीज़ों को आसान बनाना, और आसान चीज़ों को सुंदर बनाना
UI समस्याओं पर अपनी व्यक्तिगत राय रखते हैं
व्यक्तिगत प्रोजेक्ट्स की कठिनाइयों पर बात करते हैं
software engineer के प्रति सम्मान व्यक्त करते हैं
perfectionism की आलोचना करते हैं
व्यक्तिगत अंतर्दृष्टि साझा करते हैं
यह भी कहते हैं कि परिवार और बच्चे perfectionism से निपटने में मदद करते हैं
software को खुद लिखना अधिक मज़ेदार है और अधिक सरल समाधान देता है
दावा करते हैं कि नई चीज़ों के पीछे भागने वाली संस्कृति ही समस्या की जड़ है
मनोवैज्ञानिक लोगों को दो तरह में बाँटते हैं: वे जो हर चीज़ को maximize करना चाहते हैं, और वे जो "काफी अच्छा" तलाशते हैं
"टूटी हुई चीज़ों को यूँ ही छोड़ देना कैसे सीखें" की बजाय "जो महत्वपूर्ण नहीं है, उसे छोड़ना कैसे सीखें" ज़्यादा उपयुक्त वाक्य लगता है।
जिसे ठीक करना ज़रूरी है, उसे तो ठीक करना ही चाहिए।
सहमत हूँ। मेरा मानना है कि इंसान को यह अच्छी तरह समझकर छोड़ देना चाहिए कि वह अपने बगीचे को बस और सुंदर बना रहा है, या सच में कोई महत्वपूर्ण काम कर रहा है।