एक software developer की स्वीकारोक्ति: अब और self-censorship नहीं

• कई महीनों तक डर की वजह से लिखना और online activity रोक देने वाले एक developer ने self-censorship बंद करने और अब तक स्वीकार न की गई अपनी तकनीकी व व्यक्तिगत कमियों को खुलकर बताने का फैसला किया
• उसने माना कि वह polymorphism की अवधारणा को 10 साल से अधिक समय तक समझ नहीं पाया, SQL की अपनी पकड़ खो दी, और अपने अधिकांश code को automated tests के बिना deploy करता रहा
• कंपनी के tech stack में बदलाव के साथ तालमेल बिठाने की कोशिश में उसने C# और Blazor सीखना बीच में छोड़ दिया, अब भी Ruby से प्यार करता है लेकिन उसे पेशेवर रूप से इस्तेमाल नहीं कर पाता, और manager व सहकर्मियों द्वारा blog पढ़े जाने की स्थिति में महसूस होने वाले मानसिक दबाव के बारे में भी लिखा
• AI से लिखे गए PR को submit करने के बाद cyberbullying झेलने का अनुभव, remote work को लेकर ईमानदार भावनाएँ, और संगठन के भीतर custom development process की अनावश्यकता पर उसकी साफ राय भी शामिल है
• अंत में वह डर को छोड़कर अब और self-censorship के बिना लगातार सीखने और सार्वजनिक रूप से लिखते रहने का संकल्प दोहराता है

---

शुरुआत: डर और self-censorship रोकने का कारण

• अप्रैल के बाद एक ऐसा समय था जब डर इतना बढ़ गया था कि वह कुछ पोस्ट नहीं कर पा रहा था, और उसने social media, news aggregator, और forum—सब कुछ छोड़ दिया था
  • उसे लगा कि यह स्थिति अब और नहीं चल सकती, इसलिए उसने डर से आगे बढ़कर फिर से लिखना शुरू करने का फैसला किया
• वह अपनी कमजोर बुनियाद को दिखाना नहीं चाहता था और उन्हें छिपाकर रखता रहा, लेकिन उसने यह देखना शुरू किया कि कई developer ऐसे ही ज्ञान की खाली जगहों के साथ काम कर रहे हैं
  • अब तक सीखने का उसका तरीका केवल इस्तेमाल वाले हिस्से में फैलते slime mold जैसा था, और जिन ज्ञान क्षेत्रों का इस्तेमाल नहीं हुआ वे सूखते गए
• हाल में उसने फिर से fundamentals भरना शुरू किया, और सीखी हुई बातों को लिखकर व बोलकर दोबारा गढ़ते हुए “मुझे नहीं पता” को हल्केपन से स्वीकार करने का भाव बनने लगा
• उसने खुद महसूस किया कि fundamentals दोबारा सीखे जा सकते हैं, और इससे कभी भी बहुत देर नहीं होती जैसा भरोसा पैदा हुआ

10 साल से अधिक समय तक polymorphism न समझ पाने का दौर

• 2012 से वह मानता रहा कि वह object-oriented code लिख रहा है, लेकिन लगभग एक साल पहले तक भी वह polymorphism को ठीक से नहीं समझता था—यह बात उसने खुद स्वीकार की
  • उसने इस हकीकत का सामना किया कि अब तक उसका लिखा code object-oriented कम और structural programming के ज्यादा करीब था
  • conditions को classes से बदलकर design बदलने का विचार उसके मन में कभी आया ही नहीं था
• Sandi Metz की writings और Martin Fowler की materials पढ़कर उसने देर से सही, इस concept को समझा, और साफ हुआ कि वह बहुत कुछ मिस करता रहा था

• इस बात को बताना मुश्किल क्यों था

  • job interview में object-oriented concepts का आकलन करने वाले व्यक्ति की भूमिका निभाने के बावजूद खुद polymorphism न जानना स्वीकार करना उसके लिए भारी था
  • करियर के शुरुआती दौर में principles की बजाय tools-केंद्रित learning पर झुका होना साफ सामने आता था, और CS में formal education न होने की वजह से छूटे हुए fundamentals का सामना करना आसान नहीं था

SQL भूल जाने का अनुभव

