- कई महीनों तक डर की वजह से लिखना और 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 के जरिए जुड़े रहने का रास्ता बताता है
अभी कोई टिप्पणी नहीं है.