Ao deixar o LinkedIn

• O que você escolhe quando fazer o trabalho direito entra em conflito com a velocidade acelerada da empresa?
• A história do engenheiro Chris Krycho, que escolheu a segunda opção entre manter suas convicções e fazer concessões ou partir em busca de um trabalho alinhado a seus princípios
• No fim, Chris deixou o LinkedIn para buscar um trabalho que estivesse de acordo com seus princípios
• Um resumo do que ele contou no podcast
• A história dele destaca a tensão entre a "necessidade de inovar" e a "importância da saúde do projeto"

O primeiro dia de Chris Krycho no LinkedIn

• Chris entrou no LinkedIn no fim de janeiro de 2019. Passou por vários processos de onboarding comuns em grandes empresas ou em pequenas empresas saudáveis.
• Chris trabalharia remotamente do Colorado, mas passou as duas primeiras semanas no onboarding e com a equipe.

Milhões de linhas de código

• Em comparação com sua experiência na empresa anterior, ele ficou muito surpreso com a escala do app cliente de frontend e dos serviços de backend do LinkedIn.
• O frontend do LinkedIn tinha 2 milhões de linhas, muito mais do que todo o código de sua empresa anterior.

Equipe de infraestrutura

• O papel de Chris era na equipe de infraestrutura, com foco não em montar servidores, mas em suporte de engenharia ou melhoria da experiência do desenvolvedor.
• O objetivo era facilitar o trabalho com o enorme app desktop do LinkedIn.

Modernização do JavaScript

• Ele participou do trabalho de modernização do código com a introdução de classes JavaScript. Aprendeu muito no processo de resolver os problemas que surgiam ao usar o framework Ember.
• Percebeu que o trabalho de migração em uma base de código desse porte precisava ser automatizado ao máximo, pois o volume era grande demais para ser tratado manualmente.

Adoção do TypeScript

• Foi decidida a migração para TypeScript para reduzir os erros que ocorriam no frontend.
• O TypeScript pode ser adotado de forma gradual, o que oferecia a escalabilidade de que o LinkedIn precisava.

Plano de migração lenta vs. o 'Finger Gun's Plan'

• Chris e sua equipe propuseram um plano de 3 a 5 anos para migrar o código em Ember para React, mas outra equipe apresentou o 'Finger Gun's Plan', prometendo uma reformulação geral e alta velocidade.
• Essa diferença de abordagem refletia o conflito entre os problemas enfrentados por Chris e sua equipe e uma cultura empresarial que priorizava a velocidade.

As experiências e aprendizados de Chris

• Reconhecimento do problema de alertas insuficientes.
• Os servidores de todo o data center caíram por causa de uma reação em cadeia provocada pelo aumento no uso de memória e reinicializações de servidores.
• Tentaram resolver o problema por meio de reset do sistema e ajustes de permissões.
• Falhas são inevitáveis, e engenharia de software consiste em projetar sistemas que deem suporte ao processo pelo qual engenheiros produzem resultados de produto.
• Ênfase na necessidade de sistemas com resiliência em múltiplas camadas.

Reação ao incidente

• Surgiu insatisfação durante a resolução do problema por causa da falta de confiança da gestão.
• Houve divergências com engenheiros seniores e problemas de comunicação.
• Destacou-se que o sistema não deve funcionar apenas em seu melhor estado, mas ser capaz de oferecer suporte em qualquer situação.

Aumento da pressão

• Apesar dos esforços para resolver dívida técnica e melhorar a resiliência, a insatisfação da liderança aumentou.
• Houve conflito com gestores que exigiam soluções simples para problemas complexos.

Reorganização

• Reorganização causada pela 'equipe finger guns' e mudanças de papel.
• Reconhecimento de novas experiências e oportunidades de aprendizado em outros papéis.

Reflexão e tomada de consciência

• Autorreflexão por meio das experiências passadas e da situação atual.
• Reconhecimento da importância de construir relações humanas e da comunicação.
• Entendimento de que problemas técnicos e sociais estão interligados.

Conclusão e lições

• Chris manteve uma visão crítica sobre uma cultura que coloca a velocidade como valor supremo.
• Buscou novas oportunidades ao refletir sobre carreira e valores pessoais.
• A jornada de Chris para encontrar um papel voltado à excelência em engenharia continua.

Opinião do GN⁺

• A experiência de Chris Krycho mostra bem o conflito entre princípios técnicos e exigências de negócio.
• A decisão dele destaca a importância de encontrar equilíbrio entre valores pessoais e escolhas profissionais.
• Gerenciar mudanças em um ambiente tecnológico de grande escala como o do LinkedIn é algo complexo, e isso também oferece lições importantes para outras empresas.
• A adoção de tecnologias como TypeScript pode ajudar a melhorar a qualidade do código e reduzir erros, mas em bases de código muito grandes é necessária uma abordagem gradual.
• Ao promover mudanças técnicas como essas, é preciso considerar o equilíbrio entre experiência do desenvolvedor e velocidade de lançamento do produto.

[GN⁺]

Comentários do Hacker News

• Em uma conversa com um gestor, ele teria ouvido: 'você é idealista demais, não dá importância suficiente ao lucro e precisa mudar seus valores'. Ele expressou rejeição a isso e afirmou sua intenção de manter seus próprios valores. Dizem que essa foi a parte mais interessante do podcast, e o autor comentou que isso lhe passou a impressão de que ele ignorou deliberadamente um feedback importante. A lição aprendida na carreira é que o difícil não é saber o que é certo, mas conseguir o alinhamento de toda a organização em torno da solução correta.

  • Um caso de choque de valores em uma conversa com um gestor
  • A impressão de que um feedback importante foi ignorado deliberadamente
  • A lição de que o alinhamento de toda a organização em torno da solução correta é o mais importante