• एक समय ऐसा भी था जब वह SQL की किताबों के साथ अभ्यास प्रश्न हल करता था और JOIN व subquery आसानी से लिख लेता था
• frontend-केंद्रित काम लंबे समय तक करते रहने से SQL का इस्तेमाल पूरी तरह बंद हो गया, और एक दिन उसे अहसास हुआ कि पूरी की पूरी एक skill उसके दिमाग से गायब हो चुकी है
  • basic query याद आ जाती है, लेकिन left join और outer join का फर्क समझाने के लिए उसे फिर से documentation खोलनी पड़ती है

• इस बात को स्वीकार करना मुश्किल क्यों था

  • युवा उम्र में उसे लगता था कि कई साल बाद भी तथ्य और skills छोटे से hint से वापस याद आ जाते हैं
  • अब उसने महसूस किया कि यह क्षमता पहले जैसी नहीं रही, और याददाश्त से पूरी तरह फिसल जाने वाली पहली skill SQL थी—यह बात उसे गहराई से लगी
  • उम्र बढ़ने और memory के बदलते प्रवाह पर सार्वजनिक रूप से लिखना आसान नहीं था

automated tests के बिना development करने की हकीकत

• उसने खुद माना कि अब तक deploy किया गया उसका 95% से अधिक code automated tests के बिना production में चल रहा है
  • करियर की शुरुआत में उसे testing की अवधारणा से परिचय ही नहीं था, और Ember के दौर में testing tools का सही इस्तेमाल करना भी आसान नहीं था
• हाल के वर्षों में वह legacy code के साथ ज्यादा काम करता रहा, इसलिए code को testable बनाने की तैयारी में पर्याप्त समय नहीं दे पाया
  • केवल नए sub-system बनाते समय ही tests जोड़ पाना संभव हुआ

• इस बात को उजागर करना मुश्किल क्यों था

  • उसे लगता था कि यह स्वीकारोक्ति उसके करियर के लिए सबसे ज्यादा नुकसानदेह सच हो सकती है
  • Uncle Bob के मानदंड के अनुसार test के बिना production code चलाना अनैतिक माना जा सकता है, और इस मानदंड तथा अपनी वास्तविकता के बीच की दूरी का सामना करना उसे डराता था
  • उसे लगा कि अगर यह बात सार्वजनिक हो गई तो hiring process में उसके खिलाफ फैसला हो सकता है, इसलिए वह अपने learning process को दर्ज करना भी टालता रहा

Blazor न सीख पाने की वजह

• जब कंपनी ने Angular से Blazor पर जाने का फैसला किया, तब टीम में C# का अनुभव न रखने वाला वह अकेला व्यक्ति था, इसलिए जल्दी से बराबरी पर आने के लिए उसने पढ़ाई शुरू की
• कुछ महीनों बाद migration का फैसला वापस ले लिया गया, और उसकी सीखने की motivation ही खत्म हो गई; वह किताब भी पूरी नहीं कर पाया
• मूल रूप से C# या .NET वे भाषाएँ नहीं थीं जिन्हें वह side project में इस्तेमाल करना चाहता था; वह उन्हें केवल काम के लिए सीख रहा था

• यह लिखना कठिन क्यों था

  • अपनी पिछली post में वह आगे follow-up लिखने का वादा कर चुका था, और वह वादा पूरा किए बिना दूसरी बातें लिखना उसे लगातार असहज करता रहा
  • Blazor पर उसकी post को अच्छी views मिली थीं, इसलिए दिशा बदलने की बात स्वीकार करना उसे हार जैसा लग सकता था

Ruby को और ज्यादा इस्तेमाल करने की इच्छा

• Ruby आज भी उसके लिए सबसे सहज और आनंददायक भाषा है, और examples, open source, kata, hackathon जैसी जगहों पर वही स्वाभाविक रूप से उसके हाथ में आती है
• लेकिन 2013 के बाद से उसने Ruby के लिए एक बार भी salary नहीं पाई, और काम में TypeScript जैसी भाषाएँ इस्तेमाल करता रहा
• उसे कई कंपनियों के अपने सहकर्मी इतने पसंद आए कि लोगों को चुनने के लिए उसने language पर समझौता करना जारी रखा
• वह काम के बाद और weekend का समय Ruby पर देना चाहता है, लेकिन दूसरी जिम्मेदारियों और learning goals के कारण Ruby के लिए पर्याप्त समय लगभग कभी नहीं मिल पाता

