पहिए को फिर से आविष्कार करें - Reinvent the Wheel

• "पहिए को फिर से आविष्कार मत करो" जैसी सलाह रचनात्मकता और जिज्ञासा को दबाने वाला नकारात्मक प्रभाव डाल सकती है
• एक नया पहिया, यानी मौजूदा tools या technology को फिर से रचना, गहरी समझ और सीख देता है
• साधारण या परिचित दिखने वाले मूलभूत building blocks भी वास्तव में जटिलता और कई तरह के trade-offs समेटे होते हैं
• अपना खुद का पहिया बनाकर देखने से growth, problem solving, और experimentation की क्षमता मजबूत होती है
• मौजूदा परिणामों का उपयोग और पुनर्रचना के बीच उद्देश्य के अनुसार संतुलित चुनाव करने की ज़रूरत पर ज़ोर दिया गया है

---

Reinvent the Wheel

• "पहिए को फिर से आविष्कार मत करो" कहने का इरादा अच्छा हो सकता है, लेकिन यह सलाह आमतौर पर दो तरह के लोगों से आती है
  • वे लोग जिन्होंने खुद पहिया बनाकर उसकी कठिनाई का अनुभव किया है
  • वे लोग जिन्होंने कभी कोशिश नहीं की, लेकिन पुरानी सलाह को बिना सोचे दोहराते हैं
• जब ऐसी सलाह बार-बार दोहराई जाती है, तो जिज्ञासा और खोजी मानसिकता को दबाने वाला माहौल बनता है
• अगर सबने यह सलाह मान ली होती, तो आज की कई आधुनिक सुविधाएँ और प्रगति शायद संभव नहीं होतीं
• वास्तव में पहिया अपनी शुरुआती खोज के बाद भी कई बार फिर से गढ़ा गया है और लगातार विकसित हुआ है

नोट: यहाँ 'पहिया' को किसी भी tool, protocol, service, technology, या अन्य रचना के रूप में समझा जा सकता है

पहिया खुद बनाना ही सीखना है

"जिसे मैं बना नहीं सकता, उसे मैं समझता हूँ, यह नहीं कह सकता।"
— Richard Feynman

• किसी चीज़ को वास्तव में गहराई से समझने के लिए उसका छोटा सा version भी खुद implement करने का अनुभव ज़रूरी है
• भले ही परिणाम पूरी तरह perfect न हो, या बाद में इस्तेमाल भी न किया जाए, उसे बनाने की प्रक्रिया अपने आप में महत्वपूर्ण है
• computer science की कई अवधारणाएँ—protocols, encryption, web servers आदि—मुश्किल लग सकती हैं, लेकिन वास्तव में कोई भी उन्हें आज़मा सकता है
• जब अधिक लोग खुद चीज़ें बनाकर देखते हैं, तो उन्हें मौजूदा technology की संरचना और सार को समझने का मौका मिलता है

हर चीज़ अंतहीन खोज की प्रक्रिया है (Rabbit Hole)

• जिन बुनियादी building blocks को हम स्वाभाविक मान लेते हैं—जैसे strings, file paths आदि—वे भी वास्तव में बहुत जटिल होते हैं
• अपनी खुद की string या path library implement करने की कोशिश बहुत बड़ी सीख बन सकती है
• इस प्रक्रिया से यह समझ आती है
  • रोज़मर्रा की चीज़ों में भी लगभग असीम जटिलता छिपी होती है
  • दूसरों के लिए उपयोगी कुछ बनाना विनम्रता सीखने का अवसर है
  • हर abstraction इंसानों ने बनाई है, वह परिपूर्ण नहीं होती, और उसके अपने (या अलग) trade-offs हो सकते हैं
• implement करते समय correctness, simplicity, performance, scalability, portability जैसी कई पसंदों और समस्याओं का सामना होता है
• आपका बनाया समाधान कुछ क्षेत्रों में बेहतरीन हो सकता है, लेकिन हर user या हर स्थिति के लिए उपयुक्त नहीं होगा
• मौजूदा solutions की भी सीमाएँ होती हैं, और वे मेरी समस्या के लिए सही न हों, ऐसा भी हो सकता है
• किसी एक समस्या में गहराई तक उतरने का अनुभव engineer के रूप में बढ़ने की प्रक्रिया है
• अगर आप बस बार-बार projects बदलते रहेंगे, तो अर्थपूर्ण सीख हासिल नहीं होगी

पहिए को फिर से आविष्कार करने के कारण

