मुझे आकार देने वाले software essays

(refactoringenglish.com)

74 पॉइंट द्वारा GN⁺ 2025-10-02 | 3 टिप्पणियां | WhatsApp पर शेयर करें

20 साल में मैंने हज़ारों software blog posts पढ़ी हैं, लेकिन सिर्फ कुछ essays ने ही मेरी सोच को बुनियादी रूप से बदला, और यहाँ Joel Spolsky के "Joel Test" से लेकर Julia Evans के pure JavaScript के पक्ष में लिखे गए लेख तक 10 अहम essays का परिचय है
Joel Spolsky का "Joel Test" 12 सवाल रखता है जिनसे यह आंका जा सकता है कि कोई employer developers का सम्मान करता है या नहीं, और source control, daily build, bug को पहले ठीक करना जैसी चीज़ों के ज़रिए यह देखता है कि क्या developer के समय और फोकस को प्राथमिकता दी जाती है
Alexis King का "Parse, don't validate" data validation के दौरान उसे नए type में बदलने की तकनीक बताता है, और दिखाता है कि type system application की security और reliability बढ़ाने में योगदान दे सकता है
Fred Brooks का "No Silver Bullet" software काम को essential complexity और accidental complexity में बाँटता है, और तर्क देता है कि tools और hardware में प्रगति से 10x productivity improvement संभव नहीं है, हालांकि AI इस सिद्धांत में एक नया variable जोड़ता है
Julia Evans के pure JavaScript essay ने यह एहसास कराया कि framework के बिना भी सिर्फ ES2018 JavaScript ही काफ़ी है, और इसके बाद 2020 से किसी भी project में JavaScript framework या build step को शामिल नहीं किया गया

Joel Spolsky का "Joel Test" (2000)

Joel Spolsky को अब तक का सबसे बेहतरीन software blogger माना जा सकता है, और उनके essays ने लेखक के software के प्रति दृष्टिकोण को गहराई से प्रभावित किया
"Joel Test" 12 सवालों का एक सेट है, जो यह आकलन करता है कि कोई employer अपनी software team में कितना अच्छा निवेश करता है
12 सवालों की सूची
- क्या source control का इस्तेमाल होता है?
- क्या एक ही step में build किया जा सकता है?
- क्या daily build किया जाता है?
- क्या bug database मौजूद है?
- क्या नया code लिखने से पहले bugs ठीक किए जाते हैं?
- क्या up-to-date schedule मौजूद है?
- क्या spec मौजूद है?
- क्या programmers के पास शांत working environment है?
- क्या पैसे से खरीदे जा सकने वाले सबसे अच्छे tools का इस्तेमाल होता है?
- क्या testers मौजूद हैं?
- क्या नया candidate interview के दौरान code लिखता है?
- क्या hallway usability testing की जाती है?
मुख्य संदेश
- कुछ सवाल आज के हिसाब से पुराने लग सकते हैं, लेकिन सवाल खुद नहीं बल्कि उनके पीछे का meta point ज़्यादा महत्वपूर्ण है
- Joel असल में यह पूछते हैं: क्या आप developers का सम्मान करते हैं?
- हर सवाल यह परखता है कि employer सस्ते office space और short-term deadlines से ऊपर developer के समय और फोकस को रखता है या नहीं
- यह dot-com boom के चरम पर प्रकाशित हुआ था, जब skilled developers एक कीमती resource थे, लेकिन हर कोई इसे समझता नहीं था
- Joel का blog हमेशा programmers को दुर्लभ और नाज़ुक प्रतिभा की तरह पेश करता था, जिनकी employers को तलाश और कद्र करनी चाहिए
- लेखक ने अपने पूरे career में ऐसे employers खोजे जो Joel Test में ऊँचा score करते हों, और इस दिशा-निर्देश के लिए Joel के आभारी हैं

Alexis King का "Parse, don't validate" (2019)