• यह बताना कठिन क्यों था

  • उसका manager और CTO इस blog को पढ़ते हैं, इसलिए Ruby ज्यादा इस्तेमाल करने की इच्छा कहीं job छोड़ने के संकेत की तरह न पढ़ी जाए, इस बात का डर था
  • वह कंपनी में ऐसी छवि भी नहीं बनाना चाहता था कि वह सब पर कोई अपरिचित भाषा थोपना चाहता है

वयस्क होने के बाद भी दर्द देने वाला cyberbullying का अनुभव

• जब उसने एक open source project में LLM से बनाया गया छोटा patch submit किया और उस अनुभव को एक online forum पर साझा किया,
  तो उसे अयोग्य, घिनौना, खतरनाक जैसे निजी हमलों की बाढ़ का सामना करना पड़ा
• यह हमला उस site से आगे बढ़कर दूसरी websites, email, SMS, और phone calls तक पहुँच गया, और उसे सीधे तौर पर असुरक्षित महसूस हुआ
• उसने forum admin से अपना असली नाम हटाने को कहा, लेकिन उल्टा उसकी profile में और ज्यादा PII जोड़ दी गई,
  और यहाँ तक कि बाहरी संपर्क की बात गढ़ी गई थी—ऐसा झूठा बयान भी स्थायी रूप से जोड़ दिया गया
• आखिरकार उसे account deactivate करके site छोड़नी पड़ी

• यह लिखना कठिन क्यों था

  • कई दिनों तक चला यह harassment उसका सबसे जहरीला online अनुभव था, और उसका असर अब भी बाकी है
  • उसे लगातार डर लगा रहा कि यह बात सार्वजनिक करने पर हमलावर फिर से लौट सकते हैं
  • profile में बची झूठी जानकारी रोजगार पर बुरा असर डाल सकती है—यह सोच इसे और कठिन बना देती थी

SaaS टीम को ‘special process’ की जरूरत नहीं है—यह सोच

• software industry में दशकों से विकसित process पहले से मौजूद हैं,
  और Agile, Lean, Kanban, XP जैसी विधियाँ पहले ही साबित ढाँचे हैं
• इसलिए उसके मन में स्वाभाविक रूप से यह विचार बैठ गया कि कंपनी की सीमित क्षमता को नया process गढ़ने में नहीं, product development में लगना चाहिए

• यह कहना कठिन क्यों था

  • वह आमतौर पर उन्हीं विषयों पर लिखता है जिन्हें वह अच्छी तरह जानता है, और इस मामले में ट्रिगर उसकी ही कंपनी के एक सहकर्मी द्वारा सुझाया गया custom software development process था
    • उसे लगा कि यह कहीं किसी खास सहकर्मी या उसके विचार की सार्वजनिक आलोचना जैसा न लगे
  • वह Kent Beck और Martin Fowler जैसे लोगों की उस क्षमता से प्रभावित है, जो बेहतर सहयोग के तरीके समझाते हुए भी गलती करने वाले सहकर्मियों को सीधे निशाना नहीं बनाते
    • उसे लगा कि उसके पास अभी वह संतुलन पूरी तरह नहीं है, इसलिए वह लिखने से हिचकता रहा

remote work किस तरह वास्तविक सहयोग में बाधा डालता है

• remote work कई समस्याएँ हल करता है, लेकिन उसके मन से यह भावना नहीं जाती कि software development खुद साथ मौजूद रहने वाली जगह में ज्यादा बेहतर चलता है
• video calls low-bandwidth, low-sensory communication हैं, और इनमें आसपास की समझ खो जाने से सहकर्मियों की मुश्किलें पकड़ना कठिन हो जाता है
• मदद माँगना भी ज्यादा भारी लगता है, और whiteboard व sticky notes जैसी spatial thinking online tools में आसानी से टूट जाती है
• conflicts भी जल्दी बढ़ जाते हैं, क्योंकि monitor के पीछे दिख रहे व्यक्ति पर दुश्मन जैसी छवि चढ़ाना आसान होता है