• मौजूदा से बेहतर पहिया बनाना (और 'बेहतर' की परिभाषा अलग-अलग हो सकती है)
• यह सीखना कि पहिया बनाया कैसे जाता है
• दूसरों को पहिए का सिद्धांत सिखाने का शैक्षिक उद्देश्य
• पहिए के आविष्कार की प्रक्रिया को समझते हुए नई अंतर्दृष्टि पाना
• खराब होने पर खुद मरम्मत या सुधार कर सकने की क्षमता विकसित करना
• पहिया बनाने के लिए ज़रूरी अलग-अलग tools और techniques सीखना
• किसी बड़े system (जैसे कार) के हिस्से के रूप में पहिए की भूमिका समझना
• किसी खास ज़रूरत के लिए बहुत विशेष पहिया बनाने की कोशिश (जैसे wheelchair, skateboard, pottery wheel आदि)
• यह भी संभव है कि आपका बनाया पहिया अपने मूल उद्देश्य से अलग किसी और काम में ज़्यादा उपयोगी निकले
• दुनिया में ढर्रे से हटकर नए विचारों की भी महत्वपूर्ण भूमिका हो सकती है

Reuse vs Reinvent

• दूसरों के काम को नज़रअंदाज़ नहीं करना चाहिए; उनके काम का अध्ययन करके जहाँ उचित हो वहाँ उसका उपयोग करना चाहिए
• केवल अविश्वास या अज्ञानता के कारण मौजूदा चीज़ों को छोड़कर नया बनाने से बचना चाहिए
• लेकिन अगर आप खुद implement या experiment नहीं करेंगे, तो उस क्षेत्र की मूल समझ और प्रगति हासिल करना कठिन होगा
• software engineering में छोटे experiments और prototypes बनाना आसान और तेज़ होता है, इसलिए यह व्यक्तिगत समस्याओं के समाधान में प्रभावी है
• छोटे से शुरू करो, सरल बनाओ, और दोहराते रहो — यह तरीका सुझाया गया है
• इसलिए मेरी आख़िरी सलाह यह है
  • अगर insight चाहिए, तो खुद फिर से आविष्कार करने की चुनौती लो
  • अगर impact चाहिए, तो पहले से प्रमाणित solutions का reuse करो

"Reinvent for insight. Reuse for impact."
"अंतर्दृष्टि के लिए पुनराविष्कार करो, प्रभाव के लिए reuse करो।"

[nullvana]

चौकोर पहियों को गोल बनाने की कोशिश की तो बॉस की वह बात याद आ गई कि पहिया फिर से मत बनाओ। "पहिया-फिर-से-मत-बनाओ" वाला भूत आज भी आसपास बहुत है।

[dhlee0305]

"गाय खोने के बाद ही बाड़ा ठीक करता है" का मतलब यह नहीं है कि भविष्य की तैयारी मत करो,
उसी तरह "पहिया दोबारा मत बनाओ" का मतलब भी यह नहीं है कि अंतर्दृष्टि पाने में समय मत लगाओ।
ऐसी बातें किस संदर्भ में कही गई थीं, उसे आगे-पीछे से काट दें तो उनका असली मतलब विकृत हो जाता है.

[hided62]

यह हाल का अनुभव है, लेकिन मैंने हाल ही में अपना एक बहुत ही खास पहिया बनाया।
Nuxt में 1000-पेज वाले ऐप को build करने में 7 मिनट लग रहे थे,
लेकिन कुछ automation छोड़कर उसे फिर से लिखने के बाद मैं 20 सेकंड का build हासिल करने में सफल हुआ।

[aer0700]

यह तय करना मुश्किल होता है कि कहाँ तक दोबारा खुद बनाना है और कहाँ तक बाहरी dependencies पर भरोसा करना है.
किसी भी स्थिति में, सिर्फ समय बचाने के लिए ऐसी dependency चुनना जिसे मैं खुद बना सकता हूँ, और उस dependency के बिना सेवा ही नहीं बना पाने के कारण उसी पर बंध जाना — ये दोनों बिल्कुल अलग बातें हैं.
यह हर तरह के code पर लागू नहीं हो सकता (जैसे operating system), लेकिन जितना हो सके उतना पहले वाले रुख की ओर बढ़ने की कोशिश करना system को समझने में मदद करेगा.

[howudoin]