यह Haskell के type system के उपयोग पर एक essay है, लेकिन अगर type system या Haskell में दिलचस्पी न भी हो, तब भी यह software के बारे में सोचने का तरीका बुनियादी रूप से बदल देता है
Go, C++, Rust जैसी हर statically typed language में Alexis की technique इस्तेमाल की जा सकती है
मुख्य अवधारणा
- जब भी data validate किया जाए, उसे एक नए type में बदलना चाहिए
- उदाहरण: अगर username को अधिकतम 20 alphanumeric characters तक सीमित रखने का नियम हो, तो सीधा-सादा solution होगा validateUsername(username string) error function
समस्या
- code मूल रूप से सुरक्षित नहीं रहता
- क्योंकि हर incoming username को validate करना पड़ता है, इसलिए गलती से ऐसा code path बन जाना आसान है जहाँ username validation के बिना process हो जाए
- अगर कोई malicious user ऐसी गलती पकड़ ले, तो वह username field में malicious code डाल सकता है या उसे अरबों characters से भरकर server resources खत्म कर सकता है
Alexis का solution
- parseUsername(raw string) (Username, error) function का उपयोग
- codebase के बाकी हिस्से में "username" नाम के string की जगह custom type Username का उपयोग
- Username बनाने वाला एकमात्र function parseUsername है, और यह Username instance लौटाने से पहले validation rules लागू करता है
- अगर आपके पास Username instance है, तो उसमें ज़रूर एक valid username होना चाहिए
- untrusted input हमेशा string होता है, इसलिए Username अपेक्षित करने वाले function को string pass नहीं किया जा सकता
प्रभाव
- इस essay से पहले लेखक को लगता था कि type system बस language nerds को व्यस्त रखने का एक दिलचस्प तरीका है
- "Parse, don't validate" ने यह समझाया कि compiler features application की security और reliability बढ़ाने में कितने मूल्यवान हो सकते हैं

Fred Brooks का "No Silver Bullet" (1986)

कॉलेज में Fred Brooks की The Mythical Man-Month पढ़ी गई
यह IBM के OS/360 project को lead करने के अनुभव पर आधारित software engineering essays का संग्रह है
essential complexity और accidental complexity
- essential complexity: वह काम जो tools और hardware की परवाह किए बिना करना ही पड़ेगा
  - उदाहरण: sales staff bonus calculation software में bonus formula परिभाषित करना और सभी edge cases को cover करना
  - चाहे $5B supercomputer हो या $1 microcontroller, काम वही रहेगा
- accidental complexity: बाकी सब कुछ
  - memory leaks से निपटना, code compile होने का इंतज़ार करना, third-party libraries का उपयोग समझना
  - tools और hardware resources जितने बेहतर होंगे, accidental complexity पर उतना कम समय खर्च होगा
Brooks का निष्कर्ष
- tools या hardware में प्रगति से developer productivity में 10x सुधार लाना संभव नहीं
- भले ही accidental activities को शून्य समय तक घटा दिया जाए, जब तक वे कुल effort का 9/10 से ज़्यादा हिस्सा न हों, उस पैमाने का सुधार संभव नहीं
उपयोग के उदाहरण
- पूरे career में लेखक ने लोगों को software से programmer को हटाने की कोशिश करते देखा
- no-code platforms गैर-programmers को skilled web developer जितनी ताकत देने का वादा करके चर्चा बटोरते रहे
- Brooks का essay हमेशा यह भरोसा देता रहा कि कोई भी नया buzzword platform developers की जगह नहीं ले सकता
- ये platforms accidental complexity पर ध्यान देते हैं, essential complexity पर नहीं
- अगर कोई platform feature specification से जादू की तरह काम करने वाला code बना भी दे, तब भी specification लिखने के लिए किसी न किसी की ज़रूरत रहेगी
AI का प्रभाव
- आधुनिक AI, Brooks के सिद्धांत में एक wrench फेंकता है
- AI सचमुच essential complexity को कम करता है
- अगर AI को अधूरी या विरोधाभासी specifications दी जाएँ, तो वह मिलती-जुलती specifications से उधार लेकर खाली जगह भर देता है
- भले ही AI ज्ञात programming को हटा दे, Brooks का essay अंततः यह उम्मीद देता है कि किसी न किसी abstraction level पर essential complexity को संभालने वाला इंसान फिर भी चाहिए होगा

Joel Spolsky का "Choices" (2000)

सिर्फ एक पसंदीदा Joel Spolsky essay चुनना मुश्किल था, इसलिए दो चुने गए
"Choices" user interface बनाने और user को power देने की सूक्ष्म लागत पर केंद्रित है
मुख्य संदेश
- हर बार जब आप कोई option देते हैं, तो आप user से एक decision माँगते हैं
- इसका मतलब है कि user को किसी चीज़ पर सोचना और फैसला करना पड़ेगा
- यह हमेशा बुरा नहीं होता, लेकिन आम तौर पर हमें लोगों को लेने वाले decisions की संख्या कम करने की कोशिश करनी चाहिए
Windows 98 उदाहरण
- Joel ने Windows 98 में help documents खोजते समय दिखने वाला एक बेहूदा dialog box साझा किया
- वह dialog box Joel को गुस्सा दिलाता था क्योंकि:
  - जब user मदद पाने की कोशिश कर रहा हो, तब वह उसे बीच में रोकता है
  - database optimization के बारे में बिना जानकारी वाला decision लेने को कहता है
  - Windows निर्णय लेने से बचकर यह बोझ user पर डाल देता है