• यह लिखना कठिन क्यों था

  • COVID के बाद उसकी कंपनी पूरी तरह remote हो गई, और उसी की वजह से वह 27 acre जमीन और परिवार के लिए dairy cow वाले जीवन तक पहुँच पाया
  • अब उसकी जीवन-व्यवस्था ऐसी हो चुकी है कि शहर में जाना आसान नहीं, इसलिए remote work पसंद न होने की बात कहना उसे
    मौजूदा नौकरी और भविष्य की हर remote job के लिए नुकसानदेह छवि जैसा महसूस होता था

आगे की योजना

• उसे लगता है कि इस लेख के साथ उसने डर से बाहर निकलने का पहला कदम फिर से उठा लिया है,
  और आगे भी fundamentals सीखते हुए वह सीखी गई हर बात बिना छिपाए लिखता रहेगा
• जिन लोगों ने ऐसा कुछ झेला है, जो मदद करना चाहते हैं, या अगला लेख पढ़ना चाहते हैं,
  उनके लिए वह Mastodon, RSS, और mailing list के जरिए जुड़े रहने का रास्ता बताता है

[GN⁺]

Hacker News राय

• मैंने एक बहुत ही स्मार्ट सहकर्मी से एक बात सीखी। वह जो नहीं जानता उससे डरता नहीं, और समझ आने तक सवाल पूछता रहता है। सार्वजनिक रूप से सीखने के लिए जिस आत्मविश्वास और धैर्य की ज़रूरत होती है, वह उसमें ग़ज़ब का था
• मुझे इस लेख की विनम्रता और ईमानदारी पसंद आई। जो नहीं जानते, उस पर शर्मिंदा होने की ज़रूरत नहीं है। मैं 37 साल से सीख रहा हूँ, फिर भी अब भी नई चीज़ें सीख रहा हूँ।
  मैं भी ऑफिस में काम करना पसंद करता हूँ, लेकिन इसका मतलब यह नहीं कि मैं RTO(ऑफिस वापसी) का समर्थन करता हूँ। यह बस मेरी व्यक्तिगत प्रवृत्ति है।
  लगता है कि इंडस्ट्री की बेचैनी और impostor syndrome लोगों को आक्रामक बना रही है। अगर सब थोड़ा ईमानदार हों, तो शायद माहौल अधिक सहज हो जाए।
  और सच कहूँ तो, मैंने Lisp या Haskell में Fibonacci से ज़्यादा जटिल कुछ कभी नहीं लिखा। मेरा दिमाग उस तरह काम नहीं करता
  • मैं remote work पर तुम्हारी राय से सहमत नहीं हूँ, लेकिन तुमने उसे व्यक्तिगत राय के रूप में रखा, इसलिए मुझे उसमें समस्या नहीं लगती।
    लेकिन मूल लेख में अपनी ही अनुभवजन्य बातों को मानो वस्तुनिष्ठ सत्य की तरह सामान्यीकृत करके कहा गया है। खासकर second-person शैली मुझे घमंडी लगी।
    कैसे कहा जाता है, यह उतना ही महत्वपूर्ण है जितना कि क्या कहा जाता है। remote work जैसे संवेदनशील विषयों पर तो और भी सावधानी चाहिए।
    मुझे भी परिवार की स्वास्थ्य समस्याओं के कारण remote work करना पड़ा है, इसलिए लेख का लहजा हल्का और असंवेदनशील लगा, और इससे गुस्सा आया।
    आखिर में, लोगों को अतिसंवेदनशील कहने से पहले, यह देखना चाहिए कि अपनी भाषा का दूसरों पर क्या असर पड़ता है
  • मैं भी Lisp-आधारित प्रोजेक्ट में आने से पहले Fibonacci से आगे कुछ नहीं लिख पाता था। रोज़ इस्तेमाल करते-करते आखिरकार आदत हो गई
  • remote work पसंद है यह कहते ही लोग गाली क्यों देने लगते हैं? क्योंकि कोविड के बाद आज़ादी पा चुके लोग फिर से बंधन में धकेले जाने जैसा महसूस करते हैं। इसलिए प्रतिक्रिया इतनी तीखी है
  • आजकल के YouTube coding gurus तो हर बात में खुद को सही बताते हैं। कुछ भी करो, दुनिया कहती है कि वह गलत है
