Al dejar LinkedIn

• Cuando hacer bien el trabajo choca con la rapidez de una empresa, ¿qué eliges tú?
• La historia del ingeniero Chris Krycho, quien eligió lo segundo entre mantenerse fiel a sus convicciones y ceder, o irse para buscar un trabajo alineado con sus principios.
• Chris finalmente dejó LinkedIn para perseguir un trabajo que estuviera en sintonía con sus propios principios.
• Un resumen de lo que contó en el pódcast.
• Su historia subraya la tensión entre la "necesidad de innovar" y la "importancia de la salud del proyecto".

El primer día de Chris Krycho en LinkedIn

• Chris se unió a LinkedIn a finales de enero de 2019. Pasó por varios procesos de onboarding comunes en grandes empresas o en pequeñas compañías saludables.
• Aunque iba a trabajar de forma remota desde Colorado, pasó las primeras dos semanas en onboarding y conviviendo con su equipo.

Millones de líneas de código

• En comparación con su experiencia en su empresa anterior, quedó muy sorprendido por la escala de la app cliente de frontend y los servicios backend de LinkedIn.
• El frontend de LinkedIn alcanza los 2 millones de líneas, muchísimo más que todo el código de su empresa anterior.

El equipo de infraestructura

• El rol de Chris estaba en el equipo de infraestructura, pero no enfocado en construir servidores, sino en apoyar la ingeniería o mejorar la experiencia de desarrollador.
• El objetivo era facilitar el trabajo sobre la enorme app de escritorio de LinkedIn.

Modernización de JavaScript

• Participó en el trabajo de modernizar el código mediante la introducción de clases de JavaScript. Aprendió mucho mientras resolvía problemas derivados del uso del framework Ember.
• Se dio cuenta de que las migraciones en una base de código enorme debían automatizarse tanto como fuera posible, ya que la carga de trabajo era demasiado grande para hacerla manualmente.

Adopción de TypeScript

• Se decidió avanzar hacia TypeScript para reducir los errores que ocurrían en el frontend.
• TypeScript puede adoptarse de manera gradual, lo que ofrece la escalabilidad que LinkedIn necesitaba.

El plan de migración lenta vs. el 'Finger Gun's Plan'

• Chris y su equipo propusieron un plan de 3 a 5 años para migrar el código de Ember a React, pero otro equipo presentó el 'Finger Gun's Plan', que prometía un replanteamiento total y mayor velocidad.
• La diferencia entre estos enfoques refleja el conflicto entre los problemas que Chris y su equipo estaban enfrentando y una cultura corporativa que priorizaba la velocidad.

La experiencia y los aprendizajes de Chris

• Reconocimiento del problema de alertas insuficientes.
• Los servidores de todo el centro de datos se cayeron debido a una reacción en cadena causada por el aumento en el uso de memoria y los reinicios de servidores.
• Intentó resolver el problema mediante el restablecimiento del sistema y el ajuste de permisos.
• El fracaso es inevitable, y la ingeniería de software consiste en diseñar sistemas que apoyen el proceso mediante el cual los ingenieros producen resultados en producto.
• Subraya la necesidad de sistemas con resiliencia en múltiples capas.

Reacción negativa al incidente

• Surgió frustración por la falta de confianza de la gerencia durante el proceso de resolución del problema.
• Hubo desacuerdos y problemas de comunicación con ingenieros de alto nivel.
• Recalcó que un sistema no debe funcionar solo en su mejor estado, sino que debe poder responder en cualquier situación.

Aumento de la presión

• A pesar de los esfuerzos por resolver la deuda técnica y mejorar la resiliencia, aumentó el descontento de la dirección.
• Surgieron choques con directivos que exigían soluciones simples para problemas complejos.

Reorganización

• Hubo una reorganización y cambios de rol a causa del 'Finger Guns Team'.
• También reconoció nuevas experiencias y oportunidades de aprendizaje en otros roles.

Reflexión y toma de conciencia

• Reflexión personal a partir de experiencias pasadas y de la situación actual.
• Reconocimiento de la importancia de construir relaciones humanas y comunicarse.
• Comprensión de que los problemas técnicos y los problemas sociales están conectados entre sí.

Conclusión y lecciones

• Chris mantuvo una mirada crítica sobre una cultura que pone la velocidad como valor supremo.
• Buscó nuevas oportunidades a partir de una reflexión sobre su carrera y sus valores personales.
• El camino de Chris para encontrar un rol donde pudiera perseguir la excelencia en ingeniería continúa.

La opinión de GN⁺

• La experiencia de Chris Krycho muestra muy bien el conflicto entre los principios técnicos y las exigencias del negocio.
• Su decisión resalta la importancia de encontrar un equilibrio entre los valores personales y las decisiones profesionales.
• Gestionar cambios en un entorno tecnológico de gran escala como LinkedIn es complejo, y deja lecciones importantes para otras empresas.
• La adopción de tecnologías como TypeScript puede ayudar a mejorar la calidad del código y reducir errores, pero en bases de código grandes se necesita un enfoque gradual.
• Al impulsar este tipo de cambios técnicos, hay que considerar el equilibrio entre la experiencia de desarrollador y la velocidad de lanzamiento del producto.

[GN⁺]

Opiniones de Hacker News

• Cuenta que, en una conversación con un gerente, le dijeron: "eres idealista, no le das suficiente importancia a los ingresos y necesitas cambiar tus valores". Él expresó su rechazo a eso y dejó clara su intención de mantenerse fiel a sus principios. Dice que esa fue la parte más interesante del pódcast, y que le dio la impresión de que el autor estaba ignorando deliberadamente un feedback importante. La lección aprendida en su carrera es que el verdadero problema no es saber qué es lo correcto, sino lograr la alineación de toda la organización en torno a la solución correcta.

  • Un caso de choque de valores en una conversación con un gerente
  • La impresión de que se ignoró deliberadamente un feedback importante
  • La lección de que la alineación organizacional sobre la solución correcta es clave

