समझ की खुशी और ताकत

 (binaryigor.com)
3 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सॉफ़्टवेयर को गहराई से समझने पर व्यक्ति tools के पीछे नहीं घिसटता, बल्कि जिस system की ज़िम्मेदारी उसके पास है उस पर control और ownership रख सकता है
  • search और LLM तेज़ जवाब देते हैं, लेकिन ऐसे solutions को कॉपी करने की आदत जिन्हें हम समझा नहीं सकते, हमारी सुधारने की क्षमता और core competency को कमज़ोर कर सकती है
  • one-off scripts या कम-जोखिम वाले internal UI में generation और copy-paste व्यावहारिक हो सकते हैं, लेकिन लंबे समय तक maintain होने वाले code को गहराई से समझी हुई तकनीक से बनाना चाहिए
  • अगर productivity को सिर्फ code lines या PR की संख्या जैसे output से मापा जाए, तो उसे आसानी से विकृत किया जा सकता है; stable releases, simplification, automation, testing जैसे outcome लंबे समय के value के ज़्यादा करीब हैं
  • आधुनिक सॉफ़्टवेयर runtime, network, security, database और AI तक जटिल हो चुका है, लेकिन मूल सिद्धांत सीख लेने पर नए tools और approaches को ज़्यादा तेज़ी से समझा जा सकता है

समझ से मिलने वाला नियंत्रण और आनंद

  • गहरी समझ code और systems को ठीक करने और बदलने के लिए व्यावहारिक शर्त है
  • जिसे हम समझते नहीं, उसे modify या change करना मुश्किल होता है, और अंततः जिस code की ज़िम्मेदारी हमारे पास है उस पर control और ownership भी कमज़ोर हो जाते हैं
  • समझ न केवल हमें tools का मालिक बनाती है, बल्कि मानसिक रूप से संतुष्टि भी देती है
  • जो व्यवहार हमें अपने environment पर बेहतर नियंत्रण देता है, उसका positive emotions से जुड़ना स्वाभाविक माना जा सकता है

इंसानी आलस्य और LLM पर निर्भरता

  • इंसान में energy खर्च कम करने और investment के मुकाबले reward बढ़ाने की प्रवृत्ति होती है
  • यह आलस्य उबाऊ और महंगे कामों को automate करने की प्रेरणा बन सकता है, लेकिन learning और mastery में यह कमज़ोरी भी साबित हो सकता है
  • internet और LLM की वजह से मिलती-जुलती समस्याओं के जवाब मनचाहे रूप में आसानी से मिल जाते हैं, इसलिए understanding की प्रक्रिया को छोड़ देना आसान हो गया है
  • SQL सीधे सीखने के बजाय tables और चाहिए data को LLM को बताकर सिर्फ result कॉपी कर लेना अभी के लिए आसान लग सकता है, लेकिन उसे सही तरह से संभालने की क्षमता नहीं बनती
  • चाहे LLM SQL और तेज़ी से बना दे, अतीत में खुद बार-बार करके विकसित की गई पढ़ने और समझने की क्षमता इस्तेमाल न करने पर घटती जाती है
  • LLM और search engines सबसे अच्छे हाल में capability amplifier (force multiplier) हैं, लेकिन इसके लिए पहले मज़बूत basics होना ज़रूरी है
  • core skills और knowledge को सिर्फ search, prompting और manual verification से बनाए रखना मुश्किल है; उसके लिए खुद build करने और create करने की प्रक्रिया में शामिल होना पड़ता है
  • नियमित रूप से अपने आलसी स्वभाव के खिलाफ जाकर documentation और source पढ़ना, solutions के पीछे के कारण और tools के trade-offs समझना, और solutions तथा algorithms को खुद design करना ज़रूरी है