लागू होने का दायरा
- Joel का essay graphic user interface पर केंद्रित है, लेकिन लेखक इसे हर उस जगह लागू मानते हैं जहाँ कोई code के संपर्क में आता है, जिसमें command line या लेखक द्वारा लिखे गए functions को call करने वाले दूसरे developers भी शामिल हैं
- क्या आप user की ओर से उपयोगी decisions ले सकते हैं, और साथ ही उन्हें उन चीज़ों पर control दे सकते हैं जिनकी उन्हें परवाह है
- Joel के essays ने ऐसे countless मौकों पर user पर वह निर्णय थोपने से रोका है जो मैं खुद ले सकता था

Raymond Chen का "“Application compatibility layers are there for the customer, not for the program” (2010)

Raymond Chen Microsoft Windows टीम के सबसे लंबे समय तक काम करने वाले डेवलपर्स में से एक हैं
उनके ब्लॉग में Windows programming के इतिहास पर हज़ारों उपयोगी और मज़ेदार कहानियाँ हैं
ग्राहक अनुरोध का मामला
- Windows Vista compatibility mode से जुड़ा एक ग्राहक अनुरोध:
  - Windows XP और Windows Server 2003 के लिए डिज़ाइन किया गया प्रोग्राम Windows Vista में दिक्कत झेलता है
  - Windows XP compatibility mode पर सेट करने से वह Vista में ठीक चलता है
  - सवाल यह था कि Vista पर चलाते समय installer में क्या बदलाव किए जाएँ ताकि वह अपने-आप XP compatibility mode में चले
Raymond की उपमा
- "मैं आम तौर पर pet store के सामने वाले फुटपाथ पर कचरा फेंक देता हूँ, और हर सुबह जब दुकान खुलती है तो कोई उसे बुहारकर डस्टबिन में डाल देता है। लेकिन pet store रविवार को नहीं खुलती, इसलिए रविवार को कचरा वहीं पड़ा रहता है। रविवार को भी pet store खुलवाने के लिए मुझे क्या करना चाहिए?"
सीख
- यह उपमा इतनी मज़ेदार थी कि Raymond ग़लत थे, यह मुझे बहुत बाद में समझ आया
- यह उस डेवलपर की भूल का मज़ाक उड़ाती है जिसने एक बार release होने के बाद उम्मीद की कि Windows उसके app को नहीं तोड़ेगा
- मैं विवरणों से सहमत नहीं हूँ, लेकिन Raymond की लिखाई इतनी मज़ेदार और तीखी है कि उसकी खामियाँ नज़रअंदाज़ की जा सकती हैं
- user behavior को प्रभावित करने की यह एक शानदार सीख है:
  - अगर आप चाहते हैं कि user कुछ ऐसा करे जिससे आपकी मदद हो, तो user के नज़रिए से सबसे कम resistance वाला रास्ता बहुत सोच-समझकर तय करना चाहिए
  - अगर आप दिखा देते हैं कि फुटपाथ पर कचरा फेंकने से समस्या पूरी तरह हल हो जाती है, तो लोग वही करते रहेंगे

Erik Kuefler का "Don’t Put Logic in Tests" (2014)

लेखक को हमेशा unit tests पसंद रहे हैं और उन्हें अपने test code पर बहुत गर्व था
इस essay ने जैसे बाथरूम में आकर झकझोर दिया कि मैं अपने पूरे करियर में भयानक tests लिखता रहा हूँ

समस्या वाले test का उदाहरण

@Test public void shouldNavigateToPhotosPage() {  
  String baseUrl = &quot;http://plus.google.com/&quot;;  
  Navigator nav = new Navigator(baseUrl);  
  nav.goToPhotosPage();  
  assertEquals(baseUrl + &quot;/u/0/photos&quot;, nav.getCurrentUrl());  
}

सामने आई समस्याएँ
- essay पहली बार पढ़ते ही लगा, "अरे, मैं भी unit tests बिल्कुल ऐसे ही लिखता हूँ!"
- http://plus.google.com/ string को दो जगह दोहराने की क्या ज़रूरत? production code की तरह single source of truth बना लो
- test में duplication हटाने के लिए helper functions, variables और loops जोड़ना मैं हमेशा करता था
- समस्या यह है कि यह तरीका subtle bug छिपा देता है: असल में assert http://plus.google.com//u/0/photos पर हो रहा है, यानी दो slash
समझ
- Erik का essay दिखाता है कि test code को production code जैसा नहीं मानना चाहिए
- दोनों के लक्ष्य और constraints पूरी तरह अलग हैं
- अच्छा test code सबसे पहले स्पष्ट होना चाहिए
- test code का अपना अलग test code नहीं होता, इसलिए उसकी correctness जाँचने का एकमात्र तरीका inspection है
- test इतना बिलकुल साफ़ होना चाहिए कि पाठक तुरंत समझ जाए कि वह किस behavior को assert कर रहा है
- इस लक्ष्य के लिए complexity घटाने हेतु duplication स्वीकार्य है

