LinkedIn छोड़ना
एक लंबे समय से जुड़े engineer का LinkedIn छोड़ने का विवरण—जिसमें उसके विशाल frontend codebase को आधुनिक बनाने का असफल प्रयास शामिल है—बड़े tech संगठनों के architecture, technical debt, और incentives को संभालने के तरीके पर व्यापक scrutiny का कारण बना है। टिप्पणीकार incremental, सावधानी से planned migrations की तुलना “finger gun” rewrites से करते हैं, जो उत्साह और executive pressure से प्रेरित होती हैं, और तर्क देते हैं कि Conway’s law, promotion systems, और fear-driven cultures अक्सर बड़े refactors को विफल कर देते हैं। कई लोग LinkedIn के धीमे, overloaded user experience और aggressive feature/AI rollout को ऐसी engineering culture के लक्षण मानते हैं जो maintenance, code quality, और developer experience की बजाय दिखाई देने वाली नई features को reward करती है.
कोडबेस का आकार, जटिलता, और प्रदर्शन
- उद्धृत ~2M‑लाइन फ्रंटएंड उन लोगों को चौंकाता नहीं जो बड़े ऐप्स के आदी हैं; अन्य इसे फालतूपन का सबूत मानते हैं।
- दिए गए कारण: कई वर्षों में जोड़ी गई कई सुविधाएँ, JS/HTML/CSS की verbosity, “generational bloat” जहाँ नए डेवलपर सिर्फ कोड जोड़ते जाते हैं, कई ओवरलैप होती UI प्रणालियाँ, और tracking/analytics कोड।
- कई लोगों का तर्क है कि LOC एक खराब मीट्रिक है; असल में महत्वपूर्ण यह है कि इंजीनियरों को कितना कोड छूना पड़ता है और सीमाएँ कितनी समझदारीपूर्ण हैं।
- उपयोगकर्ता LinkedIn को धीमा और CPU‑भारी बताते हैं, जिसमें लंबे page loads, laggy messaging, broken back-button behavior, और खराब search/job alerts शामिल हैं। Notifications को व्यापक रूप से spammy और manipulative माना जाता है।
Build times और tooling
- मोनोलिथिक web app के लिए 17‑minute build पर राय बँटी हुई है: कुछ इसे उस पैमाने पर स्वीकार्य मानते हैं, अन्य इसे स्पष्ट रूप से बहुत धीमा कहते हैं।
- कई लोग ज़ोर देते हैं कि incremental build latency मुख्य मीट्रिक है; full clean builds को cached किया जा सकता है या offload किया जा सकता है।
- सुझाए गए सुधार: बेहतर project structure, hermetic build systems, parallelism, और cloud caching—हालाँकि ऐसे प्रयासों के लिए लगातार संगठनात्मक निवेश चाहिए, जिसे उचित ठहराना और बनाए रखना कठिन है।
Conway’s Law, संगठनात्मक संरचना, और बदलाव
- व्यापक चर्चा messy codebase को Conway’s Law और समय के साथ उसके “nightmare” से जोड़ती है: software किसी एक org chart को नहीं, बल्कि reorganizations, mergers, और इतिहास की परतों को दर्शाता है।
- कुछ लोग कहते हैं कि बड़े पैमाने पर तकनीकी बदलाव तभी काम करता है जब ऊपर से एक मज़बूत champion हो; अन्य लोग दुर्लभ bottom-up सफलताओं का वर्णन करते हैं, जो आमतौर पर उन metrics पर टिके होते हैं जिनकी external stakeholders को परवाह होती है।
- इस पर असहमति है कि Conway’s Law कितना “law-like” है, लेकिन इस पर व्यापक सहमति है कि communication structure सिस्टम डिज़ाइन को गहराई से आकार देता है और संगठनात्मक व्यवहार बदलना code बदलने से भी कठिन है।
Migration बनाम बड़ा rewrite (“finger guns”)
- podcast एक सावधान, multi-year incremental migration की तुलना एक उत्साही rewrite-from-scratch योजना से करता है।
- टिप्पणीकारों का कहना है कि लंबे, सावधानीपूर्वक infra plans को politically fund करना flashy rewrites की तुलना में कठिन है, जिन्हें जल्दी का वादा करके बेचा जाता है लेकिन जो वर्षों तक खिंचते हैं और legacy अवशेष छोड़ जाते हैं।
- कई लोग नए systems के लिए छोटे veteran teams का समर्थन करते हैं, लेकिन Second System Syndrome, over-architecture, और maintenance के लिए incentives की कमी को लेकर चेतावनी भी देते हैं।
Senior/staff engineers की भूमिका और राजनीति
- इस पर एक मजबूत धागा है कि senior स्तरों पर तकनीकी रूप से “सही” होना पर्याप्त नहीं है; असली काम alignment, relationships, और काम को business से जोड़ना है।
- कुछ लोग protagonist को आदर्शवादी लेकिन राजनीतिक रूप से अप्रभावी मानते हैं; अन्य तर्क देते हैं कि केवल “bottom line” के लिए optimize करने से इनकार करना dysfunctional environment में एक उचित values choice है।
संस्कृति, incentives, और internal quality
- कई current/former employees brittle internal tooling, लंबे build और deployment paths, minimal QA, और promotion systems का वर्णन करते हैं जो cleanup की बजाय visible features को reward करते हैं।
- अन्य लोग कहते हैं कि उद्योग की तुलना में LinkedIn का backend code quality mid‑to‑high tier है, जबकि विशेष दर्द flagship web frontend में केंद्रित है।