Saindo do LinkedIn

Artigo original ↗ Discussão no Hacker News ↗

O relato de um engenheiro de longa data sobre sua saída do LinkedIn após uma tentativa malsucedida de modernizar a enorme base de código do frontend provocou um escrutínio mais amplo sobre como grandes organizações de tecnologia lidam com arquitetura, dívida técnica e incentivos. Comentadores contrastam migrações incrementais e cuidadosamente planejadas com reescritas “finger gun” impulsionadas por entusiasmo e pressão executiva, argumentando que a lei de Conway, os sistemas de promoção e culturas movidas pelo medo muitas vezes condenam grandes refatorações. Muitos também apontam a experiência de usuário lenta e sobrecarregada do LinkedIn e a agressiva implementação de recursos/IA como sintomas de uma cultura de engenharia que recompensa novos recursos visíveis em vez de manutenção, qualidade de código e experiência do desenvolvedor.

Tamanho da base de código, complexidade e desempenho

  • O frontend citado, com ~2 milhões de linhas, não choca pessoas acostumadas a apps grandes; outros veem isso como evidência de inchaço.
  • Explicações oferecidas: muitos recursos ao longo de muitos anos, verbosidade de JS/HTML/CSS, “inchaço geracional” em que novos devs só adicionam código, múltiplos sistemas de UI sobrepostos e código de rastreamento/analytics.
  • Vários argumentam que LOC é uma métrica ruim; o que importa é quanto código os engenheiros precisam tocar e se as fronteiras são sensatas.
  • Usuários relatam o LinkedIn como lento e pesado em CPU, com carregamentos longos de página, mensagens com lag, comportamento quebrado do botão voltar e busca/alertas de vagas ruins. As notificações são amplamente vistas como spam e manipuladoras.

Tempos de build e ferramentas

  • Um build de 17 minutos para o app web monolítico divide opiniões: alguns acham aceitável para esse porte, outros claramente lento demais.
  • Muitos enfatizam que a latência do build incremental é a métrica-chave; builds completos e limpos podem ser cacheados ou terceirizados.
  • Melhorias sugeridas: melhor estrutura de projeto, sistemas de build herméticos, paralelismo e cache na nuvem — embora esse tipo de esforço exija investimento organizacional sustentado, difícil de justificar e manter.

Lei de Conway, estrutura organizacional e mudança

  • Uma discussão extensa conecta a base de código confusa à Lei de Conway e ao seu “pesadelo” ao longo do tempo: software refletindo não um organograma, mas camadas de reorganizações, fusões e história.
  • Alguns dizem que mudanças técnicas em grande escala só funcionam com um forte defensor no topo; outros relatam raros sucessos de baixo para cima, geralmente ancorados em métricas com as quais partes interessadas externas se importam.
  • Há discordância sobre quão “lei” a Lei de Conway realmente é, mas há amplo consenso de que a estrutura de comunicação molda fortemente o design do sistema e que mudar o comportamento da organização é mais difícil do que mudar o código.

Migração vs. grande reescrita (“finger guns”)

  • O podcast contrasta uma migração incremental cautelosa, de vários anos, com um plano entusiasmado de reescrever tudo do zero.
  • Comentadores observam que planos longos e cuidadosos de infraestrutura são politicamente mais difíceis de financiar do que reescritas chamativas vendidas como rápidas, mas que se arrastam por anos e deixam remanescentes legados.
  • Muitos endossam pequenas equipes veteranas para novos sistemas, mas alertam para o Second System Syndrome, over-architecture e falta de incentivos para manutenção.

Papel de engenheiros sêniores/staff e política

  • Forte linha de discussão sobre como estar “certo” tecnicamente é insuficiente em níveis seniores; o trabalho real é alinhamento, relações e vincular o trabalho ao negócio.
  • Alguns veem o protagonista como idealista, mas politicamente ineficaz; outros argumentam que se recusar a otimizar apenas para o “resultado final” é uma escolha de valores razoável em um ambiente disfuncional.

Cultura, incentivos e qualidade interna

  • Vários empregados atuais/ex-funcionários descrevem ferramentas internas frágeis, caminhos longos de build e deploy, QA mínimo e sistemas de promoção que recompensam recursos visíveis em vez de limpeza.
  • Outros dizem que, em comparação com o setor, a qualidade do código do backend do LinkedIn está entre mediana e alta, com a dor concentrada em particular no frontend web principal.