Julia Evans की “A little bit of plain Javascript can do a lot” (2020)

एक software engineer के रूप में मैंने वेब की दुनिया में शर्मनाक रूप से बहुत देर से प्रवेश किया
करियर के पहले 10 साल मैंने सिर्फ desktop apps और backend servers के लिए code लिखा
2017 तक मुझे HTML या JavaScript की कोई खास परवाह नहीं थी
framework को लेकर ग़लतफ़हमी
- जब मैंने frontend development सीखना गंभीरता से शुरू किया, तब मेरी धारणा थी कि JavaScript 10 दिनों में बनी एक बेतरतीब भाषा है और हर browser में उसका व्यवहार बहुत अलग होता है
- web app लिखने के लिए कुछ modern और polished चाहिए जो JavaScript की सारी गड़बड़ियों और कमियों से बचाए
- मैंने Angular, React, Vue जैसे लोकप्रिय web frameworks आज़माए
- Vue को काफ़ी सीखा, फिर भी dependency issues और framework traps पर बहुत समय बर्बाद किया
- JavaScript को ठीक करने के लिए frontend frameworks ने जो कुछ भी किया, उसके बाद भी web programming अब भी खराब ही लगती थी
Julia के essay से मिली समझ
- मुझे एहसास हुआ कि मैं इस बात को लेकर इतना आश्वस्त था कि JavaScript को ठीक करने की ज़रूरत है, कि मैंने उसे कभी सही मौका ही नहीं दिया
- मैं TinyPilot के prototype पर काम कर रहा था और web interface को Vue में बनाने वाला था
- Julia के essay ने मुझे यह देखने की प्रेरणा दी कि सिर्फ plain JavaScript से कितना आगे जाया जा सकता है
- framework, wrapper libraries, build step, या Node.js के बिना, सिर्फ साधारण JavaScript (ES2018) का इस्तेमाल किया
- मुझे लगातार लगता रहा कि कभी न कभी ऐसी समस्या आएगी जहाँ framework या builder पर जाना पड़ेगा, लेकिन ऐसा कभी हुआ ही नहीं
- WebComponents से जुड़ी कुछ परेशानियाँ थीं, लेकिन Vue और Angular के साथ झेले गए दर्द की तुलना में वे कुछ भी नहीं थीं
framework के बिना आज़ादी
- framework से मुक्त होना मुझे बहुत पसंद आया
- जब runtime error आता है, तो stack trace minified, transformed और tree-shaken code के किसी बुरे सपने जैसा नहीं होता
- मैं अपने code को उसी रूप में debug कर रहा होता हूँ जैसा मैंने लिखा था
- JavaScript को लेकर मेरा पूर्वाग्रह ग़लत निकला
- modern JavaScript काफ़ी अच्छा है, और उसने wrapper libraries के कई ideas अपने अंदर समेट लिए हैं, इसलिए अब wrappers की ज़रूरत नहीं रहती
- browsers ने भी समझदारी दिखाई है ताकि platforms और devices के बीच consistent behavior सुनिश्चित किया जा सके
- 2020 के बाद मैंने किसी भी नए project में JavaScript framework या build step शामिल नहीं किया, और कभी पीछे मुड़कर नहीं देखा
- plain JavaScript से framework के 90% फायदे सिर्फ 5% सिरदर्द के साथ मिल जाते हैं

Dan McKinley का “Choose Boring Technology” (2015)