• Em 2019, participei do trabalho de reescrever facebook.com em React. Não conheço diretamente o codebase nem a organização do LinkedIn, mas já vi empresas com estruturas organizacionais e codebases semelhantes. Sou favorável à abordagem de "finger gun", que, quando bem executada, pode trazer resultados positivos. Quando vários clientes tentam fazer o mesmo trabalho, é possível usar um como base para atender outras plataformas. Ou, ao começar do zero, dá para fazer de um jeito limpo, rápido e conciso. Um elemento comum de sucesso é uma pequena equipe veterana construindo o novo sistema, e acredito que o sucesso vem de pequenos times de engenharia que combinam especialistas de domínio com especialistas técnicos. Um grande problema recorrente na gestão técnica é que as pessoas menos experientes acabam construindo o próximo grande sistema.

  • Compartilhamento de experiência com reescrita para React
  • Ênfase na abordagem de "finger gun" e na importância de pequenos times veteranos
  • Aponta o problema de pessoas menos experientes construindo grandes sistemas

• Grandes reescritas são arriscadas mesmo em codebases gerenciáveis, e os problemas remanescentes nunca desaparecem por completo. Quem vai querer reescrever aquela página de configurações escondida depois de alguns anos? Seria ótimo se existisse um framework para reescrever codebases, mas na prática não existe. Codemods automatizados exigem consistência, e isso raramente é seguido. Como os padrões de código mudaram muito ao longo do tempo, é como olhar os anéis de crescimento de uma árvore. Você coloca o código em caixas e o reorganiza, mas a automação não acontece no nível das caixas.

  • Os riscos da reescrita de codebases e os problemas remanescentes
  • A ausência de um framework para reescrita de código
  • A lacuna entre automação no nível do código e no nível das caixas

• Trabalho atualmente no LinkedIn, e acho que o papel do Chris mencionado no podcast e o desenvolvimento web frontend estão relacionados ao ember. Parece que ele está falando do voyager-web, o aplicativo web principal e monolítico do LinkedIn. Além do voyager-web, o LinkedIn também tem muitos outros sistemas com milhões de linhas de código e tempos de build longos. Por exemplo, a camada intermediária, a stack de dados offline, o sistema de métricas, Kafka etc. Um build de 17 minutos é até bem bom; se são 17 minutos sem falhas transitórias de infraestrutura, então é muito bom.

  • Compartilhamento de experiência de trabalho atual no LinkedIn
  • Explicação sobre vários sistemas e tempos de build
  • Avaliação do build de 17 minutos

• Centenas de milhares de linhas de JavaScript significam volume excessivo. Isso me fez pensar em reimplementar um serviço como o LinkedIn ou criar meu próprio banco de dados de contatos. O problema é como migrar contatos em massa. Um dos principais problemas do Microsoft LinkedIn é que não é possível exportar as informações de contato, e essa é uma funcionalidade essencial em uma plataforma de contatos.

  • Aponta o volume excessivo de código JavaScript
  • A dificuldade de migrar informações de contato
  • A importância da função de exportar informações de contato

• Passei 12 anos no LinkedIn, mas agora ele está bem distante da organização de engenharia de antigamente. Avalio que a época em que Kevin Scott liderava a engenharia era muito melhor.

  • Experiência de longa duração trabalhando no LinkedIn
  • Diferenças entre a organização de engenharia do passado e a atual

• É uma situação em que a Lei de Conway está em ação. A menos que a organização mude, ela vai recriar a mesma bagunça no código. Iniciativas positivas de engenharia precisam vir de cima para baixo e exigem apoio de pessoas em cargos muito altos. É impossível mudar a organização de baixo para cima; a organização produz o codebase.

  • Possibilidade de repetição da bagunça no código sem mudança organizacional
  • Necessidade de iniciativas positivas de engenharia vindas da liderança

• Fiquei profundamente impressionado com a forma como Chris Krycho falou honestamente sobre suas dificuldades sem transformar isso em um jogo de culpas. CoRecursive é um dos podcasts de que mais gosto, por explorar o contexto complexo por trás do código.

  • A atitude sincera de Chris Krycho e sua recusa em culpar os outros
  • Avaliação positiva do podcast CoRecursive

• A migração de Ember para React parece um caso adequado para uma tecnologia criada por um cliente com quem trabalhei antes. Ele criou uma linguagem chamada "Unhack" para permitir busca e substituição no nível de AST. Usava-se uma linguagem em que você especificava um padrão no código original e outro padrão para substituí-lo. Como parei de trabalhar com esse cliente há alguns anos, não sei se isso ainda existe hoje.

  • Um caso de migração tecnológica de Ember para React
  • A linguagem "Unhack", que permite busca e substituição no nível de AST

• Que o codebase do LinkedIn é bagunçado não surpreende quem usa o site. Você clica em uma postagem interessante, tenta descobrir mais sobre quem escreveu e depois aperta voltar, mas o feed é recarregado e você perde a postagem. Se você tenta rolar as mensagens recebidas, a página inteira fica lenta e leva de 10 a 15 segundos para registrar a digitação. Por que recebo 30 notificações falsas? São notificações falsas criadas para forçar engajamento das pessoas. O algoritmo de recomendação também é absolutamente horrível.

  • Dificuldades no uso do site do LinkedIn
  • Notificações falsas e lentidão na resposta da página
  • Críticas ao algoritmo de recomendação