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

 (corecursive.com)
1 पॉइंट द्वारा GN⁺ 2024-03-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Chris Krycho ने LinkedIn में लगभग 5 साल तक डेस्कटॉप वेब ऐप के फ्रंटएंड इंफ्रास्ट्रक्चर और डेवलपर अनुभव पर काम किया, जहाँ उन्हें बड़े codebase को सुरक्षित रूप से बदलने और तेज़ product execution की मांग के बीच टकराव का सामना करना पड़ा
  • उनके शामिल होने के समय लगभग 20 लाख lines JavaScript वाला LinkedIn डेस्कटॉप ऐप बाद में लगभग 32 लाख lines के monorepo में बदल गया, और migration automation तथा product teams पर न्यूनतम बोझ के बिना व्यावहारिक रूप से मुश्किल था
  • Ember modernization और TypeScript adoption का लक्ष्य errors कम करना और development quality सुधारना था, और TypeScript migration से application log errors को कम-से-कम 25% घटाया जा सकता है — इस विश्लेषण का उपयोग अंदरूनी सहमति बनाने में किया गया
  • Ember से React में जाने की योजना में Chris की टीम की 3–5 साल की क्रमिक automated strategy और तेज़ product experimentation के लिए मौजूदा तरीके को बड़े स्तर पर फिर से design करने वाला दृष्टिकोण आपस में टकराए
  • बड़े outage response के दौरान alerts, observability, resilience और code review की सीमाएँ सामने आईं, और Chris ने संगठन की speed-first दिशा को अपने मूल्यों से असंगत पाकर कंपनी छोड़ दी

5 साल का काम और codebase का आकार

  • Chris Krycho जनवरी 2019 के आखिर में LinkedIn से जुड़े और लगभग 5 साल तक वहाँ काम किया
  • उनका क्षेत्र server infrastructure नहीं, बल्कि LinkedIn डेस्कटॉप वेब ऐप का frontend infrastructure और developer experience सुधारना था
  • उन्होंने LinkedIn.com के non-mobile browser experience को संभालने वाले desktop app में बड़े JavaScript modernization projects का नेतृत्व किया
  • उनकी पिछली कंपनी का ऐप लगभग 1.5 लाख lines का था, लेकिन LinkedIn frontend उनके जुड़ने के समय लगभग 20 लाख lines code का था
  • उसी ऐप में हर quarter 150–200 engineers commit करते थे, और दर्जनों teams एक ही product को लगातार deploy करती थीं
  • उनके शामिल होने के समय हज़ारों engineers में 100 से भी कम remote engineers थे, और Chris Colorado से remote काम करने वाले दुर्लभ लोगों में थे

20 लाख lines code में migration कैसे किया जाए

  • शुरुआती बड़े कामों में से एक था Ember-आधारित code में JavaScript की आधुनिक class syntax लाना
  • मौजूदा Ember classes और native JavaScript classes inheritance chain में मिल जाने की समस्या थी, और अंदरूनी तौर पर इसे “Zebra Striping” कहा जाता था
  • इस पैमाने के migration को जितना संभव हो उतना automated होना ज़रूरी था
    • 20 लाख lines को manually ठीक करने में कई महीने या उससे ज़्यादा लग सकते थे
    • product teams से feature development रोककर सिर्फ नई syntax अपनाने को कहना मुश्किल था
  • LinkedIn में कई teams को पार करने वाली horizontal initiatives process थी, और product team participation को 10% से नीचे रखने का operating principle था
  • Chris की टीम ने माना कि product teams खुद codemod चलाएँ, उससे बेहतर यह है कि infrastructure team automation से PR बनाए और product teams review तथा smoke test संभालें — इस मॉडल को ज़्यादा आसानी से स्वीकार किया गया
  • Ember से जुड़े काम में कुल 18 महीने लगे; ज़्यादातर काम 6 महीने में हो गया, लेकिन कुछ teams की देरी से tail लंबी रही

TypeScript adoption के लिए error reduction का तर्क

  • Ember modernization के बाद Chris की टीम ने frontend में होने वाले बड़े पैमाने के JavaScript errors को अगला लक्ष्य बनाया
  • LinkedIn में error logs का आकार इतना बड़ा था कि बाहरी services की जगह अंदरूनी logging infrastructure उपयोग किया जाता था
  • LinkedIn ने पिछले साल 1 अरब members का आँकड़ा पार किया था, और Chris के जाने तक monorepo लगभग 32 लाख lines का था
    • आधा test code था
    • आधा production code था
  • Chris की टीम ने अलग से उन error categories का विश्लेषण किया जिन्हें TypeScript पकड़ सकता था
  • कुछ errors TypeScript से भी नहीं पकड़े जा सकते, लेकिन पूरी migration के बाद उनका अनुमान था कि हर दिन होने वाले लाखों JavaScript errors में application log volume को कम-से-कम 25% घटाया जा सकता है
  • Chris द्वारा लिखी गई TypeScript migration document engineers और managers के बीच बार-बार share की गई
    • कौन-सी समस्या हल करनी है
    • कौन-से फ़ायदे अपेक्षित हैं
    • hiring competitiveness के लिहाज़ से तुलना
    • दूसरी priorities के मुकाबले निर्णय के आधार
  • बाद में Chris मुश्किल TypeScript type समस्याओं में मदद करने वाले आंतरिक विशेषज्ञ की भूमिका निभाने लगे

