La vida como intern de Dart

I don’t know.

Esas tres palabras pasan por la mente de los ingenieros de software todos los días. El trabajo de ingeniería consiste en acertijos y problemas, así que no saber algo es simplemente otro indicador de que un ingeniero tiene capacidad de crecer. Sin embargo, la falta de conocimiento también puede generar dudas sobre uno mismo.

Antes de comenzar mi pasantía este otoño, no sabía mucho sobre lenguajes de programación, sistemas de tipos, ni siquiera sobre varianza (que era todo mi proyecto). Hasta donde yo sabía, la varianza era solo un valor del que necesitaba calcular la raíz cuadrada para obtener una desviación estándar. Los lenguajes de programación y los compiladores me parecían una especie de magia negra que misterificaba a la mayoría de los desarrolladores.

Afortunadamente, mi manager, siendo el lector de mentes que era, entendió cómo me sentía y remedió mi nerviosismo.

“Mira, voy a ser completamente honesto, este proyecto te va a lanzar de cabeza a lo profundo. Todavía no sabes nada, pero eso está bien porque quiero que hagas preguntas, muchísimas preguntas,” explicó.

Daba miedo lanzarse de cabeza a un proyecto nuevo donde casi no tenía conocimientos previos sobre el trabajo, pero sabía que contaba con el apoyo de mi manager. Me dio la libertad de intentarlo, la libertad de cometer errores. Eso significó mucho para mí.

Esa breve charla con mi manager dio un impulso al primer mes de mi tiempo aquí: conocí a mi equipo en Fremont, Seattle, y estaba listo para lanzarme a este profundo desconocido llamado varianza, sobre el cual puedes leer en el artículo varianza en el sitio de declaración de Dart.

Tenía campos de entrenamiento semanales de varianza con mi manager, lo que me proporcionaba la teoría que luego tenía que traducir en código. Recuerdo haber leído la propuesta de la funcionalidad de varianza que iba a implementar y sentirme abrumado por los siete hitos necesarios para completar el proyecto: (1) escanear y luego analizar las nuevas palabras clave, (2) modificar el AST del kernel, (3) soportar varianza en el algoritmo de subtipado, (4) añadir errores y advertencias, (5) cambiar el cálculo de límites superior e inferior, (6) alterar las reglas de inferencia de tipos, y (7) trabajar en los cambios de comportamiento en tiempo de ejecución.

Entre cambiar el kernel (la representación intermedia del compilador) y la lógica de subtipado, necesitaba serializar y deserializar las anotaciones de varianza. El comportamiento en tiempo de ejecución se consideraba un objetivo adicional, pero apenas podía entender las seis tareas anteriores. No estaba seguro de dónde o cómo empezar.

Pero las cosas mejoraron.

Empezaba cada día laboral a las 9 am. Huevos revueltos, salchichas, col rizada y jugo de naranja era todo lo que necesitaba. Estaba listo para entrecerrar los ojos mirando código, preguntándome cómo demonios la gente hizo el primer compilador.

A menudo trabajaba en diferentes componentes en paralelo. Me mantenía ocupado y disfrutaba organizando metas. Cada mañana creaba un documento nuevo que listaba lo que quería lograr, desglosando las metas en tareas manejables.

De noche, la oficina de Google en Aarhus, Dinamarca, estaba activa. Sabiendo que tenía que trabajar con un par de ingenieros de Dinamarca, a menudo escribía mis preguntas, las finalizaba y las enviaba tarde en la noche en Seattle. Los tiempos de revisión de código se desplazaban 9 horas adelante, pero afortunadamente la diferencia horaria también me permitía revisar mi propio trabajo con más frecuencia antes de que fuera criticado.

Las críticas del equipo mejoraron mi capacidad para juzgar mi propio código y contemplar las ventajas y desventajas de diferentes implementaciones. Mis revisores señalaban áreas que había pasado por alto y hacían preguntas sobre qué es la varianza y cómo usarla. Corregía mi código, respondía sus preguntas, y me aseguraba de estar atento a los mismos problemas en el futuro. Más importante aún, indagaba más profundo y me preguntaba, ¿Cómo se les ocurrió esta mejora? ¿Qué conocimiento puedo llevarme de esto, más allá de la versión corregida del código? Era importante para mí aprender de cada comentario, en lugar de hacer clic mecánicamente en el conveniente botón de Done.

