LinkedIn को छोड़ते हुए

 (corecursive.com)
1 पॉइंट द्वारा GN⁺ 2024-03-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जब काम को सही तरीके से करना और कंपनी की तेज़ रफ़्तार आपस में टकराएँ, तो आपका चुनाव क्या होगा?
  • अपने विश्वासों पर टिके रहकर समझौता करना है, या अपने सिद्धांतों के अनुरूप काम खोजने के लिए आगे बढ़ जाना है—इंजीनियर Chris Krycho ने दूसरा रास्ता चुना।
  • Chris ने आखिरकार अपने सिद्धांतों से मेल खाने वाले काम को आगे बढ़ाने के लिए LinkedIn छोड़ दिया।
  • पॉडकास्ट में कही गई बातों का संक्षेप।
  • उनकी कहानी "innovation की ज़रूरत" और "project health के महत्व" के बीच के तनाव को रेखांकित करती है.

Chris Krycho का LinkedIn में पहला दिन

  • Chris जनवरी 2019 के अंत में LinkedIn से जुड़े। उन्होंने बड़े संगठनों या स्वस्थ छोटे संगठनों में आम तौर पर दिखने वाली कई onboarding प्रक्रियाओं से गुज़रे।
  • Chris को Colorado से remote काम करना था, लेकिन शुरुआती दो हफ्ते onboarding और टीम के साथ समय बिताने में गए।

लाखों लाइनों का कोड

  • पिछली कंपनी के अनुभव की तुलना में, LinkedIn के frontend client app और backend services के पैमाने ने उन्हें बहुत चौंकाया।
  • LinkedIn का frontend 20 लाख lines तक फैला हुआ था, जो उनकी पिछली कंपनी के पूरे codebase से भी कहीं बड़ा था।

इन्फ्रास्ट्रक्चर टीम

  • Chris की भूमिका infrastructure team में थी, लेकिन server बनाने के बजाय engineering support या developer experience सुधारने पर ज़ोर था।
  • लक्ष्य था LinkedIn के बड़े desktop app पर काम करना अधिक आसान बनाना।

JavaScript modernization

  • उन्होंने JavaScript classes को अपनाकर code modernization के काम में हिस्सा लिया। Ember framework का उपयोग करते समय आने वाली समस्याओं को सुलझाने की प्रक्रिया में उन्होंने बहुत कुछ सीखा।
  • उन्होंने समझा कि बड़े codebase में migration को जितना हो सके automate करना चाहिए, क्योंकि यह हाथ से करने के लिए बहुत बड़ा काम है।

TypeScript अपनाना

  • frontend में होने वाली गलतियों को कम करने के लिए TypeScript की ओर बढ़ने का फैसला किया गया।
  • TypeScript को धीरे-धीरे अपनाया जा सकता है, और यही वह scalability देता है जिसकी LinkedIn को ज़रूरत थी।

धीमी migration योजना बनाम 'Finger Gun's Plan'

  • Chris और उनकी टीम ने Ember code को React में migrate करने के लिए 3–5 साल की योजना पेश की, लेकिन दूसरी टीम ने पूरा पुनर्विचार और तेज़ execution का वादा करने वाला 'Finger Gun's Plan' रखा।
  • इस approach का अंतर, Chris और उनकी टीम द्वारा देखी जा रही समस्याओं और कंपनी की speed-first culture के बीच के टकराव को दिखाता है।

Chris के अनुभव और सीख

  • अपर्याप्त alerting की समस्या को पहचाना गया।
  • memory usage बढ़ने और server restart की chain reaction के कारण पूरे data center के server down हो गए।
  • system reset और permissions adjustment के ज़रिए समस्या सुलझाने की कोशिश की गई।
  • failure अपरिहार्य है, और software engineering दरअसल ऐसे systems design करने का काम है जो engineers को product outcomes बनाने की प्रक्रिया में support करें।
  • कई स्तरों वाली resilience रखने वाले system की ज़रूरत पर ज़ोर दिया गया।

घटना पर प्रतिक्रिया

  • समस्या सुलझाने की प्रक्रिया में management के trust की कमी से असंतोष पैदा हुआ।
  • senior engineers के साथ मतभेद और communication problems सामने आए।
  • इस बात पर ज़ोर दिया गया कि system सिर्फ़ सबसे अच्छी स्थिति में ही नहीं, बल्कि हर स्थिति में सहारा देने लायक होना चाहिए।

बढ़ता दबाव

  • technical debt कम करने और resilience बढ़ाने की कोशिशों के बावजूद management की नाराज़गी बढ़ती गई।
  • जटिल समस्याओं के लिए सरल समाधान मांगने वाले management के साथ टकराव हुआ।

संगठनात्मक पुनर्गठन

  • 'Finger Guns team' के कारण organizational restructuring और role changes हुए।
  • दूसरी भूमिकाओं में नए अनुभव और सीखने के अवसरों को पहचाना गया।