Ember से React तक: क्रमिक बदलाव बनाम पूरा पुनर्रचना

  • LinkedIn दुनिया का सबसे बड़ा EmberJS user था, लेकिन Chris का काम अंततः Ember से React में जाने की योजना बनाने की दिशा में बदल गया
  • senior leadership का मानना था कि LinkedIn की migration cost बहुत अधिक है और यह product speed को धीमा करती है
  • Chris की टीम की योजना 3–5 साल की क्रमिक automated strategy थी
    • automation को मज़बूत करना ताकि product teams लगभग बिना रुके काम कर सकें
    • build pipeline, data layer, routing layer, reactivity system और view layer को क्रम से अलग करके transition करना
    • अंत में Ember rendering और reactivity system को React की ओर बदलना
  • दूसरी टीम ने speed problem को अधिक सीधे निशाना बनाया
    • idea से A/B test तक लगने वाले समय को महीनों से घटाकर हफ़्तों तक लाना लक्ष्य था
    • desktop web, mobile web, iOS और Android के अलग-अलग stacks और लंबे cycle time को समस्या माना गया
  • Chris ने उस टीम के approach को “finger guns mode” के क़रीब माना
    • दर्जनों लोगों के लिए काम करने वाले अनुभव को सैकड़ों engineers तक scale करते समय आने वाली समस्याओं को पर्याप्त रूप से संबोधित नहीं किया जा रहा था
    • सवालों पर अक्सर “यह समस्या नहीं बनेगी” जैसी प्रतिक्रिया मिलती थी
  • Chris की टीम की 3–5 साल की योजना को leadership से अच्छा response नहीं मिला
    • योजना खुद लंबी थी और उत्साहजनक नहीं लगती थी
    • टीम ने भी इसे “सबसे कम बुरा विकल्प” की तरह पेश किया, इसलिए persuasion कमज़ोर रही

Outage response में सामने आई resilience की समस्या

  • Chris के Christmas break से लौटने के बाद LinkedIn.com के कुछ users को लगभग 20 मिनट तक pages नहीं दिखे
  • समस्या एक pre-rendering service से जुड़ी थी, जो client code को Node.js पर चलाकर backend data इकट्ठा करती थी और उसे तेज़ी से पहुँचाती थी
  • service में memory leak था, और containers memory limit पार करने पर restart हो जाते थे
  • outage को बढ़ाने वाले कई कारण एक साथ थे
    • memory kill के लिए पर्याप्त alerts नहीं थे
    • एक साथ restart हो सकने वाले containers की संख्या YAML file की एक key से नियंत्रित होती थी
    • वह value type की दृष्टि से वैध थी, लेकिन इस system के लिए गलत थी
    • configuration value व्यावहारिक रूप से चल रही पूरी service count के क़रीब थी
  • जब deployment stop किसी लंबे weekend की तरह लंबा चलता, तो services लगभग एक ही समय memory खत्म करतीं, एक साथ restart होतीं, और user requests संभाल नहीं पातीं
  • कुछ servers के गिरने पर बाकी servers पर load बढ़ता, उनकी memory usage और तेज़ी से बढ़ती, और data-center स्तर पर servers गिरने की स्थिति बनती
  • इसी दौरान fleet के CPU और memory usage को घटाने वाला rightsizing काम भी चल रहा था, जिससे spare capacity कम हो चुकी थी
  • Chris और दूसरे engineers का मानना था कि बेहतर alerts, observability और resilience की ज़रूरत है
    • एक Node server runaway state में चला जाए, तब भी host process नहीं मरना चाहिए
    • सिर्फ Node process को बंद करके alert देना और फिर restart करना अधिक सुरक्षित है
    • service down होने पर client-side fetch पर fallback path भी विचार करने योग्य था