कहावतों में एक निहित अर्थ होता है, लेकिन अब बहुत लोग उन्हें सिर्फ शब्दशः ही समझते हैं
अगर ऐसी दलीलें ट्रेंड में आ जाएँ, तो फिर मीटिंग रूम बिना किसी झिझक के फिर से अराजकता का शिकार हो जाता है
पेपरवर्क वाले लोग उत्साह में उछलने लगते हैं और वही असफलता हर साल फिर दोहराई जाती है

[GN⁺]

Hacker News राय

• मैंने एक खास क्षेत्र में अपनी तरफ़ से पहिया फिर से बनाने का अनुभव किया है। मैंने शुरुआत से ऐसा करने की योजना नहीं बनाई थी, बल्कि इसलिए किया क्योंकि मुझे लगा कि मौजूदा तकनीक गलत थी। मैंने उस समस्या को, जिसे आम तौर पर असंभव कहा जाता था, divide-and-conquer तरीके से हल किया। मैं भाग्यशाली था, और ज़िद्दी भी, इसलिए आख़िरकार सफल हुआ। मेरा पहिया उस क्षेत्र में दबदबे वाला प्रदर्शन दिखाता है। प्रयोग करके देखा तो जो चीज़ें पहले असंभव मानी जाती थीं, वे भी बहुत आसानी से होने लगीं। समय के साथ, उस क्षेत्र के दूसरे लोग भी मेरा पहिया इस्तेमाल करने लगे। शुरुआत में सब उलझन में पड़ जाते हैं, लेकिन एक बार सीख लें तो फिर कभी पुराने तरीके पर वापस नहीं जाते। दुनिया भर से अजीब use cases और workflows के लिए bug reports और feature requests मिलती हैं। ऐसे बुद्धिमान लोगों के साथ गहरी तकनीकी बातचीत होती है जिनसे मेरी मुलाकात कभी नहीं होती। मैं देखता हूँ कि लोग मेरे बनाए पहिए से ऐसी उपलब्धियाँ हासिल कर रहे हैं, जिनकी किसी ने कल्पना भी नहीं की थी। नई खोजें होती हैं जो रातों की नींद उड़ा देती हैं। और अपने सहकर्मियों को मेरे पहिए की capabilities समझाते समय उनका दिमाग़ freeze होते देखना भी मज़ेदार होता है। पहिया फिर से बनाने से डरने की ज़रूरत नहीं है। कोई नहीं जानता कि वह किस पागल दिशा में लुढ़क जाएगा

  • यह पहिया क्या है, इसे लेकर मैं बहुत जिज्ञासु हूँ

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

• पहिया फिर से बनाने की एक अहम वजह यह है कि बेकार dependencies की वजह से आने वाली अनावश्यक जटिलता से बचा जा सके

  • इस बात से मैं पूरी तरह सहमत हूँ। मशहूर libraries कई तरह की परिस्थितियों में समस्याएँ हल करने के लिए बनाई जाती हैं, और इसलिए उनमें अक्सर बहुत-सा अनावश्यक code शामिल होता है। अहम बात यह है कि अगर मैं कम समय में अपनी ज़रूरत की functionality बना सकता हूँ, तो उसे खुद बनाना usability के लिहाज़ से भी बेहतर है और dependencies भी कम रखता है। बस cryptography libraries को खुद बनाने की मैं बिल्कुल सलाह नहीं दूँगा

  • मेरे लिए पहिया फिर से बनाने की सबसे बड़ी वजह यही है। dependencies के साथ कई ऐसी सुविधाएँ भी साथ आती हैं जो मुझे नहीं चाहिए। मुझे तो बस इतना चाहिए कि मोहल्ले की किराने की दुकान तक जाकर लौट आऊँ। और निजी तौर पर मैं ऐसे code पर भरोसा नहीं करता जो पारदर्शी न हो। dependency इस्तेमाल करूँ भी, तो वह ऐसी होनी चाहिए जिसे मैं खुद एक दिन लगाकर बना सकता हूँ और review भी कर सकता हूँ। जिन executables का source code नहीं देख सकता, उन्हें मैं तब तक इस्तेमाल नहीं करता जब तक उन्हें खरीद न लूँ। अगर वह मुफ़्त है, तो source code ज़रूर खुला होना चाहिए

  • मैंने DAG (directed acyclic graph) आधारित task runner library खुद बनाई। tasks को queues से जोड़ा जा सके, ऐसा बनाया। demo को web browser में चलाना था, इसलिए IndexedDB backend बनाया; Electron app के लिए SQLite, और multi-user server environment के लिए Postgres backend अलग से implement किया। फिर rate limiting के लिए limiter भी जोड़ा। इसके अलावा graph processing और task processing जैसी कई और चीज़ों के पहिए भी खुद बनाने पड़े। पूरी तरह dependency-free बनाना हो तो सच में बहुत काम होता है। लेकिन task input/output schema बनाने और validate करने के लिए TypeBox वाला एक branch अलग रख रहा हूँ। आख़िरकार लग रहा है कि core में एक और dependency जुड़ सकती है

  • एक और वजह यह है कि नई चीज़ें invent करने या research करने की क्षमता अभ्यास से निखारी जा सकती है। पहले से हल की जा चुकी समस्याओं से भी अच्छा अभ्यास हो सकता है

  • कभी-कभी मैं अनावश्यक abstraction या modularization जैसी जटिलताओं से बचने के लिए भी पहिया फिर से बनाता हूँ