अल्पकालिक productivity और दीर्घकालिक समझ का संतुलन

  • हर code और हर solution को पूरी तरह समझना ज़रूरी नहीं है; स्थिति के अनुसार मानक अलग हो सकते हैं
  • कम महत्व और कम जोखिम वाले one-off scripts को कॉपी करना या generate करना ठीक हो सकता है
  • दो-तीन लोगों द्वारा उपयोग किए जाने वाले internal UI या pages में भी यही तरीका स्वीकार्य हो सकता है
  • जिस code का ownership, maintenance और evolution महीनों या वर्षों तक करना है, उसे ऐसी language और technology में बनाना चाहिए जिसे आप गहराई से जानते हों
    • हर line, शब्द, character और configuration option को समझ सकें, या कम-से-कम उस दिशा में बढ़ रहे हों
    • अभी तुरंत ज़्यादा output देने से अधिक, long-term understanding, maintainability और productivity को optimize करना चाहिए
  • MVP या किसी existing product के भीतर experimental features जैसे मामलों में, जहाँ सफलता अनिश्चित हो, quality और understanding के standards थोड़े कम किए जा सकते हैं
  • ऐसा चुनाव cognitive debt लेने जैसा है
    • अभी आप तेज़ी से आगे बढ़ सकते हैं
    • लेकिन जब product या feature चलने लगे, या उसमें fix/change की ज़रूरत पड़े, तो बाद में ज़्यादा चुकाना होगा
  • फिर भी कम-से-कम इतना समझना और verify करना चाहिए कि आप आत्मविश्वास से कह सकें, “यह काम करता है”
  • कुछ मामलों में generate करने के बाद verify करना और फिर शुरू से दोबारा लिखना एक व्यावहारिक strategy हो सकती है

tech stack और mastery का compounding effect

  • अगर कोई programming language, library या tool कभी-कभार ही इस्तेमाल होता है, तो गहरी learning और mastery में बहुत समय लगाना ज़रूरी नहीं
  • अगर आप result को verify कर सकते हैं, तो आंशिक समझ के साथ copy या generate करना कभी-कभी ठीक हो सकता है
  • लेकिन learning और struggle के चरण को छोड़ देने पर, आप उसी technology में skilled और productive बनने की अपनी संभावना खुद कम कर देते हैं
  • नियमित रूप से उपयोग होने वाले core tech stack में mastery का फल सैकड़ों या हज़ारों गुना मिल सकता है
  • knowledge और skills में compounding effect होता है
    • जितना ज़्यादा आप जानते हैं, उतनी तेज़ी से खुद बना सकते हैं
    • नया knowledge और skills भी समय के साथ और तेज़ी से सीखे जा सकते हैं
    • capability बढ़ने के साथ नए solutions और ideas भी सूझने लगते हैं

Output से ज़्यादा Outcome पर आधारित productivity

  • productivity को समझने और मापने के तरीके broadly output-centric और outcome-centric में बाँटे जा सकते हैं
  • output को मापना आसान है और उसे numbers में गिनना भी सरल है
    • लिखी गई code lines की संख्या
    • खोले और merge किए गए PR की संख्या
    • implement किए गए features की संख्या
    • खोजे और ठीक किए गए bugs की संख्या
    • पूरे किए गए tasks की संख्या
  • output-केंद्रित metrics को आसानी से manipulate किया जा सकता है
    • unnecessarily लंबा code लिखा जा सकता है
    • बहुत सारे छोटे PR बनाए जा सकते हैं
    • काम को कृत्रिम रूप से छोटे हिस्सों में बाँटा जा सकता है
    • बेकार features जोड़े जा सकते हैं
  • numbers बढ़ने से यह तय नहीं होता कि दिशा सही है
    • PR ज़्यादा होना अपने-आप में अच्छा नहीं है
    • codebase का बड़ा होना भी हमेशा वांछनीय नहीं होता
    • कई बार नए features जोड़ने के बजाय unused features हटाना बेहतर होता है
  • outcome-केंद्रित examples long-term value से अधिक सीधे जुड़े होते हैं
    • नई CI/CD process से production release ज़्यादा stable हो गया
    • refactoring और simplification से maintenance और future changes आसान हो गए
    • integration solution के redesign से नए partners को जोड़ना तेज़ हुआ और computing resources बचे
    • testing बढ़ाकर bugs को पहले ही पकड़ लिया गया और regression रोके गए
    • metrics और alerts जोड़कर संभावित समस्याएँ और bugs पहले से पकड़े गए
    • उबाऊ manual work को automate करके समय बचाया गया और critical errors की संभावना कम हुई
  • long-term productivity और understanding outcome-केंद्रित metrics से ज़्यादा मेल खाते हैं, और ज़्यादा output हमेशा बेहतर नहीं होता