सिर्फ code review से नहीं रुकने वाला टकराव

  • outage response meetings हफ़्ते में कई बार होती थीं; उनका स्वभाव progress share करने और executives को report देने जैसा था
  • दूसरी टीम के manager ने outage response संभालते हुए अतिरिक्त लोगों को जोड़ा, और Chris ने इसे अपने तथा अपनी मूल टीम के जवाबों पर अविश्वास की दिशा के रूप में लिया
  • इस दौरान एक senior engineer ने पूछा, “code review इसे क्यों नहीं रोक सका?”
  • Chris का मानना था कि सिर्फ code review से यह सुनिश्चित नहीं किया जा सकता कि वही घटना दोबारा न हो
    • लोग गलती करते हैं
    • किसी junior engineer के लिए बहुत senior SRE के PR में configuration value वाजिब है या नहीं, इस पर सवाल उठाना कठिन होता है
    • systems को सिर्फ senior engineer के सबसे अच्छे दिन के लिए नहीं, junior engineer के बुरे दिन में भी सुरक्षित रूप से काम करना चाहिए
  • Chris के लिए software engineering में product outcomes देने वाले engineers का समर्थन करने वाला system design भी शामिल है
  • technical failures और organizational communication अलग नहीं थे; Charity Majors के शब्दों में, ऊँचे स्तर पर न पूरी तरह social और न पूरी तरह technical समस्याएँ अकेले मौजूद होती हैं

Leadership, remote culture और values conflict

  • Chris का मानना था कि उनकी टीम और उनका approach दूसरी टीम के proposal से पीछे छूट गया
  • दूसरी टीम की योजना desktop और mobile apps दोनों पर फिर से सोचने तक फैल गई और LinkedIn में product बनाने के तरीके की व्यापक समीक्षा जैसी बन गई
  • Chris उस proposal को बेहतर बनाना चाहते थे, लेकिन उन्हें लगा कि चिंताओं और सवालों को पर्याप्त रूप से नहीं सुना जा रहा था
  • उनके अनुसार एक manager ने उनसे कहा कि “तुम बहुत idealistic हो, profit and loss की पर्याप्त चिंता नहीं करते, और तुम्हें अपने values बदलने चाहिए”
  • Chris का मानना था कि remote work ने रिश्ते बनाने की क्षमता को प्रभावित किया
    • LinkedIn में in-person culture मज़बूत थी, और बहुत-से लोग cafeteria या hallways में स्वाभाविक रूप से संबंध बनाते थे
    • senior engineers और executives के साथ बार-बार physical contact टकराव की स्थितियों में फ़र्क ला सकता था
  • Chris ने पीछे मुड़कर यह भी माना कि रिश्ते बनाने में उनकी अपनी भी कमज़ोरियाँ थीं

आखिरकार छोड़ने की वजह

  • Chris का मानना था कि मौजूदा codebase की बहुत-सी समस्याएँ speed को ज़रूरत से ज़्यादा महत्व देने और secondary paths की समस्याओं को ठीक या हटाने में विफल रहने का परिणाम थीं
  • उनका निष्कर्ष था कि जब speed सबसे ऊँची value बन जाती है, तो शुरुआत में रफ़्तार मिल सकती है, लेकिन समय के साथ उसे बनाए रखना कठिन होता है
  • उन्होंने बताया कि पिछली नौकरी में वे burnout से गुज़रे थे, और उन्हें गंभीर migraine, पेट दर्द, exercise न कर पाने की स्थिति, अचानक रो पड़ना और panic attacks हुए थे
  • उनका मानना था कि अगर वे LinkedIn में बने रहते, तो हर दिन गुस्सा न होने की कोशिश करते रहना पड़ता
  • उन्होंने इसे एक विशाल संगठन की दिशा को छोटी चप्पू वाली नाव से मोड़ने जैसी स्थिति बताया, और तय किया कि वे ऐसे तरीक़े और काम पर कई साल नहीं लगाएंगे जिन पर उन्हें खुद भरोसा नहीं है
  • Chris ने कहा कि LinkedIn में उन्होंने 30 लाख lines के app, बड़े enterprise में TypeScript migration और बड़े पैमाने की engineering समस्याओं के बारे में बहुत कुछ सीखा, लेकिन अपने मूल्यों के अनुरूप काम खोजने के लिए वे वहाँ से चले गए

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

