Dejando LinkedIn

Artículo original ↗ Discusión en Hacker News ↗

El testimonio de un ingeniero de larga trayectoria sobre su salida de LinkedIn tras un intento fallido de modernizar su enorme base de código frontend ha provocado un escrutinio más amplio sobre cómo las grandes organizaciones tecnológicas manejan la arquitectura, la deuda técnica y los incentivos. Los comentaristas contraponen migraciones incrementales y cuidadosamente planificadas con reescrituras “finger gun” impulsadas por el entusiasmo y la presión ejecutiva, y sostienen que la ley de Conway, los sistemas de promoción y las culturas guiadas por el miedo a menudo condenan los grandes refactors. Muchos también apuntan a la experiencia de usuario lenta y sobrecargada de LinkedIn y al despliegue agresivo de funciones/IA como síntomas de una cultura de ingeniería que recompensa las novedades visibles por encima del mantenimiento, la calidad del código y la experiencia del desarrollador.

Tamaño, complejidad y rendimiento de la base de código

  • El citado frontend de ~2M de líneas no sorprende a quienes están acostumbrados a aplicaciones grandes; otros lo ven como evidencia de hinchazón.
  • Las explicaciones ofrecidas: muchas funciones a lo largo de muchos años, verbosidad de JS/HTML/CSS, “hinchazón generacional” en la que los nuevos desarrolladores solo añaden código, múltiples sistemas de UI superpuestos y código de seguimiento/analítica.
  • Varios sostienen que las LOC son una mala métrica; lo que importa es cuánto código tienen que tocar los ingenieros y si los límites son sensatos.
  • Los usuarios describen LinkedIn como lento y pesado para la CPU, con cargas de página largas, mensajería con lag, comportamiento roto del botón de atrás y malas alertas de búsqueda/ofertas de trabajo. Las notificaciones se consideran ampliamente spam y manipuladoras.

Tiempos de compilación y herramientas

  • Una compilación de 17 minutos para la aplicación web monolítica divide opiniones: algunos la ven aceptable para esa escala, otros claramente demasiado lenta.
  • Muchos subrayan que la latencia de las compilaciones incrementales es la métrica clave; las compilaciones completas desde cero pueden cachearse o descargarse a otro lugar.
  • Mejoras sugeridas: mejor estructura de proyecto, sistemas de compilación herméticos, paralelismo y caché en la nube, aunque esos esfuerzos requieren una inversión organizativa sostenida que es difícil de justificar y mantener.

Ley de Conway, estructura organizativa y cambio

  • Una discusión extensa conecta la base de código desordenada con la Ley de Conway y su “pesadilla” con el tiempo: el software reflejando no un organigrama, sino capas de reorganizaciones, fusiones e historia.
  • Algunos dicen que el cambio técnico a gran escala solo funciona con un fuerte patrocinador de arriba abajo; otros relatan raros éxitos de abajo arriba, por lo general anclados en métricas que interesan a las partes externas.
  • Hay desacuerdo sobre cuán “ley” es la Ley de Conway, pero existe amplio consenso en que la estructura de comunicación moldea fuertemente el diseño del sistema y que cambiar el comportamiento organizativo es más difícil que cambiar el código.

Migración vs. gran reescritura (“finger guns”)

  • El pódcast contrapone una migración incremental cautelosa de varios años con un plan entusiasta de reescritura desde cero.
  • Los comentaristas señalan que los planes largos y cuidadosos de infraestructura son políticamente más difíciles de financiar que las reescrituras vistosas que se venden como rápidas pero se alargan durante años y dejan restos heredados.
  • Muchos respaldan equipos pequeños de veteranos para nuevos sistemas, pero advierten sobre el Second System Syndrome, la sobrearquitectura y la falta de incentivos para el mantenimiento.

Rol de ingenieros senior/staff y política

  • Fuerte hilo sobre cómo “tener razón” técnicamente es insuficiente en niveles senior; el trabajo real es la alineación, las relaciones y vincular el trabajo con el negocio.
  • Algunos ven al protagonista como idealista pero políticamente ineficaz; otros argumentan que negarse a optimizar solo para el “resultado final” es una elección de valores razonable en un entorno disfuncional.

Cultura, incentivos y calidad interna

  • Varios empleados actuales y anteriores describen herramientas internas frágiles, rutas largas de compilación y despliegue, QA mínima y sistemas de promoción que recompensan las funciones visibles por encima de la limpieza.
  • Otros dicen que, en comparación con la industria, la calidad del código backend de LinkedIn está en la franja media-alta, con el dolor concentrado en particular en el frontend web insignia.