“खराब कोड” को लेकर मेरे कुछ अनुभव हैं। अक्सर अकेले काम किया, लेकिन टीम में भी ऐसा कोड लिखा है जो बस चलता था, पर optimal नहीं था। जब नए काम के साथ पुराने कोड को refactor करने की कोशिश करता, तो अक्सर मना कर दिया जाता था; और ज़रूरी refactoring या fixes को ticket के रूप में छोड़ भी दूँ, तो आम तौर पर उनकी priority नीचे चली जाती या उन्हें ignore कर दिया जाता था
अकेले हों तो ज़रूरी कामों को priority दे सकते हैं, लेकिन टीम में second-best decisions हमेशा के लिए रह जाते हैं या “system down” वाले पल तक छोड़ दिए जाते हैं। उसके बाद postmortem में, जब मैं महीनों पहले से उस time bomb को ठीक करने की मांग वाले ticket की ओर इशारा करता, तो उसे “blame” या “aggressive” माना जाता था। अंत में समाधान जैसे यह बन गया कि suboptimal code कभी लिखना ही नहीं है, जिससे coding करते समय frustration और anxiety बढ़ गई
2017 में मुझे 2003/2004 में लिखे code को ठीक करने के लिए भी contact किया गया, और वह code अब भी production में चल रहा था। टूटे हुए code और किए गए compromises को दोबारा देखते हुए यह समझना कि ज़िम्मेदार व्यक्ति मैं ही था, काफी विनम्र बना देने वाला अनुभव है; उसके बाद maintainable code और documentation को लेकर मेरा नज़रिया बहुत बदल गया
यह टीम और company पर निर्भर करता है। मैंने कई ऐसी teams देखी हैं जहाँ developers को code maintenance और refactoring पर समय लगाने के लिए encourage किया जाता था, कभी-कभी तो उन्हें केवल वही करने के लिए मजबूर किया जाता था; random product requirements से ज़्यादा engineering-focused work को priority मिलती थी, और काम properly पूरा करने के लिए schedules भी adjust किए जाते थे
S&P 500 की बड़ी companies, 100 million से 1 billion dollar आकार की companies, और startups तक में ऐसे experience आम थे। ऐसे मामलों में skilled software engineers और managers होते थे जो reasonable trade-offs कर सकते थे और business needs का भी ध्यान रखते थे, और engineers अक्सर customers से सीधे interact भी करते थे
असली बात balance है, और वह balance आम तौर पर उन लोगों से आता है जो संतुलित judgement कर सकते हैं। अगर सिर्फ “perfection” का पीछा करें तो endless refactoring और release न हो पाने की स्थिति आती है; और अगर technical debt या खराब quality को ignore करें, तो समय के साथ business ढह सकता है। आप कहाँ खड़े होंगे, यह product, industry, customers और business पर निर्भर करता है
या तो hero बनकर मर जाओ, या इतना लंबा जियो कि 10 साल पुराने git blame में अपना नाम देख लो
“चलता है लेकिन optimal नहीं है” अक्सर acceptable trade-off होता है, जब समय कम हो और करने को बहुत काम हो। “Perfect is the enemy of good” जैसे MBA-style slogans भी तब काम आ जाते हैं जब कुछ missing हो
2017 में 2003/2004 में लिखे code को ठीक करने के लिए बुलाया जाना यह भी मतलब रखता है कि हम सब time travelers हैं। अपने past self के लिए उदार, और future self के लिए थोड़ा rude
मेरा past self युवा और naive था, लेकिन productive था, और उसने कई पहाड़ पार किए थे। Code समझने में दो दिन लगे, लेकिन अंत में वह काफी clever निकला; और शायद current self ने सब कुछ इसलिए भुला दिया क्योंकि memory खराब है
मेरा future self सारी गलतियाँ ठीक कर देगा। वह ज्यादा उम्रदराज़ और समझदार होगा, XXX और TBD को smart code में बदलेगा, अच्छे ideas implement करेगा और औसत ideas को फिर से implement करने के लिए उसके पास अनंत समय होगा—ऐसा मैं मानता हूँ। बेहतर comments हों तो शायद ये तीनों एक हो जाएँ
मुझे यह righteous “वही एक इंसान” वाला attitude नुकसानदेह लगता है। Senior developer का अपनी की हुई गलतियों और mess-ups के बारे में बोल पाना बहुत liberating और healthy है
यह सिर्फ learning opportunity नहीं है, बल्कि open culture दिखाता है और imposter syndrome से भी मुकाबला करता है। Perfectionist attitude इसके उलट बस “और मेहनत करो ताकि गलती न हो” कहता है; उससे सीखने को कुछ नहीं मिलता और बस individual effort की और मांग होती है
कम से कम दो बार, मेरे हिसाब से “वही एक इंसान” ने अपनी बड़ी गलती स्वीकार नहीं की, अच्छे customer को खोने की नौबत तक आने दी लेकिन avoid करता रहा, और शायद पीछे से बुराई भी की
एक बार junior ने report में गलत software version डालने की छोटी गलती की, जिसकी जिम्मेदारी मैंने ले ली। Customer को बस यह कहना था कि “एक गलती हुई थी और corrected report यहाँ है”, लेकिन boss बस यह सोच रहा था कि “क्या हम इसे छिपाकर यह face बनाए रख सकते हैं कि हम perfect हैं?” वही व्यक्ति दूसरों की गलतियों को discount, compensation या free delivery मांगने के मौके की तरह इस्तेमाल करता था
मुझे लगता है ज्यादातर लोग अपना काम करते हुए बेहतर हो रहे हैं। हमारी configuration management में मेरे लिखे हुए कई चीज़ें हैं जो functionally ठीक काम करती हैं, लेकिन tool को 1–2 साल इस्तेमाल करने के बाद कई वजहों से मैं उनकी quality को काफी खराब कहने लगा हूँ
फिर भी ठीक है। जब बदलने की वजह बनेगी तो उन्हें साफ कर देंगे, और तब तक वे bad practices और बेहतर approaches दिखाने वाले examples बने रहेंगे
अगर आपको अपने अंदर आलोचना करने लायक कुछ नहीं मिलता, तो इसका मतलब है आप improve नहीं कर रहे। ऐसी self-criticism share करने से दूसरे लोग भी मेरी गलतियों से सीखते हैं, और यह समझते हैं कि अपनी गलतियों से सीखना भी ठीक है
Code review में “आप बस वह गलती क्यों नहीं करते?” या “बस ऐसा क्यों नहीं करते?” जैसी बातें अक्सर सुनता हूँ
आजकल मैं जवाब देता हूँ, “शायद आपका IQ मुझसे ज्यादा है। मेरा IQ कम है, इसलिए मुझे ज्यादा dumb और simple काम करने चाहिए।” तब कभी-कभी सामने वाले को एहसास होता है कि वह बिना self-reflection के कितना dismissive छोटा weirdo जैसा behave कर रहा था, और उसका चेहरा लाल हो जाता है
“Why don't you just …?” से शुरू होने वाले सवालों से मुझे थोड़ी allergy है। वे तीन words सुनते ही आम तौर पर आगे आने वाला suggestion समझ आ जाता है—इसलिए नहीं कि वह बहुत complex होता है, बल्कि इसलिए कि वह अक्सर सबसे पहले दिमाग में आने वाला obvious तरीका होता है और पहले ही carefully consider या try किया जा चुका होता है
सवाल अपने आप में खराब नहीं है, लेकिन इसमें छिपी धारणा—“मेरा idea बहुत easy है” और “आपने यह obvious और easy बात नहीं सोची”—annoying या insulting लगती है। उल्टा जब मैं किसी से पूछता हूँ तो “why just” से बचने की कोशिश करता हूँ, और “क्या मैं यह समझूँ कि आपने X किसी वजह से नहीं किया?” जैसे पूछना, या बस विनम्रता से वजह पूछना, शायद बेहतर होता है
अगर सवाल context की कमी से आता है, तो मैंने जो किया उसे explain करने से पहले यह बताना कि सबसे obvious तरीके क्यों काम नहीं आए, या tricky requirements और problem inputs क्या थे, इसे रोक सकता है। अगर code पहले ही committed है, तो commit या merge request comments के जरिए बाद की बेकार बहस कम करना goal होता है। कभी-कभी rebut न करके यह directly explain करना कि वह तरीका try किया था लेकिन क्यों नहीं चला, और sincerely पूछना कि क्या कोई दूसरा idea है, भी उपयोगी होता है
अगर सच में ऐसा suggestion हो जिसके बारे में मैंने सोचा नहीं था और जो problem solve कर सकता है, तो मैं उसे अच्छा idea कहता हूँ और implementation में मदद मांगता हूँ। उस समय सामने वाले की assumption या tone का जवाब देने का मन करता है, लेकिन मैं कोशिश करता हूँ कि बस उसे accept करूँ और थोड़ी देर शर्मिंदा हो लूँ
यह grug brain को बहुत अच्छी तरह apply करने का case है https://grugbrain.dev/
“अगर complexity और tyrannosaurus से 1-on-1 लड़ाई में से चुनना हो, तो grug tyrannosaurus चुनेगा। कम से कम grug tyrannosaurus को देख तो सकता है”
अगर यह मज़ाक नहीं है, तो पहला सवाल मददगार नहीं है और लगभग mean behavior है। हर कोई कभी-कभी गलती करता है
दूसरा सवाल आम तौर पर ठीक-ठाक feedback हो सकता है। लोगों की skills और knowledge हमेशा overlap नहीं करतीं। A के लिए बेहद जटिल चीज़ B के लिए वैसी न हो सकती है, और उल्टा भी हो सकता है; यह ज़रूरी नहीं कि कोई ज़्यादा smart हो। A को SQL नहीं आता हो सकता है और B को pandas नहीं आता हो सकता है
अगर मान लें कि tech stack में SQL और pandas दोनों पहले से हैं, तो कभी-कभी कुछ code को SQL से pandas में ले जाना, या उल्टा, समझदारी हो सकती है। कुछ लोगों को object-oriented style आसान लगता है और कुछ को functional style। क्या ज़्यादा उचित है, यह हमेशा साफ़ नहीं होता, इसलिए सवाल अच्छा सवाल हो सकता है। सुझाव खराब हो तो समझा दें कि क्यों खराब है, और अच्छा हो तो देखें कि अभी करने लायक है या नहीं। बीच का मामला हो या समय न हो, तो मानकर आगे बढ़ जाएँ
दूसरा विकल्प है बस साफ़ तौर पर सहमत हो जाना। “हाँ, बेवकूफी थी, है न?” या “हाँ, शायद ऐसा नहीं करना चाहिए था”, या “मैं इस पर सोचूँगा” कह सकते हैं
तब सामने वाले के लिए मुझे यह कहकर शर्मिंदा करना या guilty महसूस कराना मुश्किल हो जाता है कि मैंने second-best काम किया। मुझे लगता है ऐसे वाक्यों का मकसद अक्सर शर्म के ज़रिए ऊँचा स्थान हासिल करना होता है। यह game में हिस्सा न लेने का चुनाव है, और आम तौर पर वही जीतने वाली चाल होती है
अगर बात अनजान होने की वजह से कही गई है, तो उसे हमला मानकर सामने वाले को शर्मिंदा कर कीमत चुकवाने की ज़रूरत नहीं है
पहले देखा हुआ कोई blog या लेख अब नहीं मिल रहा, लेकिन संदेश यह था: “code में suboptimal चीज़ देखकर अयोग्यता मानकर न चलें।” जिसने वह code लिखा था, उसके पास tight deadline, अलग priorities, या दूसरे कारण हो सकते थे जिनकी वजह से वह तुरंत “सही काम” नहीं कर पाया
लिखे जाने के समय code perfect रहा हो, फिर भी codebase की growth और requirements में बदलाव उसे खराब बना सकते हैं
उदाहरण के लिए, अगर store करने वाली items 10 हों तो simple file व्यावहारिक विकल्प हो सकती है, लेकिन 10,000 होने पर database की ज़रूरत पड़ सकती है। मगर अगर शुरू से ही 10 items के लिए database लगाया होता, तो लोग overengineering की शिकायत करते
2 classes हों तो if/else काफी है, लेकिन 20 classes होने पर Factory pattern की ज़रूरत पड़ सकती है; और अगर यह शुरू से किया होता तो architecture astronautics जैसा दिखता। ऐसी growth का अनुमान लगाने की कोशिश में गलत हुए, तो complex code बन जाता है। लगातार develop होने वाले projects व्यवस्थित रूप से अपने पुराने आकार से बड़े होते जाते हैं
Chesterton’s fence भी है। code में दिखने वाली कोई मूर्खतापूर्ण चीज़ पहले सचमुच महत्वपूर्ण रही हो सकती है। इससे भी बुरा, वह अभी भी किसी दुर्लभ edge case के लिए महत्वपूर्ण हो सकती है, लेकिन हम अभी उसका कारण नहीं देख पा रहे हों
blog post को लेकर यहाँ और reddit पर कुछ बार toxic comments मिले हैं। ऐसे समय मैं बिना judgment के उस toxic comment का link लेख में जोड़कर उस पर रोशनी डालने का तरीका अपनाता हूँ। आम तौर पर कुछ नहीं होता, लेकिन कभी-कभी discussion को ज़्यादा healthy दिशा में मोड़ देता है
मुझे भी काफी मिले हैं। कुछ शायद deserved रहे होंगे, लेकिन ज़्यादातर शायद नहीं। कुछ बातें कुछ हद तक सही थीं, लेकिन मददगार नहीं थीं या community के लिए सीधे harmful थीं। सही बात गलत तरीके से कहना फिर भी गलत बात कहना ही है
toxic comments को बिना judgment link करना बुरा idea नहीं है। अगर comment dead कर दिया गया हो तो यह हमेशा संभव नहीं होता, लेकिन किसी भी हालत में उसी तरीके से पलटकर वार नहीं करता। मैं भी कर सकता हूँ, लेकिन मैंने सीखा है कि petrol अच्छा fire extinguisher नहीं होता
अगर मैं गलत हूँ, तो कोशिश करता हूँ कि उसी जगह तुरंत मान लूँ जहाँ गलती हुई थी। public attack के बाद private apology मुझे खास तौर पर नापसंद है
एक सीमा होती है। मुझे लगता है मैं काफी अच्छा काम करता हूँ, लगभग 40 साल से कर रहा हूँ और इस दौरान बहुत सीखा है। मैंने ऐसे demanding environments में भी काम किया है जहाँ low-quality काम स्वीकार नहीं होता था, इसलिए ठीक-ठाक काम करना मेरी आदत बन गया है
आम तौर पर public में दूसरों को judge करने से बचता हूँ। इससे मदद नहीं मिलती, और मैं हमेशा सही भी नहीं होता। हालांकि अगर साथ काम करना हो या उस व्यक्ति की चीज़ इस्तेमाल करनी हो, तो स्थिति अलग हो सकती है। मुझे trash accept न करने के कारण harsh attacks भी झेलने पड़े हैं, लेकिन मैं Linus Torvalds जैसा व्यवहार नहीं करता। जहाँ संभव हो, सम्मानजनक तरीके से कहता हूँ कि वह काम मेरे लिए acceptable नहीं है
फिर भी हमेशा सुधार किया जा सकता है और नया सीखा जा सकता है, और कभी-कभी बिल्कुल अनपेक्षित जगह से सीख मिलती है। इस तरह की learning के लिए open रहना मूल रूप से अच्छी policy है। मैं गलत होकर और सीखकर सही बनता हूँ। “अच्छा judgment experience से आता है, और experience खराब judgment से आता है”
मेरे पसंदीदा podcasts में से एक, YouTube का well there's your problem, podcast पर शिकायत करने वाली comments को लगभग हमेशा pin करता है। ज़्यादातर शिकायतें “मुझे यह podcast पसंद नहीं, इसलिए इसे कोई दूसरा podcast बन जाना चाहिए” वाली होती हैं, और जो comment pin होती है वह हर बार उस episode की लगभग सबसे मूर्खतापूर्ण व्याख्या होती है
पता नहीं इससे ऐसी comments कम होती हैं या नहीं, लेकिन जो लोग discourse में इस तरह हिस्सा लेते हैं, उन्हें रूपकात्मक idiot hat पहनाने का मतलब तो है
मैं सहमत हूँ कि कुछ engineers का attitude खराब होता है। कोई भी खराब code लिख सकता है, और यह तर्क भी कुछ हद तक सही है कि सारा code खराब है और debt है
यह लेख “No more pink mustache” के साथ पढ़ना दिलचस्प है। उस लेख में Lyft को “अविश्वसनीय scale पर टूटा हुआ” बताया गया है, और quality की वजह अक्सर कुर्सी पर बैठा व्यक्ति नहीं बल्कि organization होती है :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
मैंने यह लेख 2018 में पढ़ा था और फिर से ऊपर आया देखकर अच्छा लगा। यह उन लेखों में से था जिसने मुझे खुद से सवाल पूछने पर मजबूर किया। अगर absolutism या extremism को खत्म नहीं किया जा सकता, तो ऐसी बातचीत या ऐसे लोगों से सामना होने पर कौन-सा filter बनाया जा सकता है—मैं इस पर सोचने लगा। मेरा अपना model है, लेकिन जानना चाहूँगा कि दूसरे लोग कौन-सी strategies अपनाते हैं
ऐसे लोग ऐसे emotional territory पर कब्ज़ा करना चाहते हैं जो उनका नहीं है। आम तौर पर वे पहले ही हिसाब लगा चुके होते हैं कि वे “ऐसा कर सकते हैं”, और इसका मतलब है कि वे सामने वाले को कमजोर मानते हैं
विकल्प तीन हैं। हार मानकर वह territory दे दें और अपनी life जारी रखें; अन्याय के कारण जितनी कम नींद खराब हो, उतना अच्छा। सीधे मुकाबला करें; वे लड़ाई के लिए तैयार होते हैं, लेकिन उनका position मूल रूप से irrational होता है, इसलिए आप उनके thought space में जितना कम खिंचते हैं, उतना “जीतते” हैं। ऊपर से स्थिति सँभालें; यानी वे गलत हैं इसका social proof उनके space में ले आएँ। मूल लेख के मामले में, यह वे productive programmers होंगे जो एक-दूसरे के काम का सम्मान करते हैं और nitpick नहीं करते
जब कोई सलाह देता है कि “ऐसा किया होता तो बेहतर हो सकता था”, तो वह हमेशा मुझ पर हमला या मेरी क्षमता का अपमान नहीं होता
सलाह देने वाला व्यक्ति interpersonal relationships में कमजोर बेवकूफ भी हो सकता है, या बस पूरी तरह बेवकूफ भी हो सकता है। दुनिया का कोई हिस्सा मुझसे सहमत न हो तो भी ठीक है। लोग विरोधी राय दें या असहमत हों, इसका मतलब यह नहीं कि वे मुझे धमका रहे हैं
अजीब लेख है। ट्वीट जैसा लगता है, कंटेंट कम है और शीर्षक body को reflect नहीं करता, इसलिए clickbait जैसा दिखता है
मैं इसके मूल point से असहमत नहीं हूं, लेकिन दूसरी side भी है। feedback स्वीकार करने की क्षमता भी जरूरी है
ज्यादातर लोग feedback स्वीकार कर सकते हैं और उसे apply कर सकते हैं। बस कुछ लोग feedback बेहद खराब तरीके से देते हैं और फिर मान लेते हैं कि सामने वाला feedback नहीं ले पा रहा
ऐसे लोग सोचते हैं कि feedback देने का उनका पसंदीदा तरीका ही सबसे अच्छा है और सबको वैसा ही महसूस करना चाहिए; अगर नहीं, तो सामने वाले को बदलना चाहिए। जाहिर है, यह गलत है। लेकिन अगर आप उन्हें यह बताएं, तो वे खुद दिखा देते हैं कि मैंने पहले वाक्य में “ज्यादातर” क्यों कहा था
1 टिप्पणियां
Hacker News की राय
अकेले हों तो ज़रूरी कामों को priority दे सकते हैं, लेकिन टीम में second-best decisions हमेशा के लिए रह जाते हैं या “system down” वाले पल तक छोड़ दिए जाते हैं। उसके बाद postmortem में, जब मैं महीनों पहले से उस time bomb को ठीक करने की मांग वाले ticket की ओर इशारा करता, तो उसे “blame” या “aggressive” माना जाता था। अंत में समाधान जैसे यह बन गया कि suboptimal code कभी लिखना ही नहीं है, जिससे coding करते समय frustration और anxiety बढ़ गई
2017 में मुझे 2003/2004 में लिखे code को ठीक करने के लिए भी contact किया गया, और वह code अब भी production में चल रहा था। टूटे हुए code और किए गए compromises को दोबारा देखते हुए यह समझना कि ज़िम्मेदार व्यक्ति मैं ही था, काफी विनम्र बना देने वाला अनुभव है; उसके बाद maintainable code और documentation को लेकर मेरा नज़रिया बहुत बदल गया
S&P 500 की बड़ी companies, 100 million से 1 billion dollar आकार की companies, और startups तक में ऐसे experience आम थे। ऐसे मामलों में skilled software engineers और managers होते थे जो reasonable trade-offs कर सकते थे और business needs का भी ध्यान रखते थे, और engineers अक्सर customers से सीधे interact भी करते थे
असली बात balance है, और वह balance आम तौर पर उन लोगों से आता है जो संतुलित judgement कर सकते हैं। अगर सिर्फ “perfection” का पीछा करें तो endless refactoring और release न हो पाने की स्थिति आती है; और अगर technical debt या खराब quality को ignore करें, तो समय के साथ business ढह सकता है। आप कहाँ खड़े होंगे, यह product, industry, customers और business पर निर्भर करता है
मेरा past self युवा और naive था, लेकिन productive था, और उसने कई पहाड़ पार किए थे। Code समझने में दो दिन लगे, लेकिन अंत में वह काफी clever निकला; और शायद current self ने सब कुछ इसलिए भुला दिया क्योंकि memory खराब है
मेरा future self सारी गलतियाँ ठीक कर देगा। वह ज्यादा उम्रदराज़ और समझदार होगा, XXX और TBD को smart code में बदलेगा, अच्छे ideas implement करेगा और औसत ideas को फिर से implement करने के लिए उसके पास अनंत समय होगा—ऐसा मैं मानता हूँ। बेहतर comments हों तो शायद ये तीनों एक हो जाएँ
यह सिर्फ learning opportunity नहीं है, बल्कि open culture दिखाता है और imposter syndrome से भी मुकाबला करता है। Perfectionist attitude इसके उलट बस “और मेहनत करो ताकि गलती न हो” कहता है; उससे सीखने को कुछ नहीं मिलता और बस individual effort की और मांग होती है
एक बार junior ने report में गलत software version डालने की छोटी गलती की, जिसकी जिम्मेदारी मैंने ले ली। Customer को बस यह कहना था कि “एक गलती हुई थी और corrected report यहाँ है”, लेकिन boss बस यह सोच रहा था कि “क्या हम इसे छिपाकर यह face बनाए रख सकते हैं कि हम perfect हैं?” वही व्यक्ति दूसरों की गलतियों को discount, compensation या free delivery मांगने के मौके की तरह इस्तेमाल करता था
फिर भी ठीक है। जब बदलने की वजह बनेगी तो उन्हें साफ कर देंगे, और तब तक वे bad practices और बेहतर approaches दिखाने वाले examples बने रहेंगे
आजकल मैं जवाब देता हूँ, “शायद आपका IQ मुझसे ज्यादा है। मेरा IQ कम है, इसलिए मुझे ज्यादा dumb और simple काम करने चाहिए।” तब कभी-कभी सामने वाले को एहसास होता है कि वह बिना self-reflection के कितना dismissive छोटा weirdo जैसा behave कर रहा था, और उसका चेहरा लाल हो जाता है
सवाल अपने आप में खराब नहीं है, लेकिन इसमें छिपी धारणा—“मेरा idea बहुत easy है” और “आपने यह obvious और easy बात नहीं सोची”—annoying या insulting लगती है। उल्टा जब मैं किसी से पूछता हूँ तो “why just” से बचने की कोशिश करता हूँ, और “क्या मैं यह समझूँ कि आपने X किसी वजह से नहीं किया?” जैसे पूछना, या बस विनम्रता से वजह पूछना, शायद बेहतर होता है
अगर सवाल context की कमी से आता है, तो मैंने जो किया उसे explain करने से पहले यह बताना कि सबसे obvious तरीके क्यों काम नहीं आए, या tricky requirements और problem inputs क्या थे, इसे रोक सकता है। अगर code पहले ही committed है, तो commit या merge request comments के जरिए बाद की बेकार बहस कम करना goal होता है। कभी-कभी rebut न करके यह directly explain करना कि वह तरीका try किया था लेकिन क्यों नहीं चला, और sincerely पूछना कि क्या कोई दूसरा idea है, भी उपयोगी होता है
अगर सच में ऐसा suggestion हो जिसके बारे में मैंने सोचा नहीं था और जो problem solve कर सकता है, तो मैं उसे अच्छा idea कहता हूँ और implementation में मदद मांगता हूँ। उस समय सामने वाले की assumption या tone का जवाब देने का मन करता है, लेकिन मैं कोशिश करता हूँ कि बस उसे accept करूँ और थोड़ी देर शर्मिंदा हो लूँ
“अगर complexity और tyrannosaurus से 1-on-1 लड़ाई में से चुनना हो, तो grug tyrannosaurus चुनेगा। कम से कम grug tyrannosaurus को देख तो सकता है”
दूसरा सवाल आम तौर पर ठीक-ठाक feedback हो सकता है। लोगों की skills और knowledge हमेशा overlap नहीं करतीं। A के लिए बेहद जटिल चीज़ B के लिए वैसी न हो सकती है, और उल्टा भी हो सकता है; यह ज़रूरी नहीं कि कोई ज़्यादा smart हो। A को SQL नहीं आता हो सकता है और B को pandas नहीं आता हो सकता है
अगर मान लें कि tech stack में SQL और pandas दोनों पहले से हैं, तो कभी-कभी कुछ code को SQL से pandas में ले जाना, या उल्टा, समझदारी हो सकती है। कुछ लोगों को object-oriented style आसान लगता है और कुछ को functional style। क्या ज़्यादा उचित है, यह हमेशा साफ़ नहीं होता, इसलिए सवाल अच्छा सवाल हो सकता है। सुझाव खराब हो तो समझा दें कि क्यों खराब है, और अच्छा हो तो देखें कि अभी करने लायक है या नहीं। बीच का मामला हो या समय न हो, तो मानकर आगे बढ़ जाएँ
तब सामने वाले के लिए मुझे यह कहकर शर्मिंदा करना या guilty महसूस कराना मुश्किल हो जाता है कि मैंने second-best काम किया। मुझे लगता है ऐसे वाक्यों का मकसद अक्सर शर्म के ज़रिए ऊँचा स्थान हासिल करना होता है। यह game में हिस्सा न लेने का चुनाव है, और आम तौर पर वही जीतने वाली चाल होती है
उदाहरण के लिए, अगर store करने वाली items 10 हों तो simple file व्यावहारिक विकल्प हो सकती है, लेकिन 10,000 होने पर database की ज़रूरत पड़ सकती है। मगर अगर शुरू से ही 10 items के लिए database लगाया होता, तो लोग overengineering की शिकायत करते
2 classes हों तो if/else काफी है, लेकिन 20 classes होने पर Factory pattern की ज़रूरत पड़ सकती है; और अगर यह शुरू से किया होता तो architecture astronautics जैसा दिखता। ऐसी growth का अनुमान लगाने की कोशिश में गलत हुए, तो complex code बन जाता है। लगातार develop होने वाले projects व्यवस्थित रूप से अपने पुराने आकार से बड़े होते जाते हैं
toxic comments को बिना judgment link करना बुरा idea नहीं है। अगर comment dead कर दिया गया हो तो यह हमेशा संभव नहीं होता, लेकिन किसी भी हालत में उसी तरीके से पलटकर वार नहीं करता। मैं भी कर सकता हूँ, लेकिन मैंने सीखा है कि petrol अच्छा fire extinguisher नहीं होता
अगर मैं गलत हूँ, तो कोशिश करता हूँ कि उसी जगह तुरंत मान लूँ जहाँ गलती हुई थी। public attack के बाद private apology मुझे खास तौर पर नापसंद है
एक सीमा होती है। मुझे लगता है मैं काफी अच्छा काम करता हूँ, लगभग 40 साल से कर रहा हूँ और इस दौरान बहुत सीखा है। मैंने ऐसे demanding environments में भी काम किया है जहाँ low-quality काम स्वीकार नहीं होता था, इसलिए ठीक-ठाक काम करना मेरी आदत बन गया है
आम तौर पर public में दूसरों को judge करने से बचता हूँ। इससे मदद नहीं मिलती, और मैं हमेशा सही भी नहीं होता। हालांकि अगर साथ काम करना हो या उस व्यक्ति की चीज़ इस्तेमाल करनी हो, तो स्थिति अलग हो सकती है। मुझे trash accept न करने के कारण harsh attacks भी झेलने पड़े हैं, लेकिन मैं Linus Torvalds जैसा व्यवहार नहीं करता। जहाँ संभव हो, सम्मानजनक तरीके से कहता हूँ कि वह काम मेरे लिए acceptable नहीं है
फिर भी हमेशा सुधार किया जा सकता है और नया सीखा जा सकता है, और कभी-कभी बिल्कुल अनपेक्षित जगह से सीख मिलती है। इस तरह की learning के लिए open रहना मूल रूप से अच्छी policy है। मैं गलत होकर और सीखकर सही बनता हूँ। “अच्छा judgment experience से आता है, और experience खराब judgment से आता है”
पता नहीं इससे ऐसी comments कम होती हैं या नहीं, लेकिन जो लोग discourse में इस तरह हिस्सा लेते हैं, उन्हें रूपकात्मक idiot hat पहनाने का मतलब तो है
यह लेख “No more pink mustache” के साथ पढ़ना दिलचस्प है। उस लेख में Lyft को “अविश्वसनीय scale पर टूटा हुआ” बताया गया है, और quality की वजह अक्सर कुर्सी पर बैठा व्यक्ति नहीं बल्कि organization होती है :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
विकल्प तीन हैं। हार मानकर वह territory दे दें और अपनी life जारी रखें; अन्याय के कारण जितनी कम नींद खराब हो, उतना अच्छा। सीधे मुकाबला करें; वे लड़ाई के लिए तैयार होते हैं, लेकिन उनका position मूल रूप से irrational होता है, इसलिए आप उनके thought space में जितना कम खिंचते हैं, उतना “जीतते” हैं। ऊपर से स्थिति सँभालें; यानी वे गलत हैं इसका social proof उनके space में ले आएँ। मूल लेख के मामले में, यह वे productive programmers होंगे जो एक-दूसरे के काम का सम्मान करते हैं और nitpick नहीं करते
सलाह देने वाला व्यक्ति interpersonal relationships में कमजोर बेवकूफ भी हो सकता है, या बस पूरी तरह बेवकूफ भी हो सकता है। दुनिया का कोई हिस्सा मुझसे सहमत न हो तो भी ठीक है। लोग विरोधी राय दें या असहमत हों, इसका मतलब यह नहीं कि वे मुझे धमका रहे हैं
ऐसे लोग सोचते हैं कि feedback देने का उनका पसंदीदा तरीका ही सबसे अच्छा है और सबको वैसा ही महसूस करना चाहिए; अगर नहीं, तो सामने वाले को बदलना चाहिए। जाहिर है, यह गलत है। लेकिन अगर आप उन्हें यह बताएं, तो वे खुद दिखा देते हैं कि मैंने पहले वाक्य में “ज्यादातर” क्यों कहा था