यह इस सूची में एक अजीब essay है, क्योंकि मैंने इसे वास्तव में कभी पढ़ा ही नहीं है
लोगों को इसे quote करते सुना, और idea समझने के बाद वह इतना सहज लगा कि पढ़ने की ज़रूरत ही महसूस नहीं हुई
मुख्य विचार
- नया project शुरू करते समय बहुत चर्चा में चल रही cutting-edge technology इस्तेमाल करने का लालच होता है
- Google ने ऐसा नया database घोषित किया है जो exabyte scale तक जा सकता है, Postgres से 40% तेज़ है, और लागत सिर्फ 20% है
- जब इतना sexy नया विकल्प सामने हो, तब Postgres इस्तेमाल करना मूर्खता लगती है
- लेकिन असल में नई technology में bugs और कमजोरियाँ होती हैं, बस वे अभी तक साफ़ नज़र नहीं आई होतीं
- और जब आप उनसे टकराते हैं, तो आप बुरी तरह फँस जाते हैं
- Postgres में समस्याएँ हैं, लेकिन 30 साल के field experience के बाद लगभग हर संभव समस्या के लिए परखी हुई solutions मौजूद हैं
innovation token की अवधारणा
- Dan मानते हैं कि कभी-कभी नई technology अपनानी चाहिए, लेकिन रणनीतिक तरीके से और सीमित मात्रा में
- हर business को खर्च करने के लिए तीन "innovation tokens" मिलते हैं
- अगर आपको चमकदार नया database चाहिए, तो आपको उन tokens में से एक खर्च करना होगा
- Dan का essay, Julia के essay के साथ बहुत स्वाभाविक रूप से मेल खाता है
- काश frontend frameworks पर इतना समय बर्बाद करने से पहले मैंने इनमें से कोई एक भी पढ़ लिया होता

Terence Eden का “I’ve locked myself out of my digital life” (2022)

Terence Eden एक आनंददायक और eclectic तकनीकी ब्लॉगर हैं
वह हर हफ़्ते कई नई पोस्ट लिखते हैं, लेकिन सबसे बड़ा असर डालने वाली थी “मैंने अपनी डिजिटल ज़िंदगी में खुद को लॉक कर लिया”
आपदा परिदृश्य
- यह सिमुलेट करता है कि अगर बिजली Terence के घर पर गिर जाए और उसकी सारी संपत्ति नष्ट हो जाए तो क्या होगा
- password manager में हर चीज़ के password रखे हुए हैं
- अगर सभी devices नष्ट हो जाएँ, तो password manager तक पहुँचना असंभव
- hardware passkey इसका विकल्प क्यों नहीं हो सकते: क्योंकि वे भी घर में ही थे
एहसास
- लेखक को लगता था कि वह data के मामले में काफ़ी सुरक्षित है: सब कुछ redundant drives पर स्टोर है और दो vendors के साथ तीन महाद्वीपों में offsite backups हैं
- Terence की पोस्ट ने उन कई विश्वसनीय ख़तरों के बारे में सोचने पर मजबूर किया जो सभी devices को एक साथ मिटा सकते हैं: आग, बाढ़, बिजली का surge, आपराधिक जाँच
- सारा data दिमाग़ में मौजूद passwords से encrypted है, इसलिए स्मृतिलोप, अक्षम हो जाना, या मृत्यु भी इस सूची में जुड़ते हैं
online services की समस्या
- online services इस मामले में कमज़ोर हैं कि वे उपयोगकर्ताओं को आपदा से उबरने में मदद करें
- कई ऐसी services इस्तेमाल करता हूँ जो यह मानकर चलती हैं कि फ़ोन खोना असंभव है, ईमेल account और अपने सभी digital devices की बात तो छोड़ ही दें
प्रभाव
- Terence का essay पढ़ने के बाद मैं इस पर ज़्यादा सोचने लगा कि कौन-सी services और devices महत्वपूर्ण हैं, और Terence द्वारा बताए गए परिदृश्य में उनसे कैसे उबरा जा सकता है
- जब मैंने अगला laptop खरीदा, तो उसे library में सेट up किया ताकि यह जाँच सकूँ कि क्या घर पर मौजूद devices के बिना password manager और महत्वपूर्ण accounts तक access वापस पाया जा सकता है
- मैं अब भी digital disaster preparedness में बेहतर कर सकता हूँ, लेकिन Terence की पोस्ट हर बार दिमाग़ में गूँजती है जब मैं devices और data को सुरक्षित रखने के तरीक़ों के बारे में सोचता हूँ
- अगर सब कुछ अचानक नष्ट हो जाए तो क्या होगा?

बोनस: Brad Fitzpatrick का “parsing user input” (2009)

तकनीकी रूप से यह essay नहीं है, लेकिन software interviews से एक उद्धरण मेरे दिमाग़ में बार-बार आता है
2009 में Joel Spolsky की शानदार review के बाद Coders at Work पढ़ी
सफल programmers के interviews का संकलन
Brad Fitzpatrick का उद्धरण
- LiveJournal और Memcached के संस्थापक Brad Fitzpatrick interviewees में से एक हैं
- उस समय 28 साल के थे; किताब के सबसे युवा programmer, और सबसे ज़्यादा गाली देने वाले व सबसे मज़ेदार व्यक्ति
- software engineering ethics पर सवाल के जवाब में input validation पर जोशीला बयान:
  - “मैं चाहता हूँ कि हर कोई कम-से-कम credit card form में लोगों को spaces या hyphens डालने की सुविधा लगातार दे। Computers ऐसी चीज़ों को हटाने में बहुत अच्छे होते हैं. मुझे मत बताइए कि मैं अपने numbers को कैसे format करूँ।”