• साथ बैठकर सोचने लायक एक अच्छा निबंध था। मेरा भी ऐसा ही अनुभव रहा है; मैंने सिर्फ Python और NumPy का इस्तेमाल करके PyTorch-स्टाइल machine learning library (ml-by-hand) शुरू से बनाई। मैंने एक छोटे autograd engine से शुरुआत की और फिर layers, optimizers, dataloaders वगैरह को चरण-दर-चरण खुद implement किया। शुरुआत सिर्फ़ मूल सिद्धांतों को सीखने के लिए की थी। अपनी इसी library से मैंने क्लासिक convolutional neural network (cnn example) से लेकर एक साधारण GPT-2 (gpt2 example) तक दोबारा बनाकर देखा। PyTorch या TensorFlow की abstractions के बिना machine learning अंदर से कैसे काम करता है, इसकी समझ मुझे बहुत बेहतर हुई। ऐसा लगा जैसे मैंने अपने फिर से बनाए पहिए से आगे बढ़कर पूरी कार भी खुद बना ली

• “पहिया फिर से मत बनाओ” कहने वाले लोग आम तौर पर दो तरह के होते हैं—इस बात में मैं जोड़ना चाहूँगा कि असल में एक तीसरी, और कहीं ज़्यादा आम किस्म भी है। वे लोग जो पहिया दोबारा बनाने की कठिनाइयों को सचमुच जानते हैं, उस प्रक्रिया से गुज़र चुके हैं, और फिर भी यह तय करते हैं कि इसे खुद करना बिल्कुल भी worthwhile नहीं है। चाहे शैक्षिक कारण से ही क्यों न हो, उन्हें इसमें खुद हाथ डालना भी सार्थक नहीं लगता

  • मुझे यह किस्म ज़्यादा यथार्थवादी लगती है। ये लोग मौजूदा तरीक़ों या status quo पर अंधविश्वास नहीं करते, बल्कि कई बार पुराने तरीक़ों से ही डरते हैं

• पहिया फिर से बनाना सीखने का सबसे अच्छा तरीका है। लेकिन मुझे लगता है कि यह बात सिर्फ़ learning context में सही है। मुझे भी किसी चीज़ में गहराई तक जाना पसंद है, लेकिन कंपनी में deadlines और दूसरी सीमाओं की वजह से अक्सर खुलकर exploration नहीं कर पाता। अगर वह बनाया हुआ पहिया सचमुच production service में इस्तेमाल होना है, तो मेरा मानना है कि उसे मौजूदा विकल्पों से सच में बेहतर होना चाहिए

  • नौकरी में पहिया फिर से बनाने वाले 99% लोग तो यह भी ठीक से नहीं जानते कि मौजूदा पहिया कैसे बना है, या उसमें ऐसे trade-offs क्यों हैं

  • खुद बनाना ज़रूरी नहीं कि सीखने का सबसे अच्छा तरीका ही हो। इसमें समय और लागत दोनों बहुत लगते हैं। अगर अच्छी documentation और प्रयोग के लिए environment उपलब्ध हो, तो काफ़ी कुछ सीखा जा सकता है। ज्ञान को साफ़-साफ़ पहुँचाना अपने आप में एक अलग चुनौती है। हर चीज़ को ज़मीन से फिर से बनाना ज़रूरी नहीं