आत्मचिंतन और जागरूकता

  • पिछले अनुभवों और मौजूदा स्थिति के आधार पर आत्मचिंतन किया गया।
  • मानवीय संबंध बनाने और communication के महत्व को समझा गया।
  • यह समझ विकसित हुई कि technical और social समस्याएँ एक-दूसरे से जुड़ी होती हैं।

निष्कर्ष और सीख

  • Chris ने speed को सर्वोच्च मूल्य मानने वाली culture पर आलोचनात्मक नज़र बनाए रखी।
  • अपने career और personal values पर विचार करते हुए नई opportunities की तलाश की।
  • engineering excellence को आगे बढ़ाने वाली भूमिका खोजने की Chris की यात्रा जारी है।

GN⁺ की राय

  • Chris Krycho का अनुभव technical principles और business demands के बीच के टकराव को अच्छी तरह दिखाता है।
  • उनका फैसला इस बात पर ज़ोर देता है कि व्यक्तिगत values और professional choices के बीच संतुलन खोजना कितना महत्वपूर्ण है।
  • LinkedIn जैसे बड़े तकनीकी माहौल में change management जटिल होता है, और यह दूसरी कंपनियों के लिए भी महत्वपूर्ण सीख देता है।
  • TypeScript जैसी तकनीक अपनाने से code quality बेहतर हो सकती है और errors कम हो सकते हैं, लेकिन बड़े codebase में इसके लिए gradual approach ज़रूरी है।
  • ऐसे technical बदलावों को आगे बढ़ाते समय developer experience और product release speed के बीच संतुलन पर विचार करना चाहिए।

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