उपयोग
- जब भी मैं किसी web form में phone number paste करने की कोशिश करता हूँ, मुझे यह उद्धरण याद आता है
- मैं बड़बड़ाता हूँ कि parentheses या spaces की अनुमति नहीं है, या इससे भी बुरा, सिस्टम parentheses की वजह से phone number काट देता है और फिर शिकायत करता है कि parentheses allowed नहीं हैं
- जब भी मैं software में input fields बनाता हूँ और अनपेक्षित characters के बारे में सोचता हूँ, मुझे Brad Fitzpatrick कहते सुनाई देते हैं: “Computers ऐसी चीज़ों को हटाने में बहुत अच्छे होते हैं.”

3 टिप्पणियां

shakespeares 2025-10-07

इतिहास है, इसलिए आज है।

GN⁺ 2025-10-02

Hacker News राय

"I've locked myself out of my digital life" शीर्षक वाला लेख पढ़ने के बाद लगा कि उसने उस चिंता को बहुत अच्छी तरह व्यक्त किया है, जो मेरे भीतर थी लेकिन जिसे समझाना मुश्किल था
एनालॉग दुनिया में मैं किसी इंसान को यह समझाकर कि मैं कौन हूँ, अपनी पहचान सत्यापित करवा सकता हूँ और अपने अकाउंट तक पहुँच सकता हूँ, लेकिन डिजिटल दुनिया के निर्दयी algorithm के सामने अगर आपके पास credentials नहीं हैं, तो आप कितना भी विनती करें, कोई फ़ायदा नहीं
क्योंकि मेरी password manager service देने वाली कंपनी के पास भी मेरे password तक पहुँचने का अधिकार नहीं है
मनाने के लिए वहाँ कोई इंसान है ही नहीं, और सिर्फ code ही कानून बन जाता है
मुझे लगता है कि हर process से आमने-सामने की प्रक्रिया हटाने की वकालत करने से पहले, सबको इस समस्या को समझना चाहिए
लेख में यह दुर्लभ स्थिति जैसी लग सकती है, लेकिन प्राकृतिक आपदा या चोरी जैसी परिस्थितियों में यह आसानी से हो सकता है
संबंधित लेख: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/
- मुझे नहीं लगता कि ऐसी चरम automation या आमने-सामने की प्रक्रिया कम करने का समर्थन करने वाले लोग वास्तव में बहुत हैं
  और यह सिर्फ AI की समस्या नहीं है, rule-based software में भी यही बात लागू होती है
  यूरोपीय संघ (EU) में कानून यह सुनिश्चित करता है कि किसी भी निर्णय के खिलाफ इंसान के सामने अपील करने का अधिकार बना रहे
Grug Brained Developer ऐसा लेख है जो हमेशा दिमाग में रहता है, लेकिन सूची में नहीं था
शायद इसलिए कि उसमें कही गई बातों से मैं पहले से सहमत था, इसलिए उसने सोच में बदलाव नहीं किया बल्कि बस याद रह गया
संदर्भ: https://grugbrain.dev/
- इनमें से 복잡성 악마를 마침내 수정된 크리스탈에 가두는 것이 최고의 기분 वाला हिस्सा मुझे सच में बहुत पसंद आया
- मैं अंग्रेज़ी को दूसरी भाषा के रूप में इस्तेमाल करने वाला bilingual व्यक्ति हूँ, इसलिए grug brain शैली में लिखी चीज़ें पढ़ना और समझना मेरे लिए काफ़ी कठिन है
  मुझे यह भी नहीं पता कि grug शब्द का मतलब क्या है
  फिर भी मुझे वह ब्लॉग पढ़ना मज़ेदार लगता है
