Leaving LinkedIn
A long-time engineer’s account of leaving LinkedIn over a failed attempt to modernize its massive frontend codebase has prompted wider scrutiny of how big tech organizations handle architecture, technical debt, and incentives. Commenters contrast incremental, carefully planned migrations with “finger gun” rewrites driven by enthusiasm and executive pressure, arguing that Conway’s law, promotion systems, and fear-driven cultures often doom large-scale refactors. Many also point to LinkedIn’s sluggish, overloaded user experience and aggressive feature/AI rollout as symptoms of an engineering culture that rewards visible new features over maintenance, code quality, and developer experience.
Codebase size, complexity, and performance
- The cited ~2M‑line frontend doesn’t shock people used to large apps; others see it as evidence of bloat.
- Explanations offered: many features over many years, JS/HTML/CSS verbosity, “generational bloat” where new devs only add code, multiple overlapping UI systems, and tracking/analytics code.
- Several argue LOC is a poor metric; what matters is how much code engineers must touch and whether boundaries are sane.
- Users report LinkedIn as slow and CPU‑heavy, with long page loads, laggy messaging, broken back‑button behavior, and poor search/job alerts. Notifications are widely seen as spammy and manipulative.
Build times and tooling
- A 17‑minute build for the monolithic web app divides opinion: some see it as acceptable at that scale, others as clearly too slow.
- Many stress incremental build latency is the key metric; full clean builds can be cached or offloaded.
- Suggested improvements: better project structure, hermetic build systems, parallelism, and cloud caching—though such efforts require sustained org investment that’s hard to justify and maintain.
Conway’s Law, org structure, and change
- Extensive discussion connects the messy codebase to Conway’s Law and its “nightmare” over time: software reflecting not one org chart but layers of reorganizations, mergers, and history.
- Some say large‑scale technical change only works with a strong top‑down champion; others recount rare bottom‑up successes, usually anchored by metrics external stakeholders care about.
- There’s disagreement on how “law‑like” Conway’s Law is, but broad agreement that communication structure heavily shapes system design and that changing org behavior is harder than changing code.
Migration vs. big rewrite (“finger guns”)
- The podcast contrasts a cautious multi‑year incremental migration with an enthusiastic rewrite‑from‑scratch plan.
- Commenters note that long, careful infra plans are politically harder to fund than flashy rewrites that are sold as quick but drag on for years and leave legacy remnants.
- Many endorse small veteran teams for new systems, but warn about Second System Syndrome, over‑architecture, and lack of incentives for maintenance.
Role of senior/staff engineers and politics
- Strong thread on how being “right” technically is insufficient at senior levels; the real work is alignment, relationships, and tying work to the business.
- Some see the protagonist as idealistic but politically ineffective; others argue that refusing to optimize solely for the “bottom line” is a reasonable values choice in a dysfunctional environment.
Culture, incentives, and internal quality
- Multiple current/former employees describe brittle internal tooling, long build and deployment paths, minimal QA, and promotion systems rewarding visible features over cleanup.
- Others say, relative to industry, LinkedIn’s backend code quality is mid‑to‑high tier, with particular pain concentrated in the flagship web frontend.