काम करना, काम करना ही है
(softwaredesign.ing)- सिर्फ़ कार्रवाई करना ही वास्तविक अमल है; सोचना या तैयारी करना अमल नहीं है
- बार-बार यह बताया गया है कि योजना बनाना, सीखना, चर्चा करना, टूल खरीदना—इनमें से कोई भी ‘काम करना’ नहीं है
- असफल होते हुए या अनाड़ीपन के साथ भी सीधे कोशिश करना ही सच्चा अमल माना जाता है
- छोटा ही सही, शुरुआत करना महत्वपूर्ण है; परफेक्ट तैयारी या आदर्श परिस्थितियाँ ज़रूरी नहीं हैं
- यह लेख याद दिलाता है कि वास्तविक कार्रवाई में बदलने वाला रवैया ही रचनात्मकता और डेवलपमेंट का मूल है
अमल और गैर-अमल के बीच फर्क
- लेख में गिनाया गया है कि “सोचना, सपने देखना, विज़ुअलाइज़ करना, तैयारी करना” जैसी चीज़ें ‘काम करना’ नहीं हैं
- उदाहरण: “सोचना”, “सपने देखना”, “सफलता की कल्पना करना”, “तैयार होने तक इंतज़ार करना” आदि
- बोलना, समझाना या बहस करना भी अमल नहीं माना जाता
- इसमें “दूसरों को समझाना”, “ऑनलाइन बहस करना”, “शुरू करने की घोषणा करना” जैसी चीज़ें शामिल हैं
तैयारी और उपभोग के जाल
- पॉडकास्ट सुनना, ट्यूटोरियल देखना, दूसरों के उदाहरण पढ़ना—ये सब अमल नहीं हैं
- परफेक्ट सिस्टम डिज़ाइन करना, टूल खरीदना, या वर्कस्पेस व्यवस्थित करना भी अमल नहीं माना गया है
- गिल्ट या व्यस्तता से तसल्ली पाने का रवैया भी वास्तविक कार्रवाई नहीं है
असली अमल के रूप
- असफल होते हुए करना, अनाड़ीपन से करना, छोटा ही सही, करना—इन सबको ‘काम करना’ माना गया है
- परफेक्ट न होते हुए भी वास्तव में हाथ चलाना महत्वपूर्ण है
- लेख के अंत की ओर यह कहा गया है कि “ब्लॉग लिखना भी काम करना नहीं है”, और इस तरह आत्म-चिंतन वाला निष्कर्ष सामने आता है
मुख्य संदेश
- सिर्फ़ कार्रवाई ही असली अमल है, और बाकी सब उसका विकल्प नहीं है
- छोटे स्तर पर ही सही, शुरू करना, असफलता स्वीकार करना, और खुद करके देखना ही आगे बढ़ने का एकमात्र रास्ता है
- लेख का अंतिम वाक्य “अब मुझे फिर से काम पर लौटना चाहिए” तुरंत अमल करने वाले रवैये का प्रतीक है
2 टिप्पणियां
मेरे जैसे लोगों के लिए, जिन्हें चीज़ों को अमल में लाने में दिक्कत होती है, यह बहुत अच्छा वाक्य है।
Hacker News की राय
“Doing it badly” वाले सिद्धांत ने मेरी सोच पूरी तरह बदल दी
मैंने perfect architecture डिज़ाइन करने में हफ्तों लगा दिए, लेकिन आखिरकार planning रोककर अपने problem को solve करने वाला एक rough version बना लिया
हैरानी की बात यह थी कि उस पहले version ने मुझे ऐसी बातें सिखाईं जो planning से कभी नहीं सीख पाता। users वास्तव में किस चीज़ की परवाह करते हैं, production में कौन से edge cases मायने रखते हैं, और ‘good enough’ वास्तव में कैसा दिखता है — यह सब समझ आया
सबसे कठिन बात यह है कि defects होने का पता होने के बावजूद deploy करने की अनुमति देना। लेकिन real-world usage से मिलने वाला feedback loop कई हफ्तों की काल्पनिक चर्चा से कहीं अधिक मूल्यवान था
आजकल productivity से जुड़े subreddits पर ऐसे posts भरे पड़े हैं। personal automation tool बनाते हुए कोई हफ्तों तक architecture plan करता रहे, यह कितना realistic है, इस पर संदेह है
लेखक की comment history देखें तो वही मिलता-जुलता writing style बार-बार दिखता है, इसलिए भरोसा नहीं होता
वह process देखना सचमुच दिलचस्प था
चीज़ों को वास्तव में implement करने और refactor करने की process में problem और programming दोनों के बारे में बहुत कुछ सीखने को मिलता है
शुरू में सोची गई abstractions ज़्यादातर गलत निकलती हैं। implement करते-करते structure पूरी तरह बदल जाता है, और आखिर में शुरुआत से बिल्कुल अलग beautiful code निकलता है
बात यह है कि पहला version इस इरादे से बनाओ कि उसे फेंकना पड़ेगा, लेकिन व्यवहार में ज़्यादातर लोग उसे फेंकते नहीं, बल्कि iteration से बेहतर बनाते जाते हैं
अब tools और process की वजह से लगातार iterate करना संभव हो गया है
internal structure में भी iteration और prototyping चाहिए, लेकिन data structures, error handling, logging, naming जैसी चीज़ें शुरू में सोच-समझकर तय करनी चाहिए ताकि बाद में तेजी से सुधार किया जा सके
“Doing it badly is doing the thing” यह पंक्ति मुझे बहुत पसंद आई
HN से सीखा हुआ सबक है: जब अटक जाओ, तो perfect करने के बारे में सोचते रहने के बजाय बस शुरू कर दो
शुरुआत में चीज़ें बिखरी हुई हों तो भी, धीरे-धीरे सुधार करते-करते एक समय बाद साफ तस्वीर दिखने लगती है। यह किसी जादू जैसा लगता है
एक है Dan Harmon की writer’s block पर सलाह, और
दूसरी है Ira Glass का “The Gap”
मूल बात यह है कि perfection का इंतज़ार मत करो; बहुत खराब draft भी लिखो, फिर उसे आलोचक की नज़र से सुधारते जाओ
इसलिए आजकल मैं जानबूझकर कहता हूँ, “अभी तैयार नहीं है,” जब तक वह सच में पूरा न हो जाए
मैं पहले जल्दी से बना लेता हूँ, फिर polish करता हूँ, और अंत में दोबारा नया लिखता हूँ
अहम बात है beta stage में perfectionism में न फँसना
अगर incremental improvement सच में effective है, तो फिर वह इंसान करे या AI, इससे क्या फर्क पड़ता है
मेरी पुरानी company में management को हम “problem admiration society” कहते थे
वे problem पर चर्चा करते थे, analysis करते थे, ज़िम्मेदार खोजते थे, लेकिन उसे वास्तव में solve नहीं करते थे
आखिरकार जो मायने रखता था, वह था ‘वास्तव में करना’
सबसे अच्छा approach है problem के प्रति लगाव और उसे बार-बार solve करने की इच्छा — दोनों को साथ रखना
internally इस्तेमाल होने वाला dogfooding उस balance को बनाए रखने का अच्छा तरीका है
जहाँ तक हो सके, फैसले अपने पक्ष में मोड़ना ज़रूरी है
updates के लिए कम coordination चाहिए होता है, और जो organization सच में काम करती है वह ज्यादा efficient होती है
यह लेख strangestloop.io के essay से बहुत मिलता-जुलता है
title देखकर लगा कि यह जाना-पहचाना है, लेकिन click करने पर दूसरी site निकली, और post का समय भी कुछ दिन पहले का था, इसलिए और हैरानी हुई
content इतना मिलता है कि इसे संयोग कहना मुश्किल है
पहले मैं सोचता था कि preparation बहुत महत्वपूर्ण है, लेकिन एक समय पर समझ आया कि preparation खुद एक infinite loop बन सकती है
हमारी team ने 2-page spec के साथ 4 महीनों में product पूरा कर लिया, जबकि competitor team 8 महीने तक documents ही लिखती रही और अंत में भंग हो गई
planning का 20% ही 80% problems पकड़ लेता है। उसके बाद का हिस्सा अक्सर anxiety को rigor का रूप देकर पेश करना भर होता है
आखिर में मैंने ज़्यादातर चीज़ें वही सीखीं जिन्हें पहले शर्मिंदगी के साथ बाहर निकालना पड़ा और फिर सुधारना पड़ा
इसे पुरानी HN comment में quote किया गया था
Analysis paralysis सचमुच एक वास्तविक चीज़ है
रुकने से बचना है तो पहले शुरू करना होगा। पहले happy path को संभालो, edge cases बाद में polish कर लेना
आजकल prototype बनाने की cost कम है, इसलिए failure से डरे बिना कोशिश करनी चाहिए
LLM के हैरान कर देने वाले effective होने की एक वजह भी यही है — वे analysis की जगह तुरंत execution करते हैं
result perfect न भी हो, तो अक्सर उपयोगी होता है; ज़रूरत पड़े तो बाद में optimize किया जा सकता है
framework बनाने से पहले कम-से-कम तीन बार वास्तविक systems बना लेने चाहिए। तभी समझ आता है कि कहाँ ज्यादा हो गया और कहाँ कमी रह गई
‘काफी ठीक है’ कहना self-deception भी हो सकता है
असफल prototype यह साबित नहीं करता कि market ही नहीं है। वह सिर्फ इस बात का संकेत है कि कुछ कमी रह गई थी
यह लेख पुरानी post जैसा लगभग वही message देता है
पुरानी HN चर्चा में भी इस पर बात हुई थी
दूसरी तरफ, कभी-कभी ‘doing the thing’ खुद ही गलत चुनाव होता है
इसलिए मैं अब भी design docs और code review पर ज़ोर देता हूँ
GenAI के दौर में ‘बिना planning के बस कर देखना’ बहुत आसान हो गया है, इसलिए उतना ही counterbalance भी चाहिए
non-determinism और latency की समस्याओं में ही समय निकल जाता है, और आखिरकार unit economics मिलाना ही असली चुनौती बन जाता है
『Remains of The Day』 में ‘the thing के बारे में सिर्फ बात करना’ को self-indulgent act कहा गया है
अक्सर यह ऐसी बातचीत बन जाती है जिसमें कुछ हासिल नहीं होता, बस लोगों को अच्छा महसूस होता है
दूसरी ओर, planning, preparation, और mise-en-place वास्तविक execution में मदद कर सकते हैं