जटिल होती सॉफ़्टवेयर दुनिया और मूल सिद्धांत

  • software engineering का मूल theorem अक्सर इस वाक्य में समेटा जाता है: “computer science की किसी भी समस्या को एक और indirection layer से हल किया जा सकता है, सिवाय बहुत ज़्यादा indirection layers की समस्या के”
  • आधुनिक software development कई layers और elements की वजह से बहुत जटिल है
    • runtime और platforms: browser, server, cloud, mobile, desktop, embedded
    • network: HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC, database और message broker protocols
    • security, authentication, authorization
    • operating systems
    • virtualization, containerization, Kubernetes-श्रेणी orchestration
    • databases: SQL, NoSQL, local, remote, distributed
    • high-level programming languages और compiler, interpreter, transpiler pipelines
    • libraries, frameworks, package managers
    • API और external services
    • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
    • LLM और AI
  • इस complexity से निपटने के कारण भी मौजूद हैं
    • कई systems जरूरत से ज़्यादा design किए जाते हैं और उन्हें काफ़ी simplify किया जा सकता है
    • किसी विशेष अवधि में आमतौर पर software development landscape के सिर्फ छोटे हिस्से में विशेषज्ञता काफ़ी होती है
    • बाकी के लिए awareness-level समझ भी पर्याप्त हो सकती है
    • tools के पीछे के सामान्य patterns और principles सीख लेने पर नए tools, approaches और technologies सीखने में leverage मिलता है

मूल सिद्धांतों का दायरा और प्रभाव

  • मूल सिद्धांत वे बुनियादी और अपेक्षाकृत स्थिर rules, constraints और mechanisms हैं जो software development में इस्तेमाल होने वाले tools, libraries, frameworks, protocols और components के नीचे काम करते हैं
  • इसके मुख्य दायरे में कई क्षेत्र आते हैं
    • computer architecture और hardware: CPU structure, instruction execution, memory hierarchy, registers, cache, storage devices
    • machine code, assembly, high-level languages: assembler, compiler, interpreter की ज़रूरत क्यों होती है, और अलग-अलग language types के trade-offs
    • operating systems: processes, threads, scheduling, locks, synchronization, virtual memory, file systems, IPC, system calls, I/O
    • algorithms, data structures, complexity analysis
    • networking: computers के बीच communication, reliability, throughput, latency, layered structure
    • databases और data systems: ACID, transactions, isolation levels, indexes, storage methods, relations, data modeling
    • software design और architecture: modularity, dependencies और responsibilities का management, information hiding, encapsulation, layers, client-server, events, coupling और cohesion
    • state और data flow: identity, single source of truth, conflict resolution, cache और memoization, state invalidation, state machines, consistency और synchronization
    • distributed systems: CAP theorem, replication, latency, partitions, consensus, service discovery, eventual consistency
    • concurrency और parallelism: locks, synchronization, parallelization potential, race conditions, deadlocks
  • हर क्षेत्र में mastery पाना न ज़रूरी है और न हमेशा संभव, लेकिन लक्ष्य यह होना चाहिए कि हर क्षेत्र की थोड़ी समझ हो और चुने हुए कुछ क्षेत्रों में उत्कृष्टता हासिल की जाए
  • मूल सिद्धांतों पर focus करने से समय के साथ universal intuition जैसी meta-skill विकसित होती है
  • computing और computers अकेले तथा clusters में कैसे काम करते हैं, इसे गहराई से समझ लेने पर लगातार बदलते tools और frameworks की बारीकियों से कम प्रभावित होना पड़ता है
  • इस स्तर पर पहुँचने के बाद, नए trending tools को सीखना भी बहुत आसान हो जाता है