• जब भी remote work की बात सुनता हूँ, IRC के दिन याद आते हैं। तब हम पहले ही remote collaboration बहुत अच्छे से कर रहे थे।
  कॉरिडोर की बातचीत की जगह team chat से समस्याएँ सुलझाते थे, और सब सक्रिय रूप से मदद करते थे।
  अब तो उल्टा लगता है कि हम tools का बेहतर उपयोग भी नहीं कर पा रहे
  • आजकल बहुत से लोग public channels में लिखने से डरते हैं। पहले anonymity थी, लेकिन अब असली नाम के माहौल में लोग ज़्यादा सतर्क रहते हैं।
    गुमनाम होकर बोलने की जगहें कम होने से खुलकर बोलना मुश्किल बनाने वाली संस्कृति बन गई है
  • पहले ऑफिस में Slack इस्तेमाल करते समय हम आज से कहीं ज़्यादा efficient थे।
    तब अगर कुछ अटकता था तो बस बगल की सीट पर जाकर हल कर लेते थे, लेकिन अब अगर अटक जाए तो बस वहीं खत्म
  • कोविड के दौर का remote work असली remote work नहीं था। वह isolation की स्थिति थी, और culture या process तैयार नहीं थे।
    इसलिए लोगों ने अपनी अकेलेपन की भावना का दोष remote work पर डाल दिया
  • मेरे हिसाब से बदलाव का कारण demography से ज़्यादा व्यक्तित्व में बदलाव है। पहले ज़्यादा ‘अजीब बच्चे’ हुआ करते थे, और वे सवाल पूछने से नहीं डरते थे।
    अब ज़्यादा socially adjusted लोग हैं, इसलिए asynchronous communication में वे कमजोर पड़ते हैं
  • chat से bug ठीक करना, ‘एक ही हवा में सांस लेना’ जैसा नहीं है।
    non-verbal signals पढ़ने की घनत्व कम होती है, इसलिए सामाजिक संकेत भी कम हो जाते हैं
• उसी SaaS इंडस्ट्री में होते हुए भी लगता है जैसे हम बिल्कुल अलग दुनिया में रह रहे हों।
  बहुत से developers दिलचस्पी से ज़्यादा career path का पीछा कर रहे हैं।
  मैंने SQL तीन बार फिर से सीखा है। टेक्नोलॉजी बदलती रहती है, इसलिए सब कुछ याद रखना संभव नहीं।
  महत्वपूर्ण syntax नहीं, बल्कि समस्या सुलझाने की क्षमता और सहयोग करने की क्षमता है।
  मुझे नहीं लगता AI इसे आसानी से replace कर पाएगा
• मैंने जो code लिखा, उसका 95% test coverage 0% था। कई देशों और कई कंपनियों में ऐसा था। सोचता हूँ क्या सिर्फ मैं ही ऐसा हूँ
  • automated tests दोहराए जाने वाले development में आत्मविश्वास देने वाला tool हैं। एक बार इसकी आदत हो जाए, फिर पीछे लौटने का मन नहीं करता
  • मेरा भी कुछ ऐसा ही अनुभव रहा, लेकिन अब इसे बदलना चाहता हूँ। बिना tests वाले project में बाद में tests जोड़ना सच में बहुत मुश्किल होता है
  • tests कुछ हद तक overrated भी हैं। वे गलत तरह की झूठी तसल्ली भी दे सकते हैं। कई बार language खुद tests के लिए उपयुक्त नहीं होती
• आसपास काम कर रहे लोगों का माहौल ही ध्यान केंद्रित करने में मदद करता है।
  focus के संक्रामक प्रभाव जैसा कुछ होता है। साथ काम करने की जगह productivity बढ़ाती है
  • मैं भी ऐसा ही हूँ। लेकिन कंपनी ‘clean desk policy’ थोपती है, इसलिए असुविधा होती है। मुझे personalized environment चाहिए
  • चहल-पहल वाले café में भी ऐसा ही असर महसूस होता है। दूसरों की productivity मुझे प्रेरित करती है
  • यह ADHD के ‘body doubling’ जैसा विचार है
  • मैं भी ऑफिस में काम करना पसंद करता हूँ, लेकिन दरवाज़े वाला कमरा ज़रूरी है।
    दरवाज़ा सहयोग और focus को नियंत्रित करने का सबसे अच्छा tool है।
    ऑनलाइन ‘away’ status से कहीं ज़्यादा स्पष्ट संकेत एक भौतिक दरवाज़ा देता है
  • लेकिन हर कोई ऐसे माहौल में अच्छा काम नहीं करता।
    किसी एक की एकाग्रता के लिए दूसरों को ज़बरदस्ती ऑफिस बुलाना अमानवीय है