मैं Fred Brooks के "No Silver Bullet" पर निकाले गए निष्कर्ष से सहमत नहीं हूँ
मैं इस दावे से सहमत नहीं हूँ कि हाल का AI Brooks के सिद्धांत को तोड़ देने लायक हद तक essential complexity घटा चुका है
AI अधूरी या परस्पर-विरोधी specifications को मिलते-जुलते उदाहरणों के आधार पर अपने-आप भर सकता है, लेकिन essential complexity अभी भी AI से पर्याप्त रूप से हल नहीं होती, और मुझे लगता है कि आगे भी नहीं होगी
इस पर मेरा विस्तृत विश्लेषण यहाँ है: https://smartmic.bearblog.dev/no-ai-silver-bullet/
- पढ़ने और मेरा लेख साझा करने के लिए धन्यवाद
  जैसा तुमने अपनी व्याख्या में कहा, मैं भी सहमत हूँ कि LLM essential complexity को पूरी तरह खत्म नहीं कर सकता
  लेकिन मुझे लगता है कि LLM essential complexity को कुछ हद तक कम कर सकता है
  एक वास्तविक उदाहरण के तौर पर, मैंने Claude 4.1 Opus से computer-generated चित्रों के लिए एक domain-specific language की परिभाषा माँगी थी
  मैंने सिर्फ requirements दीं और कई details जान-बूझकर अस्पष्ट छोड़ीं, फिर भी LLM ने spec लिखकर दे दी
  ऐसे मामले में मुझे यक़ीन है कि LLM ने essential complexity को कम किया
  मैं खुद भी इसे नए सिरे से high quality में परिभाषित कर सकता था, लेकिन अगर LLM का निकला हुआ परिणाम पर्याप्त है, तो गुणवत्ता सुधारने के लिए अतिरिक्त मेहनत लगाने की वजह कम हो जाती है
  पहले मुझे लगता था कि coding मैं खुद बेहतर करता हूँ और मुझे इसमें ज़्यादा मज़ा भी आता है, इसलिए LLM की खास ज़रूरत नहीं है, लेकिन इस्तेमाल करने के बाद लगा कि जिन हिस्सों में मुझे अपना समय और ऊर्जा नहीं लगानी पड़ती, वहाँ LLM essential complexity का बड़ा हिस्सा अपने ऊपर ले लेता है
  उदाहरण: https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1
- AI जो complexity कम करता है, वह आखिरकार code लिखने वाले की cognitive burden ही है
  Brooks ने जिस nonessential complexity की बात की थी, वह code में लगभग वैसी की वैसी बनी रहती है
  नतीजतन वह बोझ code पढ़ने वाले पर डाल दिया जाता है
  यह कुछ वैसा है जैसे exoskeleton suit पहनकर कोई भारी सामान शेल्फ पर रख दे और फिर अपने सहकर्मी से कहे कि अब इसे अच्छे से रंग दो
"Parse, don't validate" निबंध मेरी नज़र में एक क्लासिक masterpiece है
और "Don't put logic in tests" वाक्य से सहमत होना मुझे मुश्किल लगा
उदाहरण में समस्या इस बात से आई थी कि string की जगह URI type का उपयोग होना चाहिए था, और मेरा मानना है कि क्योंकि test code भी deployment की सफलता या विफलता को प्रभावित करता है, इसलिए test code को भी production code माना जाना चाहिए
फिर भी, ऐसी चर्चाओं को खुद देखकर यह सोचना पूरी तरह सार्थक है कि क्या वे आपके लिए लागू होती हैं
- मुझे भी हैरानी है कि "Parse, don't validate" उतना जाना-पहचाना नहीं है
  शायद इसलिए कि मेरे आसपास ज़्यादातर लोग Go, Python, C++ करते हैं, और लगता है कि यह functional language वाली दुनिया में ही ज़्यादा मशहूर है
  "Don't put logic in tests" के उदाहरण पर की गई आलोचना मुझे उचित लगती है
  उदाहरण को थोड़ा बेहतर बनाया जा सकता है, लेकिन असली बात यह है कि साधारण string concatenation भी tests में complexity बढ़ा सकती है और bugs छूट सकते हैं
- व्यक्तिगत रूप से मुझे tests में (बहुत ज़्यादा) logic न डालने की philosophy आकर्षक लगती है
  test code के bugs की वजह से false positive कई बार देखने के बाद इस मामले में मेरे भीतर अविश्वास पैदा हो गया है
  मुझे नहीं लगता कि tests के लिए tests लिखने की ज़रूरत महसूस होनी चाहिए
  असल में ऐसे मामले दुर्लभ हैं, लेकिन हाल में LLM द्वारा लिखे गए घटिया test code का चलन बढ़ने से यह समस्या इस philosophy से अलग भी बड़ी होती जा रही है
मैं Nancy Leveson की Therac-25 दुर्घटनाओं पर जाँच और समीक्षा सामग्री की सिफारिश करता हूँ
- An Investigation of the Therac-25 Accidents: https://cse.msu.edu/~cse470/Public/Handouts/Therac/Therac_1.html
- The Therac-25: 30 Years Later: https://ieeexplore.ieee.org/document/8102762
  Charles Fishman की They Write the Right Stuff भी ज़बरदस्त सिफारिश है
  https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20Write%20the%20Right%20Stuff.pdf