समझ की खुशी और प्रभाव

  • Leonardo da Vinci के शब्दों में, “सबसे महान आनंद समझ की खुशी है”
  • software development में समझ सिर्फ आनंद नहीं देती, बल्कि व्यावहारिक प्रभाव और शक्ति भी देती है
  • software engineering का दायरा बहुत बड़ा है, लेकिन मूल सिद्धांतों पर ध्यान देने से वह क्षेत्र बढ़ता जाता है जिसे आप संभाल सकते हैं
  • अपनी वर्तमान cognitive limits को लगातार आगे धकेलने का रवैया नियमित खुशी और बढ़ते प्रभाव की ओर ले जाता है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की राय

  • मुझे इस ब्लॉग पोस्ट का समग्र भाव सच में बहुत पसंद आया।
    आजकल हर जगह “अंदर क्या हो रहा है यह जाने बिना भी मैंने एक टूल बना लिया” जैसी पोस्टें बहुत ज़्यादा दिखती हैं, और उसे किसी उपलब्धि की तरह पेश करने वाले माहौल से मैं थक गया हूँ।

    • सही बात। गहरी समझ ही असली बढ़त बनाती है और नए ideas व insights तक ले जाती है।
      और यह भी बड़ी बात है कि वह पूरी प्रक्रिया अपने-आप में बहुत आनंददायक होती है।

  • यह दिलचस्प लेख था, और मुझे लगता है कि लोगों को बिना समझे हुए नतीजे निकालने की ओर धकेलने वाली यह प्रवृत्ति कुछ हद तक जानबूझकर है।
    AI labs के नज़रिए से इसके साफ़ आर्थिक कारण भी हैं। लोगों को उनके products पर निर्भर रहना होगा, तभी वे अपनी valuation को जायज़ ठहराना शुरू कर सकते हैं, और users की क्षमता को कमज़ोर करना भी उसी का एक तरीका है।
    संयोग से मैंने आज इसी तरह का एक लेख लिखा, जो किसी चीज़ को सच में सीखने और उसमें mastery हासिल करने की खुशी वाले उसी मूल विचार को साझा करता है: https://hgrsd.nl/blog/simplicity-agency-and-mastery/

    • लेख साझा करने के लिए धन्यवाद। स्वायत्तता और snowball effect पर आपका point मुझे खास तौर पर अच्छा लगा।
      अपनी स्वायत्तता कभी नहीं छोड़नी चाहिए, और जितना ज़्यादा आप जानते और कर सकते हैं, उतना ही ज़्यादा आगे जानने और करने में सक्षम हो जाते हैं। यह सच में एक सुंदर और सकारात्मक feedback loop है।

  • अच्छा लगा कि इस पोस्ट पर डरावना vibecoding टैग नहीं लगा था। सच कहूँ तो इस तरह की बातें दशकों से कही जाती रही हैं, बस तब वे आम तौर पर छोटी और अक्सर ज़्यादा शिकायत भरे रूप में होती थीं।
    software भयावह रूप से जटिल है, इसलिए cognitive shortcuts बहुत हैं, और किसी मोड़ पर वे जीवित रहने के लिए ज़रूरी भी हो सकते हैं। लेकिन इंसानों में सावधान होने की ज़रूरत वाले समय पर भी और आलसी हो जाने की प्रवृत्ति रहती है। computers सख्त modularization के साथ अच्छी तरह फिट बैठते हैं, इंसान नहीं।
    अच्छा लगा कि इस लेख ने समझ को केवल एक “कर्तव्य” नहीं माना, बल्कि इस बात पर ज़ोर दिया कि यह समझना कितना मज़ेदार है कि कोई चीज़ कैसे काम करती है। हो सकता है कुछ लोग दुनिया को समझने में आनंद न लेते हों, लेकिन मेरे स्वभाव का यह इतना मूल हिस्सा है कि उसका अभाव लगभग सिर्फ़ सैद्धांतिक-सा लगता है। अगर यह आनंद नहीं है, तो software career शुरू करने से पहले दोबारा सोचना चाहिए।

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

  • मुझे सीखना सच में बहुत पसंद है, और लेख में जिस स्थिति की बात है — “किसी ऐसी चीज़ को पैदा करना जिसे केवल आंशिक रूप से समझा गया हो, और फिर उसे समझने के लिए और समय लगाना पड़े” — उसमें मुझे व्यक्तिगत रूप से ऐसा cognitive debt बुरा नहीं लगता।
    अगर वह कोई ऐसा problem domain है जिसमें मेरी रुचि है, तो मैं उस कर्ज़ को चुकाने और समझ हासिल करने के लिए समय देने को तैयार हूँ। अंततः यह उसी समझ तक पहुँचने का बस एक अलग रास्ता लगता है।
    इससे lean startup का विचार भी याद आता है। अगर आपके सामने देखने लायक कुछ हो, तो खाली स्क्रीन पर क्या महत्वपूर्ण है यह अनुमान लगाने के बजाय, आप किसी ठोस चीज़ को खोलकर देखना शुरू कर सकते हैं। कहाँ से शुरू करें यह न जानना ज़्यादा बुरा है, और AI तेज़ी से शुरुआत कराने में मदद कर सकता है।
    जो बात अभी भी मेरे लिए पूरी तरह साफ़ नहीं है, वह यह है कि कम अनुभव वाले juniors बुरी गंध कैसे पहचानें और उसका विरोध करने वाली intuition कैसे विकसित करें। AI का मेरा उपयोग बहुत iterative है, और मैं उसे सुधार के लिए Socratic dialogue की तरह बरतता हूँ। यह मौजूदा tools से संभव one-shot vibecoding वाली दुनिया से काफ़ी अलग है।

    • “कम अनुभव वाले juniors बुरी गंध कैसे पहचानें और उसका विरोध करने वाली intuition कैसे विकसित करें” वाली बात पर, मेरे कुछ करीबी दोस्त और परिवार के लोग पिछले साल के आखिर में ही इस industry में आए हैं।
      व्यावहारिक रूप से देखें तो मुझे नहीं लगता कि यह पहले से बहुत अलग है। ज़्यादा senior लोग सलाह देंगे और आपत्ति भी उठाएँगे, और ज़्यादातर tech companies में peer review भी होता है। इसलिए juniors पूरी तरह अकेले नहीं होते। बल्कि उनके पास गलती करने और ढलने का काफ़ी समय होता है।

  • अच्छा लगा कि इसमें कई बुनियादी विषयों को काफ़ी विस्तार से गिनाया गया।
    पाठक इसे Gish gallop या parading of horribles जैसी rhetorical techniques की तरह समझने के लिए प्रेरित हो सकता है, लेकिन वास्तव में मुझे लगता है कि हमारी ज़िंदगी के हर क्षण में दर्जनों बुनियादी सिद्धांत एक-दूसरे से टकराते और मिलते रहते हैं।
    computers भी किसी एकीकृत सिद्धांत से program नहीं किए गए हैं; वे कई छोटे सिद्धांतों को जोड़कर बने overlapping set-inclusion diagram के ज़्यादा करीब हैं।

  • मैंने इस लेख को बहुत आनंद लेकर ध्यान से पढ़ा और कुछ दोस्तों के साथ भी साझा किया।
    जैसे-जैसे गति धीमी करना मुश्किल होता जा रहा है, मैंने नए साल में बुनियादी सीख के लिए सार्वजनिक रूप से प्रतिबद्ध होने पर यह भी लिखा: https://writing.tidefield.dev/hello-world-again/#honing-my-focus
    “2026 के बाद मैं ऐसी बुनियादी चीज़ों का अध्ययन करूँगा जो जल्दी out of fashion नहीं होंगी…” — यह दिशा समान होने से अच्छा लगा।