• मैं सरकारी सिस्टमों को global स्तर पर फिर से implement करने का एक प्रयोग कर रहा हूँ। यह असली सरकार से अलग है। जैसे ua.gov-ai.co, ua.ai-gov.co, ng.gov-ai.co, ng.ai-gov.co वगैरह। अभी तक CBER और DDP में सबसे ज़्यादा प्रगति हुई है। अब तक 422 agencies तक पहुँच चुका हूँ। Juneteenth तक इसे पूरा करना चाहता हूँ। इस तरह बुनियादों को फिर से बनाते हुए मुझे मूल सिद्धांतों को समझने में मदद मिल रही है। मुझे पता है कि इससे शायद कोई वास्तविक परिणाम नहीं निकलेगा, लेकिन जब-जब मूल स्वभाव बदलता है, तब-तब अपने विचारों को फिर से व्यवस्थित करने में यह उपयोगी साबित होता है। मेरे हिसाब से पहिया फिर से बनाने का प्रयोग हमेशा सार्थक होता है

• अगर आप startup में काम करते हैं, तो मुझे लगता है कि इस तरह की सलाह को जहाँ तक हो सके नज़रअंदाज़ करना चाहिए। (हाँ, अगर नया बनाया जाने वाला पहिया आपकी service के core performance का हिस्सा हो, तो बात अलग है।) नहीं तो सीमित resources सिर्फ़ बर्बाद होंगे और कारोबार शुरू होने से पहले ही खत्म हो सकता है

  • फिर भी startup में ऐसे लोगों का साथ होना ज़रूरी है जिन्होंने खुद पहिया बनाया हो, यानी जो सचमुच पहिया बनाना जानते हों। चाहे open source हो या personal project, ऐसा अनुभव होना चाहिए

  • मुझे लगता है यह सलाह पेशेवर काम के लिए नहीं, बल्कि व्यक्तिगत learning के लिए पहिया-प्रयोग करने के बारे में है

• एक दोस्त की कही बात याद आ रही है। “हम पहिया फिर से इसलिए नहीं बनाते कि हमें और पहियों की ज़रूरत है, बल्कि इसलिए कि हमें और inventors की ज़रूरत है।” कई बार नए concepts सीखने के लिए कुछ खुद बनाते हुए मुझे दिमाग़ी और भावनात्मक स्थिरता मिली है। फ़ाइनमैन का यह कथन—“जो मैं बना नहीं सकता, उसे मैं समझता भी नहीं”—पढ़ने के बाद इस तरह के अनुभव और विश्वास और मज़बूत हुए। हर बार जब मैं कोई पहिया फिर से बनाता हूँ, तो मूल अवधारणा के लिए मेरी intuition और मज़बूत हो जाती है, और मैं ऐसी बातें भी सीखता हूँ जिनके बारे में पहले कुछ नहीं जानता था

• मुझे लगता है कि duplication के प्रति हमारी पीढ़ी का अति-विरोध ही समस्या है। सब एक जैसे होते जा रहे हैं, एक जैसा खाना खाते हैं, मिलते-जुलते पेशों में हैं, और लगभग समान ज़रूरतों के मुताबिक़ चलते हैं। अगर “पहिया फिर से मत बनाओ” जैसे संदेश को चरम तक धकेल दिया जाए, तो आख़िरकार आदर्श यही रह जाएगा कि हम कुछ अमीर लोगों की बेहद खास ज़रूरतों के हिसाब से ढले हुए, और किसी भी असली चीज़ से अनजान इंसान बन जाएँ। एक ऐसी ज़िंदगी जिसमें हम न खाना बनाना सीखें, न खेती, न प्यार

  • लेकिन इसका यह मतलब नहीं कि “पहिया फिर से मत बनाओ” वाला कथन बिना सोचे-समझे कहा जाता है, या उसका अर्थ हमेशा आसान रास्ता चुनना होता है। उदाहरण के लिए, अगर कार का टायर पंचर हो जाए, तो पहिए के बारे में उपलब्ध अलग-अलग विकल्पों पर ठीक से विचार करना चाहिए। पहिया फिर से बनाने की ज़रूरत नहीं है। spare tire दिया ही इसलिए जाता है। निर्माता के बनाए पहिए से बेहतर मेरा जल्दी-जल्दी बनाया हुआ पहिया होने की संभावना लगभग नहीं के बराबर है

[kandk]

क्या कंपनी सीखने की जगह है? या वह जगह जहाँ दूसरों के बनाए पहिए को लेकर मूल्य को फिर से रचा जाता है?

[aer0700]

बनाना तो बस शुरुआत है, और अगर आप करीब 10 साल तक कोई सेवा चलाते हैं, तो बीच में हर तरह की चीज़ें होंगी; वहाँ टिके रहने के लिए बुनियाद चाहिए होगी... सीखना पड़ेगा।