इस क्षेत्र में मेरा सबसे पसंदीदा लेख Neil W. Rickert का "The Parable of the Two Programmers" है
यह प्रोग्रामर की ज़िंदगी और चुनौतियों का बहुत संक्षिप्त लेकिन सटीक सार है
https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html
- मैं Neil को अच्छी तरह जानता हूँ; कई सालों तक comp.ai.philosophy Usenet newsgroup में उनसे अक्सर बातचीत होती रही
  लेख का लहजा और उसकी सामग्री सच में बिल्कुल उसी की शैली जैसी है
- यह लेख सच में शानदार है
मेरे लिए यह लेख turning point था
https://stevemcconnell.com/articles/software-quality-at-top-speed/

McConnell यहाँ बहुत ज़्यादा प्रसिद्ध नहीं हैं
- साझा करने के लिए धन्यवाद!
  यह मैं पहली बार पढ़ रहा हूँ, लेकिन अपने करियर की शुरुआत में मैंने Code Complete पढ़ी थी और उससे बहुत प्रभावित हुआ था
  वह किताब मेरी शेल्फ पर हमेशा रही, और जब भी उसे दोबारा थोड़ा-बहुत पढ़ा, यही लगा कि यह वाकई शानदार है, इसे फिर ठीक से पढ़ना चाहिए
  काफ़ी समय से McConnell के बारे में कुछ सुना नहीं था, इसलिए मुझे हैरानी होती थी कि Kent Beck, Martin Fowler, Ward Cunningham जैसे उनके समकालीन लेखक 2000 के बाद कम लोकप्रिय होने के बावजूद लिखते रहे, लेकिन McConnell चुप क्यों हो गए
  बाद में पता चला कि उन्होंने software छोड़ दिया और financial advisor बन गए, और यह बात चुपचाप काफ़ी चौंकाने वाली लगी
  https://raindogllc.com/steve-mcconnell-investment-advisor/
यह सख्ती से कहें तो पारंपरिक software essay नहीं है, लेकिन Gilad Bracha की "Ban on Imports" ब्लॉग पोस्ट ने module system को लेकर मेरा नज़रिया पूरी तरह बदल दिया
उसमें ज़ोर देकर कहा गया है कि import/export दरअसल global state जैसा ही है, और इसलिए वह global state की सारी समस्याएँ साथ ले आता है
उसके बाद से मैं dependency injection की अवधारणा को बहुत अधिक महत्व देने लगा
https://gbracha.blogspot.com/2009/06/ban-on-imports.html
हो सकता है इसे सख्ती से software essay कहना मुश्किल हो, लेकिन Patrick McKenzie का "Don't Call Yourself A Programmer, And Other Career Advice" एक असली खज़ाना है
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/
मैं programming languages में गहरी रुचि रखने वाला व्यक्ति हूँ, और "slumming with basic programmers" शीर्षक वाला लेख मेरे दिमाग में बहुत देर तक रहा
https://prog21.dadgum.com/21.html

secret3056 2025-10-02

यूज़र input parsing वाली बात से मैं सच में सहमत हूँ।
आख़िर वैकल्पिक फ़ोन नंबर input फीचर बनाने वाले इतने सारे coders किस माहौल में काम करते हैं कि वे string पर replace() को दो बार call करने से इतना डरते हैं?

मुझे आकार देने वाले software essays

Joel Spolsky का "Joel Test" (2000)

12 सवालों की सूची

मुख्य संदेश

Alexis King का "Parse, don't validate" (2019)

मुख्य अवधारणा

समस्या

Alexis का solution

प्रभाव

Fred Brooks का "No Silver Bullet" (1986)

essential complexity और accidental complexity

Brooks का निष्कर्ष

उपयोग के उदाहरण

AI का प्रभाव

Joel Spolsky का "Choices" (2000)

मुख्य संदेश

Windows 98 उदाहरण

लागू होने का दायरा

Raymond Chen का "“Application compatibility layers are there for the customer, not for the program” (2010)

ग्राहक अनुरोध का मामला

Raymond की उपमा

सीख

Erik Kuefler का "Don’t Put Logic in Tests" (2014)

समस्या वाले test का उदाहरण

सामने आई समस्याएँ

समझ

Julia Evans की “A little bit of plain Javascript can do a lot” (2020)

framework को लेकर ग़लतफ़हमी

Julia के essay से मिली समझ

framework के बिना आज़ादी

Dan McKinley का “Choose Boring Technology” (2015)

मुख्य विचार

innovation token की अवधारणा

Terence Eden का “I’ve locked myself out of my digital life” (2022)

आपदा परिदृश्य

एहसास

online services की समस्या

प्रभाव

बोनस: Brad Fitzpatrick का “parsing user input” (2009)

Brad Fitzpatrick का उद्धरण

उपयोग

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

3 टिप्पणियां

Hacker News राय