1 टिप्पणियां

 
GN⁺ 2024-03-07
Hacker News राय

  • एक मैनेजर के साथ बातचीत में उनसे कहा गया कि 'तुम बहुत idealistic हो, revenue को पर्याप्त महत्व नहीं देते, और तुम्हें अपने values बदलने चाहिए।' उन्होंने इस पर असहजता व्यक्त की और अपने values पर कायम रहने की इच्छा जताई। यह बात podcast का सबसे दिलचस्प हिस्सा लगी, और लेखक को इससे यह आभास हुआ कि शायद उन्होंने महत्वपूर्ण feedback को जानबूझकर नज़रअंदाज़ किया। करियर से सीखा गया सबक यह है कि सही बात जानना मुश्किल नहीं है; असली मुश्किल पूरे संगठन को सही समाधान पर एकमत करना है.

    • मैनेजर के साथ बातचीत में values के टकराव का अनुभव
    • महत्वपूर्ण feedback को जानबूझकर नज़रअंदाज़ करने का आभास
    • सही समाधान पर पूरे संगठन की सहमति एक अहम सबक

  • 2019 में मैंने facebook.com को React में rewrite करने के काम में हिस्सा लिया था। मुझे LinkedIn के codebase या संगठन के बारे में सीधे तौर पर जानकारी नहीं है, लेकिन मैंने ऐसे codebase और organizational structure वाली कंपनियाँ देखी हैं। मैं 'finger gun' approach का समर्थक हूँ, क्योंकि अगर इसे अच्छी तरह लागू किया जाए तो यह सकारात्मक नतीजे दे सकती है। जब कई client एक ही काम करने की कोशिश कर रहे हों, तो एक को आधार बनाकर दूसरे platform serve किए जा सकते हैं। या अगर आप नए सिरे से शुरू कर रहे हों, तो इसे साफ, तेज़ और संक्षिप्त तरीके से किया जा सकता है। सफलता का सामान्य पैटर्न यह है कि अनुभवी छोटे team नया system बनाते हैं; मेरा मानना है कि domain expert और technical expert के मेल वाली छोटी engineering team से सफलता मिलती है। technical management में बार-बार दिखने वाली बड़ी समस्या यह है कि सबसे कम अनुभवी लोग अगला बड़ा system बनाते हैं.

    • React में rewrite के अनुभव की साझेदारी
    • 'finger gun' approach और अनुभवी छोटे team के महत्व पर ज़ोर
    • कम अनुभवी लोगों द्वारा बड़े system बनाए जाने की समस्या की ओर इशारा

  • बड़े rewrite, manageable codebase में भी, जोखिम भरे होते हैं और बाकी बचे हुए issues पूरी तरह खत्म नहीं होते। कुछ साल बाद छिपे हुए settings page को फिर से कौन rewrite करना चाहेगा? काश codebase rewrite करने के लिए कोई framework होता, लेकिन हकीकत में ऐसा नहीं है। automated codemod को consistency चाहिए होती है, और उसका पालन कम ही होता है। समय के साथ code pattern बहुत बदल चुके होते हैं, इसलिए यह पेड़ के growth rings देखने जैसा लगता है। यह code को boxes में डालकर rearrange करने जैसा है, लेकिन box level पर automation नहीं होती.

    • codebase rewrite के जोखिम और बचे हुए issues
    • code rewrite के लिए framework का अभाव
    • code level automation और box level automation के बीच का अंतर

  • मैं अभी LinkedIn में काम करता हूँ, और podcast में Chris की role तथा frontend web development का ज़िक्र शायद ember से जुड़ा है। लगता है कि वह LinkedIn के monolithic flagship web app voyager-web की बात कर रहे हैं। LinkedIn में voyager-web के अलावा भी लाखों lines of code और लंबे build time वाले कई system हैं। उदाहरण के लिए, middle tier, offline data stack, metrics system, Kafka आदि। 17 मिनट का build time काफ़ी अच्छा है; अगर बिना किसी transient infra failure के 17 मिनट लगते हैं, तो यह बहुत अच्छा माना जाएगा.

    • LinkedIn में वर्तमान कार्य-अनुभव की साझेदारी
    • विभिन्न systems और build time के बारे में विवरण
    • 17 मिनट के build time का मूल्यांकन

  • लाखों lines of JavaScript code का मतलब अत्यधिक bloat है। इससे मेरे मन में LinkedIn जैसी service को फिर से implement करने या अपना खुद का contacts database बनाने का विचार आया। समस्या यह है कि contacts को bulk में migrate कैसे किया जाए। Microsoft LinkedIn की एक बड़ी समस्या यह है कि contact information export नहीं की जा सकती, जबकि contacts platform में यह एक अनिवार्य feature है.

    • JavaScript code के अत्यधिक bloat की ओर इशारा
    • contact information migrate करने की कठिनाई
    • contact information export feature के महत्व पर ज़ोर

  • मैंने LinkedIn में 12 साल बिताए, लेकिन अब यह उस पुराने engineering organization से काफ़ी दूर जा चुका है। Kevin Scott के engineering lead करने के समय को वह कहीं बेहतर मानते हैं.

    • LinkedIn में लंबे समय तक काम करने का अनुभव
    • पुराने engineering organization और मौजूदा स्थिति के बीच अंतर

  • यहाँ Conway's law काम कर रहा है। जब तक संगठन नहीं बदलता, वही code mess फिर से पैदा होगा। सकारात्मक engineering initiative ऊपर से आनी चाहिए और उसके लिए बहुत senior level का support ज़रूरी है। संगठन को नीचे से ऊपर बदलना संभव नहीं; संगठन ही codebase बनाता है.

    • संगठनात्मक बदलाव के बिना code mess के दोबारा पैदा होने की संभावना
    • ऊपर से आने वाली सकारात्मक engineering initiative की आवश्यकता

  • Chris Krycho ने अपनी कठिनाइयों के बारे में ईमानदारी से बात की, फिर भी blame game नहीं खेला—यह बात मुझे गहराई से प्रभावित कर गई। CoRecursive उन podcasts में से एक है जो मुझे बहुत पसंद हैं, क्योंकि यह code के पीछे के जटिल context को खंगालता है.

    • Chris Krycho की ईमानदार और गैर-दोषारोपण वाली प्रवृत्ति
    • CoRecursive podcast के बारे में सकारात्मक राय

  • Ember से React की ओर migration मुझे उस client द्वारा बनाई गई technology के लिए एक उपयुक्त case लगता है, जिसके साथ मैं पहले काम करता था। उसने 'Unhack' नाम की एक language बनाई थी, जिससे AST level पर search and replace किया जा सकता था। इसमें source code में एक pattern निर्दिष्ट किया जाता था और उसे किस दूसरे pattern से बदलना है, यह भी बताया जाता था। मैंने कुछ साल पहले उस client के साथ काम बंद कर दिया था, इसलिए नहीं जानता कि वह अब भी मौजूद है या नहीं.

    • Ember से React migration का एक तकनीकी उदाहरण
    • AST level search and replace को संभव बनाने वाली 'Unhack' language

  • LinkedIn का codebase बिखरा हुआ है, यह उनकी website इस्तेमाल करके कोई चौंकाने वाली बात नहीं लगती। आप किसी दिलचस्प post पर क्लिक करें, फिर लेखक के बारे में और जानने की कोशिश करें, और उसके बाद back दबाएँ तो feed refresh हो जाती है और post खो जाता है। अगर आप received messages scroll करने की कोशिश करें, तो पूरा webpage धीमा पड़ जाता है और input register होने में 10-15 सेकंड लगते हैं। 30 fake notifications क्यों मिलती हैं? ये लोगों से interaction मजबूर कराने के लिए बनाई गई fake notifications हैं। recommendation algorithm भी पूरी तरह भयानक है.

    • LinkedIn website इस्तेमाल करने में कठिनाइयाँ
    • fake notifications और webpage की धीमी प्रतिक्रिया
    • recommendation algorithm की समस्याओं की ओर इशारा