• En 2019 participé en el trabajo de reescribir facebook.com en React. No conozco de primera mano el codebase ni la organización de LinkedIn, pero sí he visto empresas con codebases y estructuras organizacionales similares. Apoyo el enfoque de "finger gun", porque si se implementa bien puede dar resultados positivos. Cuando varios clientes intentan hacer el mismo trabajo, puedes usar uno como base para dar servicio a otras plataformas. O, si empiezas de cero, puedes hacerlo de una forma limpia, rápida y concisa. Un elemento común del éxito es que un pequeño equipo veterano construya el nuevo sistema, y creo que el éxito viene de equipos pequeños de ingeniería que combinan expertos del dominio con expertos técnicos. Un gran problema recurrente en la gestión técnica es que las personas con menos experiencia son quienes terminan construyendo el siguiente gran sistema.

  • Comparte su experiencia en una reescritura hacia React
  • Destaca el enfoque de "finger gun" y la importancia de equipos pequeños y veteranos
  • Señala el problema de que la gente con menos experiencia construya sistemas grandes

• Las grandes reescrituras son riesgosas incluso en codebases manejables, y los problemas residuales no desaparecen por completo. ¿Quién quiere reescribir una página de configuración oculta varios años después? Ojalá existiera un framework para reescribir codebases, pero en la práctica no existe. Los codemods automatizados requieren consistencia, y rara vez se cumple. Como los patrones del código han cambiado mucho con el tiempo, es como ver los anillos de un árbol. Se trata de meter el código en cajas y reordenarlo, pero a nivel de cajas no hay automatización.

  • Los riesgos de reescribir un codebase y los problemas residuales
  • La ausencia de un framework para reescribir código
  • La brecha entre la automatización a nivel de código y a nivel de cajas

• Actualmente trabajo en LinkedIn, y creo que el rol de Chris mencionado en el pódcast y el desarrollo web frontend están relacionados con ember. Parece que se refiere a voyager-web, la app web insignia monolítica de LinkedIn. Además de voyager-web, en LinkedIn hay muchos otros sistemas con millones de líneas de código y tiempos de build largos. Por ejemplo, la capa intermedia, el stack de datos offline, el sistema de métricas, Kafka, etc. Un build de 17 minutos es bastante bueno; si son 17 minutos sin fallas transitorias de infraestructura, entonces es muy bueno.

  • Comparte su experiencia actual trabajando en LinkedIn
  • Explica varios sistemas y sus tiempos de build
  • Evalúa el tiempo de build de 17 minutos

• Cientos de miles de líneas de JavaScript implican un volumen excesivo. Eso me hizo pensar en reimplementar un servicio como LinkedIn o construir mi propia base de datos de contactos. El problema es cómo migrar contactos en masa. Uno de los principales problemas de Microsoft LinkedIn es que no puedes exportar la información de contactos, y esa es una función imprescindible en una plataforma de contactos.

  • Señala el volumen excesivo de código JavaScript
  • La dificultad de transferir información de contactos
  • La importancia de poder exportar la información de contactos

• Pasé 12 años en LinkedIn, pero ahora está muy lejos de la organización de ingeniería de antes. Evalúo que era mucho mejor cuando Kevin Scott dirigía ingeniería.

  • Experiencia de largo plazo trabajando en LinkedIn
  • La diferencia entre la organización de ingeniería del pasado y la actual

• Aquí está operando la ley de Conway. Mientras la organización no cambie, volverán a crear el mismo caos de código. Las iniciativas positivas de ingeniería tienen que venir desde arriba y necesitan apoyo de niveles muy altos. Es imposible cambiar una organización de abajo hacia arriba; la organización produce el codebase.

  • Posibilidad de que el caos de código reaparezca sin cambios organizacionales
  • Necesidad de iniciativas positivas de ingeniería desde la alta dirección

• Me impresionó profundamente que Chris Krycho hablara con honestidad sobre sus dificultades sin entrar en el juego de culpas. CoRecursive es uno de mis pódcasts favoritos porque explora el contexto complejo detrás del código.

  • La actitud honesta de Chris Krycho y su rechazo a culpar a otros
  • Una valoración positiva del pódcast CoRecursive

• La migración de Ember a React parece un caso que encaja con una tecnología creada por un cliente para el que trabajé antes. Él creó un lenguaje llamado "Unhack" para permitir búsqueda y reemplazo a nivel de AST. Usaba un lenguaje en el que especificabas un patrón en el código original y luego otro patrón para reemplazarlo. Dejé de trabajar con ese cliente hace algunos años, así que no sé si todavía existe.

  • Un caso de migración técnica de Ember a React
  • El lenguaje "Unhack" que permite búsqueda y reemplazo a nivel de AST

• Que el codebase de LinkedIn sea un desastre no sorprende si has usado el sitio web. Haces clic en una publicación que te interesa, intentas saber más sobre quien la escribió y luego presionas atrás, y el feed se recarga y pierdes la publicación. Si intentas desplazarte por los mensajes recibidos, toda la página web se vuelve lenta y tarda entre 10 y 15 segundos en registrar la entrada. ¿Por qué recibo 30 notificaciones falsas? Son notificaciones falsas diseñadas para forzar interacción de la gente. El algoritmo de recomendaciones también es completamente terrible.

  • Las dificultades de usar el sitio web de LinkedIn
  • Notificaciones falsas y lentitud en la respuesta de la página
  • Señala problemas con el algoritmo de recomendaciones