• यह लेख साहसी है। लेकिन यह व्यक्तिगत अनुभव को सामान्य सत्य बना देने की समस्या भी अच्छी तरह दिखाता है।
  समस्या remote work नहीं, बल्कि शायद खराब support system वाली कंपनी में काम करने का अनुभव हो सकता है
• लेखक खुद पर बहुत कठोर है। यह मान लेना कि आप कुछ नहीं जानते, एक तरह की मुक्ति देता है।
  मैं भी अक्सर कहता हूँ, “मुझे नहीं पता।” यह high EQ वाले लोगों की पहचान है
  • मेरे मैनेजर को यह पसंद था कि मैं “मुझे नहीं पता” कह देता था। ईमानदारी भरोसा बनाती है
  • कार्यस्थल पर यह ठीक है, लेकिन ऑनलाइन प्रतिष्ठा की चिंता के कारण “मुझे नहीं पता” कहना मुश्किल होता है
  • interview में git rebase पूछते समय, मुझे लगता है कि तकनीकी बारीकियों से ज़्यादा वास्तविक उपयोग की क्षमता महत्वपूर्ण है
• मुझे लेखक की ईमानदारी पसंद आई। मेरा भी ऐसा ही अनुभव रहा है।
  Kotlin में live coding करते समय मुझे switch syntax याद नहीं आ रहा था और मैं घबरा गया।
  तब महसूस हुआ कि रोज़ इस्तेमाल की जाने वाली language भी जल्दी भूल सकते हैं
  • मैं भी switch syntax हर बार खोजता हूँ। जो चीज़ बार-बार इस्तेमाल न हो, उसका भूल जाना स्वाभाविक है
  • जैसे-जैसे उम्रदराज़ developers बढ़ेंगे, शायद ऐसे ‘भूल जाने वाले पलों’ के प्रति लोग ज़्यादा उदार होंगे
  • हर कोई गलती करता है। यहां तक कि मैनेजर भी कभी-कभी copy-paste shortcut भूल जाते हैं
  • अगर बार-बार इस्तेमाल न हो तो कौशल तेज़ी से क्षीण होता है, लेकिन फिर से इस्तेमाल करने पर जल्दी लौट भी आता है।
    concepts लंबे समय तक टिकते हैं, लेकिन बारीक syntax जल्दी गायब हो जाता है
• शुरुआत में लगा था कि यह लेख AI की वजह से developers के खत्म होने पर होगा।
  लेकिन असल में माहौल ऐसा है कि उस डर के बारे में खुलकर कहना भी मुश्किल है।
  मैं भी Claude से code लिखवाकर आनंद लेता हूँ, लेकिन साथ में डर भी है।
  अगर हम आने वाले बदलाव की प्रकृति को सबसे अच्छी तरह समझने वाली पीढ़ी हैं, तो हमें उस पर चर्चा करनी चाहिए
  • Claude द्वारा बनाया गया code इंसानी code से बेहतर होगा, ऐसा नहीं है। लेकिन वह उत्पादन की गति बढ़ा देता है।
    समस्या यह है कि कहीं यह कम कौशल वाले लोगों की productivity ही बढ़ाने का साधन न बन जाए
  • अगले कुछ सालों तक हम AI agents के team lead बने रहेंगे।
    लेकिन अगर कंपनियाँ AI को manager की भूमिका में इस्तेमाल करने लगें, तो human developers की जगह कम होती जाएगी।
    अभी से AI efficiency consultant जैसी भूमिकाओं की ओर बदलाव की तैयारी करनी चाहिए
  • मैं तो बस AI के साथ सहयोग करूँगा या कुछ और दिलचस्प काम करूँगा। programming ही सब कुछ नहीं है
  • ऐसी कंपनी जहाँ “AI doomer” policy हो, वह toxic organizational culture है। तुरंत नई नौकरी ढूँढनी चाहिए