Mi forma de aprender fue haciendo preguntas. Siempre hay un equilibrio frágil entre ser un ingeniero de software terco apretando los dientes y machacando código que no tiene ningún sentido, y pedirle de mala gana ayuda al experto en esa base de código. Lo segundo casi siempre ahorraba más tiempo. Prefería asignar una cantidad decente de tiempo a trabajar de forma independiente, tomando notas y escribiendo preguntas a medida que encontraba áreas nuevas, y luego molestar a otro ingeniero cuando tenía 2 o 3 preguntas y un bloqueo sólido. Me di cuenta de que era mucho más productivo preguntar sobre problemas que me habrían requerido 3 horas de solución de problemas solo, comparado con 10 minutos de orientación y explicación de otra persona.

La seguridad en el lugar de trabajo también aumenta la productividad.

La seguridad, para mí, venía en forma de hacer preguntas, hacer bromas y almorzar con el equipo. Tan pronto como el reloj marcaba las 11:30, sabía que la siguiente media hora estaría llena de comida caliente y caras brillantes. Cada día escuchaba las historias y pensamientos más elaborados: las ventajas de tener 6 dedos, recibir una langosta cocida como regalo de Navidad, las horas de limpieza después de mezclar dos tuberías diferentes en Factorio… cualquier cosa y todo. Mi equipo me apoyó tanto en mis errores como en mis logros. Un buen equipo hace que sea mucho más fácil levantarse de la cama por la mañana para ir a trabajar.

Las horas antes y después del almuerzo también eran igual de agradables. Pasaba la mayor parte del tiempo leyendo código y entendiendo conceptos nuevos. El compilador de Dart está compuesto por muchos componentes grandes y en constante cambio, lo que significaba que necesitaba sumergirme en varias bases de código diferentes. Me encantaba tener la oportunidad de contactar a los equipos de front-end encargados del análisis estático, así como a los equipos de back-end que gestionaban los comportamientos en tiempo de ejecución. Era asombroso ver cómo los componentes trabajan juntos para crear una nueva funcionalidad en el lenguaje Dart.

La brecha entre implementación y teoría fue el aspecto más desafiante de mi proyecto. No todos los días uno necesita solidificar una demostración en código tangible. Mientras trabajaba en la varianza, esta brecha surgía cuando tenía preguntas — a veces mis consultas entrelazaban los componentes de la propuesta del lenguaje con una implementación apropiada. Las personas a las que acudía en busca de respuestas sabían qué archivo contenía el algoritmo de subtipado, o sabían cómo los cambios de subtipado afectaban las operaciones de asignación, pero nunca ambas cosas. Se sentía como construir una casa en un árbol con un par de piezas de madera contrachapada y la interpretación artística del resultado final.

Aun así, trabajar en Dart fue inmensamente gratificante y divertido. Me encantó el desafío, especialmente sabiendo que había mucho que aprender sobre áreas más allá de la varianza. Dart estaba, y sigue estando, creciendo y evolucionando para soportar mejor a los desarrolladores que usan el lenguaje. Observé al equipo moverse como un reloj bien afinado cuando surgían problemas cruciales que requerían atención inmediata. Escuchaba al equipo reflexionar sobre errores anteriores, asegurándose de que los procesos futuros no los repitieran.

Mi pasantía en el equipo de Dart mejoró mis habilidades de ingeniería, mis habilidades de comunicación y mi confianza en mis propias capacidades. Me enseñó la importancia de tener un equipo amigable, pero también muy funcional. Me enseñó las muchas formas en que la teoría puede traducirse en código, y las técnicas de resolución de problemas necesarias para hacerlo. Me enseñó más sobre mí mismo y sobre lo que valoro en el trabajo que hago.

Gracias Dart. Hasta la próxima.