1 टिप्पणियां

 
GN⁺ 2024-03-07
Hacker News की रायें

  • मेरे हिसाब से podcast का सबसे दिलचस्प हिस्सा वह feedback था कि “आप बहुत ज़्यादा idealistic हैं, profit-loss पर पर्याप्त ध्यान नहीं देते, और आपको अपनी values बदलनी चाहिए।” पढ़ने से पहले भी मुझे ऐसा ही impression मिला था, और बीच-बीच में valuable feedback मिलने के बावजूद ऐसा लगा जैसे उसे जानबूझकर ignore किया गया हो
    Senior Staff Engineer के लिए मुश्किल चीज़ सिर्फ ‘सही होना’ नहीं, बल्कि सही समाधान की दिशा में पूरे संगठन की alignment बनाना है। 2019 में facebook.com को React में फिर से लिखने के काम में शामिल रहा था, इसलिए यह कहानी खास तौर पर दिलचस्प लगी

    • इस बात में कुछ हद तक सच्चाई है। LinkedIn में सीखे बड़े lessons में से एक यह था कि मैं organizationally पर्याप्त effective नहीं था, और developer experience team की सबसे बड़ी चुनौती यह है कि काम को business की core priorities के साथ कैसे align किया जाए
      Communication कुछ हद तक कर पाया, लेकिन LinkedIn में रहते हुए उस alignment में बहुत सफल नहीं हुआ। कुछ जिम्मेदारी मेरी है, और कुछ LinkedIn की भी है
      हालांकि इस मामले में “बहुत ज़्यादा idealistic” का मतलब सच में “जो profit-loss में सीधे योगदान नहीं देता, उसकी चिंता मत करो” था, और मैं उसे अंदर तक reject करता हूं। Profit-loss महत्वपूर्ण है, लेकिन user experience, developer experience, और हम क्या बना रहे हैं इसे लेकर basic ethics भी महत्वपूर्ण हैं
    • Senior Staff Engineer के लिए मुश्किल सिर्फ सही होना नहीं है; इसके अलावा, जिसे मैं ‘सही’ मानता हूं, वह salary देने वालों के लिए ‘सही’ से मेल न भी खा सकता है। इसे नकारना मूर्खता होगी
      किसी organization में आप जिस चीज़ को सही मानते हैं, उसके पक्ष में अपनी पूरी कोशिश से advocate करते हैं, और फिर कोई दूसरा व्यक्ति या consensus body तय करती है कि सहमत होना है या नहीं। उस नतीजे को स्वीकार करना है या compromise करना है, या फिर छोड़कर जाना है—यह फैसला मेरा होता है, और अपने career में मैंने दोनों किया है
    • बात सही भी है और नहीं भी। Staff Engineer, खासकर Senior Staff Engineer level की roles, जिस organization में जाते हैं उसके detailed context के प्रति सबसे ज़्यादा sensitive positions होती हैं, ऐसा मुझे लगता है
      एक मशहूर unicorn में एक बहुत smart, rational और kind Senior Staff Engineer था। उसने सालाना 50 मिलियन डॉलर के scale पर इस्तेमाल हो रहे framework को v2 से v3 पर ले जाने पर जोर दिया, और Python 2 से 3 पर जाने की तुलना में यह बहुत minor change था
      Investigation में मूल रूप से 10% performance improvement की उम्मीद थी, फिर भी management “version upgrade में समय बर्बाद” नहीं करना चाहता था। आखिरकार उस engineer ने अकेले push किया, एक महीने से कम समय में preview version बनाया, और दो महीने के अंदर high-impact काम का कुछ हिस्सा migrate करके अपनी salary से कई गुना ज्यादा बचत कर दी
      शुरुआती political cost और engineering cost चुकने के बाद हर कोई migrate करना चाहता था, और एक साल बाद deployment पूरा होने पर ऊपर की management structure का लगभग आधा हिस्सा layoffs और resignations में बदल चुका था, लेकिन वह engineer और migration बचे रहे। कभी-कभी Staff Engineer जिद्दी नहीं होता, बल्कि पागल दुनिया में अकेला समझदार इंसान हो सकता है
    • जो करना है वह करना ही चाहिए, लेकिन अगर breathing room और conceptual consistency हो, तो ‘alignment’ के नाम पर ऐसे sacrifices भी सामने आते हैं जिन्हें किसी भी तरह स्वीकार नहीं किया जा सकता। कई ‘सही’ solutions पर मैं सहमत होता हूं, लेकिन ऐसी situations भी होती हैं जहां समझते हुए भी कि वे core values के खिलाफ हैं, उन्हें accept नहीं किया जाता
      मैं ऐसी position में रहा हूं और participate न करने का option था, लेकिन हमेशा ऐसा कर पाना possible नहीं होता
    • सिर्फ इस context से judge करना मुश्किल है। Complex politics वाले बड़े organizations में लोग बेहतर positions पाने के लिए move करते हैं, और कभी-कभी दूसरे departments को practically hostile तरीके से take over भी कर लेते हैं
      मैंने देखा है कि best ideas या plans न होने पर भी सही connections, सही lunch meetings और सही words के जरिए management को convince कर लिया जाता है
      “तुम बहुत ज़्यादा idealistic हो और profit-loss पर पर्याप्त ध्यान नहीं देते” जैसी बात भी किसी को बाहर धकेलने के लिए लगाया गया label हो सकती है। खासकर अगर वह व्यक्ति खुद को और अपने ideas को ऊपर तक इसी तरह बेचता आया हो
      Personally, Facebook से छोटे लेकिन सैकड़ों engineers और बड़े codebase वाले organization में Ruby, Rails, Postgres से जुड़े large-scale changes and upgrades कई बार किए हैं, और Chris ने जो methodology explain की है वह बहुत reasonable है और उस तरीके से भी मेल खाती है जिसे मैंने successful महसूस किया
      मैं सहमत हूं कि leadership role प्रभावी होने के लिए trust और respect की जरूरत होती है। बेशक, वह trust useful होने के लिए वास्तव में सही भी होना चाहिए। गलत दिशा में progress, progress नहीं होती

  • मैंने LinkedIn के codebase को जाने बिना वहां काम नहीं किया है, लेकिन डरावनी हद तक मिलते-जुलते codebase और संगठनात्मक·राजनीतिक ढांचे कई बार देखे हैं। इसलिए आम तौर पर मैं finger-gun तरीका का समर्थन करता हूं
    finger-gun शैली की rewrite भी अच्छी तरह लागू की जा सकती है। अगर एक ही काम करने वाले कई clients हैं, तो उनमें से किसी एक को दूसरे platform की नींव बनाया जा सकता है, और अगर बिल्कुल नए सिरे से शुरू भी करें तो उसे साफ, तेज और संक्षिप्त रखा जा सकता है
    सफलता की कुंजी यह है कि नए system को domain expert और technical expert दोनों तरह के लोगों वाली छोटी veteran team को सौंपा जाए। यह विवादास्पद है, लेकिन मेरा मानना है कि साधारण operations maintenance समस्याओं सहित सारी सफलता यहीं से आती है। बाकी सब बस गति धीमी करता है
    ज्यादातर technology executives बार-बार जो बड़ी गलती करते हैं, वह यह है कि अगले बड़े system को सबसे कम अनुभवी लोगों के हवाले कर देते हैं। finger-gun पक्ष से कोई symmetric interview भी सुनना चाहूंगा

    • अनुभवी लोग outages का जवाब देने और operations maintenance के लिए जरूरी होते हैं, इसलिए जिन ज्यादातर जगहों पर मैंने काम किया, वहां आखिरकार सबसे कम अनुभवी लोग ही नया system बनाने लगे
    • मैं छोटी veteran team वाले तरीके के खिलाफ नहीं हूं। बस veteran team अक्सर मौजूदा concepts, tools और approaches में गहराई से invested होती है
      यह स्वाभाविक है, क्योंकि ये वही proven चीजें हैं जिनसे उन्हें पहले फायदा मिला है, लेकिन वे हमेशा सबसे अच्छी नहीं होतीं। ऊपर से, veteran team project शुरू कर भी दे तो अंत तक बनी रहे, ऐसा कम ही होता है, और अगर उन्हें नतीजों या बाद के असर को झेलना न हो तो फैसले लेना बहुत आसान हो जाता है
    • शुरू करने से पहले हर बाधा को कैसे पार करेंगे यह जानना जरूरी है, इस रवैये और यह मान लेने के बीच कि कोई बाधा है ही नहीं, निश्चित रूप से बीच का रास्ता है
      plan में बाधाओं से निपटने के realistic विकल्प होने चाहिए, और वे सिर्फ technical विकल्प नहीं, बल्कि वह काम करने वाले लोगों का समय और क्षमता भी शामिल करते हैं। उदाहरण के लिए अगर plan है कि कई teams servers operate करेंगी, तो भले ही तकनीकी रूप से संभव हो, अगर team के पास समय या क्षमता नहीं है तो वह realistic विकल्प नहीं है
      इसके उलट, हर बाधा से बचने के लिए बहुत बारीक route plan करना भी खराब है। क्योंकि जब तक आप पहुंचेंगे, बाधा खिसक चुकी हो सकती है, और रास्ते में ऐसी बाधाएं भी हो सकती हैं जिनके बारे में अभी पता ही नहीं। अगर आपने सिर्फ एक ही रास्ता plan किया है, तो वहीं रुक जाएंगे
      हालांकि अभी जो दिख रहा है वह complex architecture debate को cartoon जैसा summarize करने वाला podcast description है, इसलिए LinkedIn में असल में कौन-सी strawman logic करीब थी, यह पता नहीं चल सकता
    • मैंने ऐसे व्यक्ति से बात की थी जिसने product launch की महत्वपूर्ण तारीख पूरी करने के लिए 3–4 लोगों के साथ वह काम कर दिखाया जो company एक साल में नहीं कर पाई थी, और नतीजतन इतने ज्यादा लोगों को नाराज कर दिया कि उसे resign करना पड़ा
      कहा गया कि board ने पूरी engineering organization से कहा कि आगे किसी भी project में कोई भी किसी को details dictate नहीं कर सकता
    • लेख concrete नहीं है, इसलिए तय करना मुश्किल है कि मामला किस तरफ है, लेकिन 5-year plan वाकई बहुत खराब लगता है

  • लगता है Chris ने कुछ unfortunate choices किए। उसने 5-year plan propose किया, incident को leadership के बजाय blame की दिशा में ले गया, समस्या को solve करने से ज्यादा उसके बारे में बात की, और relationship building भी शायद कम रही
    Chris से सहानुभूति है, लेकिन ऐसा भी लगता है कि उसे इस environment में results निकालने का तरीका नहीं पता था। फिर भी यह ठीक है। हर किसी को bureaucratic knots के बीच काम करना सीखना जरूरी नहीं, और startups इस मायने में ज्यादा simple होते हैं
    बड़ी companies समय के साथ अपनी धार क्यों खो देती हैं, और कोई executive meeting room में एक भी ईमानदार VP के बिना YoY -10% loss का सामना क्यों करता है, इसकी वजह होती है

    • Chris जैसे लोगों को, और अपने जैसे लोगों को, कैसे समझना चाहिए—मैं अक्सर इस पर डगमगा जाता हूं
      ऐसी स्थिति में रहने पर मनोवैज्ञानिक रूप से direction sense खो जाता है। मुझे लगता है मैं सही हूं, लेकिन क्या सचमुच सही हूं? क्या आसपास के लोग सच में इतने अक्षम हैं, और colleagues से सीखने में उन्हें कोई दिलचस्पी नहीं?
      कुछ साल बाद जब आप छोड़कर पीछे मुड़कर देखते हैं, तो वे लोग fired हो चुके होते हैं या जा चुके होते हैं, organization अभी भी X नहीं कर पाती, और बाद में जुड़ी teams की agility और capability सच में मौजूद होती है
      एक तरफ यह arrogance, political incompetence, और pathological work culture में adapt न कर पाने की बात हो सकती है। दूसरी तरफ, शायद वही सही reaction भी हो सकता है
      अगर organization pathological culture phase से गुजर रही है, तो talent, carefulness और passion वाले लोगों का उसके कारण पागल-सा हो जाना सही भी हो सकता है। जो लोग इससे पागल नहीं होते, वे productivity और growth से असंबंधित हो सकते हैं, या इससे भी बुरा, net loss हो सकते हैं
      इसलिए ऐसा environment psychodrama बन जाता है। क्या situation सच में इतनी खराब है, या मैं overreact कर रहा हूं
    • episode में समय की वजह से कट गई nuance को थोड़ा जोड़ूं तो, 5-year plan पर “lol” कहना सही है। यह ऐसा plan था जिससे लोगों का दिल नहीं जीता जा सकता था, और यह हमारा भी सबसे नापसंद plan था
      लेकिन executives ने जब कहा कि “हमने जो migration मांगा है, उससे product iteration speed जरा भी धीमी न हो,” तो वही एकमात्र plan लगा जिसे ले जाया जा सकता था
      incident को blame की दिशा में ले गया—इससे आपका मतलब क्या है, मैं ठीक से नहीं समझता। बल्कि मैंने उल्टा करने की कोशिश की, और memory threshold कम करने वाले व्यक्ति या YAML में गलत value typo करने वाले व्यक्ति को दोष नहीं दिया। मैंने बस इस बात पर जोर दिया कि root cause को अगले व्यक्ति के हाथ फिर फटने तक न छोड़ें, बल्कि सच में solve करें
      समस्या solve करने से ज्यादा सिर्फ बात की—यह हिस्सा भी ठीक से समझ नहीं आता। broadcast में मैंने अपने किए काम का लंबा brag नहीं किया, बस इतना है; वहां solve की गई समस्याएं काफी अच्छी तरह solve हुई थीं
      relationship building की कमी, जैसा episode में भी कहा, मेरी सबसे कमजोर तरफ थी। engineers के साथ मेरे अच्छे रिश्ते थे, लेकिन खासकर ऊपर के management के साथ political trust बनाने में मैं काफी fail रहा
      फिर भी मैं इसे सिर्फ इतना नहीं मानता कि मुझे उस environment में result निकालना नहीं आता था। मुझे ऐसे तरीके दिख रहे थे जिनसे success मिल सकती थी, लेकिन मैंने यह भी चुना कि जिन तरीकों पर मेरा विश्वास नहीं, उनके अनुसार behave नहीं करूंगा। जिन engineers का मैं सम्मान करता हूं, उनमें से कई जिस काम पर विश्वास करते हैं उसके लिए political dance करते हैं, लेकिन जिस पर विश्वास नहीं करते उसके लिए ऐसा नहीं करते

  • अभी LinkedIn में काम कर रहा/रही हूँ। Chris की भूमिका और podcast शायद Ember और frontend web development से जुड़ा है, और उसने जितनी code lines और build की बात की, वह शायद LinkedIn की monolithic flagship web app voyager-web हो सकती है
    LinkedIn में ऐसे और भी systems हैं जिनमें लाखों lines of code और लंबे builds हैं। middle tier, offline data stack, metrics system, और KafkaKafkaKafka जैसी चीजें
    दुर्भाग्य से 17 मिनट का build काफ़ी अच्छा माना जाएगा। अगर अस्थायी infra outage के बिना 17 मिनट में हो जाए, तो बहुत अच्छा है

    • मैंने LinkedIn infra में काम किया था, और internal tools एक nightmare थे। Jugaad की असली परिभाषा के काफ़ी करीब
      पूरी company में testing की अवधारणा लगभग नहीं थी और QA भी नहीं था। engineers promotion material में डालने के लिए आधे-पके projects ठेलते और फिर अगले पर बढ़ जाते
      internal tools रोज़ इस्तेमाल करते हुए इतने सारे issues खुद ही हल करने पड़ते थे कि काम करने की कोशिश कर रहे engineers असल में QA बन जाते थे
    • सबसे ज़्यादा खटकता है कि इतने सारे लोग ऐसे build times को immutable value की तरह देखते हैं। build, test और run हर push पर बहुत देर लेते हैं, इसलिए इन्हें न करें—ऐसा रवैया
      इसकी जगह builds को तेज़ बनाने या build infra को और तेज़ व सस्ता बनाने की दिशा में जाना चाहिए
    • दूसरे नजरिए से, मैंने LinkedIn समेत कुछ companies में backend developer के तौर पर काम किया है, और LinkedIn की code quality शायद 70–80 percentile के आसपास लगेगी
      कम से कम जिस team में मैं था/थी, वहाँ code quality पर अच्छा-खासा ज़ोर था और culture भी लगातार बेहतर हो रहा था। हालांकि voyager पर एक काम किया था, और वह nightmare के रूप में याद है
    • LinkedIn आखिर बनना क्या चाहता है? यह 2007 के Facebook जैसा बदलता लग रहा है—क्या यह जानबूझकर है?
    • जिज्ञासा है कि codebase ऐसा क्यों हो गया। क्या platform team या developer tools team की hiring कम थी?

  • बड़े पैमाने पर rewrite manageable codebase में भी जोखिम भरा होता है, और बचा हुआ कचरा लगता है अंत तक खत्म नहीं होता। कुछ साल बाद कोने में पड़ी settings page को फिर से लिखकर कौन points कमाना चाहेगा
    ऐसी कोशिशें इतनी देखी हैं कि codebase rewrite के लिए कोई framework होना चाहिए लगता है, लेकिन है नहीं। automated code modification tools consistency मांगते हैं, लेकिन ऐसी consistency रखने वाली जगहें दुर्लभ हैं। code patterns समय के साथ इतने evolve हो जाते हैं कि tree rings देखने जैसा लगता है
    हम मूल रूप से code को boxes में रखते हैं, boxes को rearrange करते हैं, और वाजिब तौर पर कहते हैं कि कोई arrangement अधिक efficient है। फिर भी हम बेहतर तरीका क्यों नहीं खोज पाए? automation code level पर काम करता है, लेकिन box level पर नहीं

  • यह Conway’s Law के काम करने का उदाहरण है। organization नहीं बदली, इसलिए वही code soup फिर से बन जाने की संभावना है
    उसी नाव में रहा/रही हूँ, इसलिए कहूँगा/कहूँगी कि positive engineering initiatives को बहुत ऊँचे स्तर के sponsor के ज़रिए top-down आना चाहिए। नीचे से ऊपर organization को नहीं बदला जा सकता, और codebase आखिरकार organization ही बनाती है

    • top-down तरीके के अपने risks भी हैं। बड़े ideas और बड़े बदलाव तभी संभव हैं जब ऊपर sponsor, नीचे अच्छी समझ, और middle layer में पर्याप्त alignment और capability साथ हों
      Conway’s Law बदलता नहीं, लेकिन ज़रूरी नहीं कि वह सिर्फ formal org chart पर निर्भर करे। सही tech leads और सक्षम managers के बीच temporary communication structure बना दें तो इसे handle किया जा सकता है
      लेकिन बीच में कुछ technically weak या अपना kingdom बनाने वाले managers भी हों तो पूरी चीज़ आसानी से बिगड़ जाती है, और company के lifecycle के हिसाब से Pournelle’s iron law of bureaucracy की वजह से शायद पहले से ही उम्मीद खत्म हो चुकी हो
    • software पर बार-बार आने वाली सबसे बड़ी tragedy खराब leadership है। अजीब बात है कि developers लगभग हमेशा सोचते हैं कि लोगों की समस्या को बेहतर tools से ठीक किया जा सकता है
      मसलन, अगर सभी developers खराब हैं तो उन्हें कोई popular framework दे दो। यह people problems से निपटने से बचने का बहाना है, और बच्चों को daycare चलाने देने जैसा है
      अगर excellence चाहिए, तो accountability तय करके और ownership व rewards/responsibilities लागू करने वाले rules से high standards स्थापित करने होंगे। यह जटिल नहीं है, लेकिन ऊपर से दृढ़ता और conflict से न डरना चाहिए
    • अगर Conway’s Law और उसके implications में गहराई से जाना चाहते हैं, तो Casey Muratori का यह video essay ज़रूर recommend करूँगा/करूँगी: https://youtu.be/5IUj1EZwpJY?si=dPxsXieBwZsP0PPP
      हालांकि इससे Microsoft जैसी company के कुछ बनाने और फिर उसे खराब न कर देने की सारी उम्मीद खत्म हो सकती है
    • फिर भी, senior sponsor initiative पास करा दे तो भी उस process में burnout हो सकता है। मेरे साथ भी हुआ है
    • मुझे लगता है मामला और subtle है। bottom-up तरीके से भी organization बदली जा सकती है, लेकिन तब जब वह नई चीज़ हो जो exist नहीं करती या early stage में हो। existing चीज़ को बदलना top-down आने पर भी बहुत मुश्किल है

  • LinkedIn में 12 साल बिताए। दुख की बात है कि यह पुराने engineering organization से बहुत दूर है। जब Kevin Scott engineering lead कर रहे थे, वह दौर तुलना में सचमुच अच्छा था

    • इस scale की companies के engineers सभी वही बात कहते हैं। मुझे लगता है यह किसी खास culture की वजह से नहीं, बल्कि engineering team की growth किसी भी culture को खराब करने की दिशा में जाती है
    • Ryan Rolansky ने कहा था कि LinkedIn मूल रूप से feature-complete स्थिति में है

  • JavaScript की लाखों लाइनों का होना अपने-आप में फूलाव का साक्षात रूप है
    मैं LinkedIn जैसी चीज़ को फिर से implement करने, या सही कहें तो “Facebook-जैसे” features के बिना अपना contacts database बनाने के बारे में सोचता रहा हूं
    समस्या यह है कि मैं अपने contacts को बड़े पैमाने पर वहां कैसे ले आऊं। फूलाव से अलग, Microsoft LinkedIn की मुख्य समस्या यह है कि वह contact जानकारी export करने नहीं देता, और contacts platform के लिए यह जरूरी feature होना चाहिए

    • Platform lock-in साफ तौर पर जानबूझकर किया गया है। Users के लिए अच्छा नहीं है
    • LinkedIn मूल रूप से Ruby में बना था और code 60,000 lines का था
      https://queue.acm.org/detail.cfm?id=2567673
      सारांश: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
      LinkedIn ने 2010 की शुरुआत में Node पर migration किया था
    • सुनने में अजीब लग सकता है, लेकिन वह संख्या मुझे चौंकाने वाली नहीं लगी। पहले एक बड़े bank में consumer-facing JavaScript web app पर काम किया था, जिसका code 60 लाख lines का था
      हालांकि इस thread की प्रतिक्रियाएं देखकर लग रहा है कि शायद वह संख्या गलत थी
    • Contacts पाने के लिए क्या आपने कभी browser में आने वाले web server responses से सीधे JSON scrape किया है?
      LinkedIn पर तो मैंने नहीं किया, लेकिन public website पर डाली गई conference attendee list export करने के लिए मैं यही गंदी-सी trick इस्तेमाल करता हूं। स्थिति के हिसाब से अलग हो सकता है

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

    • मुझे Adam भी बेहतरीन host लगता है। अच्छे सवाल पूछते हैं और guest को बोलने देते हैं
    • निजी तौर पर, वे ऐसे इंसान लगते हैं जिनके साथ मैं काम करना चाहूंगा

  • यह लगभग हमेशा मुश्किल रहने वाली soft leadership role जैसी लगती है। ऐसी position जहां किसी चीज़ की “जिम्मेदारी” तो होती है, लेकिन संगठन के बाकी हिस्से पर अधिकार बहुत कम या बिल्कुल नहीं होता
    अगर असली technical leadership है भी, तो वह शायद गायब है, या बहुत लंबे समय से वहीं है और “systems expert” होने के बावजूद अब वास्तविक समस्याओं से जुड़ी नहीं रह गई है। यह झेल चुका हूं, और दोबारा नहीं चाहिए