Una Carrera Como Ingeniero de Software

Buenos días a todos. Es bueno estar en Londres y también dar la bienvenida a todos en la transmisión en vivo. Mi familia y yo el verano pasado hicimos la cosa más británica de todas. Fuimos al Distrito de los Lagos. Y allí tuvimos nuestra propia pequeña campaña de dejar o permanecer. Eso resultó en el Brexit. Lo siento por eso. Así que tristemente, ya no vivo en Londres, pero definitivamente tuvimos el mejor año aquí. Muy feliz de estar aquí.

El comité me pidió que hablara un poco sobre tener una carrera de ingeniero de software y compartir algunas lecciones que he aprendido en el camino con ustedes. He trabajado durante un par de años en una startup llamada Mendix. He estado trabajando durante un par de años ahora en Meta, y también tuve mi negocio de consultoría por un tiempo. Pero la mayoría de la gente probablemente me conocerá por todo el negocio de código abierto que sucede, junto con Emer, Morbix, y muchos más. Y así compartiré algunas de las lecciones personales sobre eso. Así que probablemente no las necesiten, pero yo las necesitaba. Así que de eso hablo.

Y cuando pienso en carreras de ingeniería de software, básicamente puedes pensar en esas tres direcciones diferentes. Realmente no estaba interesado en la primera, así que no hablaré de esa. Y como creo que es bastante incómodo hablar mucho sobre mí mismo de todos modos, también voy a hablar sobre este tipo. Y me pregunto, tenemos a muchas personas británicas en la sala, así que deberían saber quién es este. ¿Puedo escuchar un grito? Sí, exactamente, es Eisenbart Kingdom Brunel. Probablemente es el ingeniero más famoso de todos los tiempos. Al menos tiene el mejor nombre y el mejor atuendo. Así que también hablaremos un poco sobre él.

Y así, la primera gran lección que tuve que aprender es que el código será imperfecto. Recién salido de la universidad, siempre pensaba, voy a construir este stack perfecto, usar la mejor biblioteca para UIs hoy, que es React. Usaré las reglas perfectas de ESLint que moldean mi código y algo que sea muy automático. Tristemente, después de un tiempo, aprendes que la realidad se impone. Siempre hay esos clientes molestos que piden características que no encajan en tus abstracciones y las cosas se ponen feas con el tiempo o la gente no entiende exactamente lo que estás haciendo. Así que la primera gran lección que creo para crecer como ingeniero es aprender que el código será imperfecto.

De hecho, podrías incluso decir que el código no solo es imperfecto. Es solo un subproducto de lo que estás tratando de lograr. En resumen, el código es perecedero.

Y Brunel es un gran ejemplo de pensar en conceptos perecederos. Por ejemplo, un día tuvo esta maravillosa idea de por qué un código necesita una locomotora al frente de él? ¿Qué pasaría si simplemente lo pusiera en un tubo de aire, pusiera algo de presión y moviera los vagones de un lado a otro? Básicamente inventó el hyperloop. Y eso fue hace aproximadamente 200 años. Y lo construyó, y funcionó, pero no lo suficientemente bien. Así que se sintió satisfecho, y después de medio año abandonaron la idea y se distanciaron de ella. Y creo que esa es a menudo una lección importante que tenemos que aprender como ingenieros, que no estamos demasiado apegados a las cosas que construimos. Cómo lo implementamos. He visto bastantes conflictos a lo largo del tiempo donde la gente estaba demasiado aferrada a la forma en que resolvieron el problema y estaban teniendo todo tipo de peleas por básicamente nada, como puntos y comas o algo así. Así que tenemos que estar un poco desapegados de lo que estamos construyendo.

Y también hay ventajas. Hace un tiempo me pidieron que revisara este producto que fue construido por un departamento muy diferente, y querían escalarlo en toda la organización a múltiples departamentos. Y lo revisé, y estaba bastante bien, pero no era completamente semánticamente correcto, podría ser más rápido. Así que fui al equipo original que ya lo estaba manteniendo durante dos años, y estaba muy dudoso al respecto, porque básicamente quería proponer reescribir el núcleo de la cosa. Pero presenté mi caso, y de hecho, para mi sorpresa positiva, estaban realmente contentos con ello, y resultó en una muy buena colaboración. Pero la única forma en que eso pudo haber funcionado fue porque no se sentían demasiado apegados a lo que estaban construyendo, y todavía tenían una visión clara de lo que estaban tratando de lograr, en lugar de lo que estaban escribiendo. De manera similar, también trato de mantener el hecho de que el código es perecedero en mente cuando estoy revisando PRs de otras personas. Y la razón de eso es, básicamente, quiero hacer concesiones en soluciones en lugar de en relaciones. La mayoría de los códigos duran tal vez un par de años. Un negocio puede durar más. Así que quiero asegurarme de que, donde sea que esté la persona con la que estoy interactuando en el otro lado del PR, mantengamos nuestra relación. A veces las personas no resolverán los problemas exactamente de la manera en que tú lo harías, yo lo haría. Todos abordan las cosas de manera ligeramente diferente. Creo que está bien, y si hay demasiado estrés, puedes hacer una nota mental de ello, pero en general, creo que tenemos que preocuparnos mucho por las relaciones alrededor del código. Y creo que eso construye relaciones duraderas. O para parafrasear ligeramente a alguien más famoso, ama un poco el código y a los demás como a ti mismo. Esa referencia fue a Sapo. La otra forma de lidiar con las imperfecciones es pensar en las pruebas.

El código será imperfecto, por lo que debemos tener una historia clara de pruebas. A veces veo, especialmente en el mundo de Scrum, que las personas mencionan las pruebas como una historia separada. No creo que funcione. Eso lo convierte en un problema de gestión, cuando básicamente es un problema de ingeniería. Es tu decisión determinar si quieres probar algo o no. Las pruebas siempre son una estimación de cuál es el esfuerzo frente al riesgo que se está cubriendo.

A medida que tu producto vive más tiempo y se vuelve más exitoso, el riesgo aumentará automáticamente, lo que también justificará incurrir en más costos. Veo muchos casos donde las personas no superan el obstáculo inicial de establecer suficientes pruebas para que sea barato agregar más. Las primeras pruebas son realmente difíciles y costosas de escribir. Cuantas más escribas, más fácil se vuelve. Tienes más datos de prueba, etcétera, etcétera. Simplemente trabaja en una cultura donde eso sea la norma. Pero nuevamente, las pruebas también son imperfectas.

Una cosa en la que realmente puedes destacarte como ingeniero es volverte realmente bueno en debugging. Creo que esta es una habilidad a menudo subestimada, así que algunos consejos realmente prácticos al respecto.

Uno es, no sé si la gente todavía usa console.log como debugging. No creo que sea un enfoque muy bueno. No tengo nada en contra de console.logs. No los necesitas. Las herramientas hoy en día pueden manejar eso por ti. Toma, por ejemplo, las herramientas de desarrollador de Chrome. Puedes simplemente en tu navegador ir a un archivo fuente, averiguar la cosa que quieres inspeccionar, y agregar un punto de registro. Te ahorra la compilación, el paso de recarga. Simplemente agrega una declaración de console.log en vivo para tu código sin cambiarlo. Es mucho más rápido. Siempre me sorprende cuántas pocas personas lo saben.

Bienvenido. Así que, sí, esto no es muy creativo, pero es práctico. Aquí hay un escenario más complicado. A menudo estamos tratando de averiguar cómo terminamos en este estado. Por ejemplo, ¿por qué están los plugins en el estado en el que no esperaba que estuvieran? Un truco simple para averiguar dónde se está cambiando esa cosa es simplemente envolver un get run setter alrededor de ella. Pon un debugger o un punto de interrupción en un setter y sabrás exactamente de dónde proviene un cambio. Muy simple, muy práctico.

Pero el consejo de debugging más importante que tengo para ti es básicamente simplemente dejarlo ir. Lo que quiero decir con eso es que si estoy corriendo durante un par de horas en un problema y pongo mi dedo en él donde va mal, dejo de intentar resolver el problema. En cambio, voy a un tipo diferente de modo donde simplemente empiezo a observar el sistema. Interactúo un poco con él bastante al azar. Navego un poco por el código fuente. Reviso un poco los registros. Realmente no trato de entenderlo. Solo trato de obtener información en mi cabeza. Y luego lo dejo ir, me alejo, hago otra cosa, voy a casa, duermo bien y tan a menudo esos despierto al día siguiente o en el momento en que sales del metro, y estás como, oh, este sistema probablemente está enviando mensajes por allí y yendo allá y algo muy complicado, pero tu subconsciente es realmente inteligente y hay trucos para aprender a aprovecharlo. Así que esa es la primera parte sobre aprender a aceptar que el código será imperfecto y nosotros mejor nos preparamos para lidiar con ello. Así que básicamente creo que cuando el código es perfecto, probablemente tenías demasiado tiempo en tus manos.

Los únicos casos en los que pude acercarme a un código bastante perfecto fue cuando estaba en proyectos de código abierto, porque era mi tiempo, tenía que justificarlo a alguien, bueno, hasta que tuve una familia. Y entonces puedes llegar a la perfección. Pero no hay clientes, al menos no inicialmente, a los que tengas que satisfacer. Así que puedes verificar la forma a tu antojo.

La segunda lección que tuve que aprender es que no solo mi código será imperfecto, también en algún momento tu conocimiento se volverá incompleto. Como ingeniero senior, a menudo podemos tener este dominio donde estamos muy especializados en él, sabemos exactamente lo que está pasando, si alguien viene con una solicitud, sabemos a dónde ir para solucionarlo. Pero luego, tal vez crezcamos hacia algo más grande. Tomemos el Great Western Railway como ejemplo. Creo que todavía corre desde la estación de Pennington aquí hacia el oeste del Reino Unido. Pero aquí está lo interesante. La compañía fue establecida en 1833, y nuestro amigo Brunel también estuvo involucrado en ella como ingeniero. Y así, este es uno de los anuncios del Great Western Railway, y he visto algunos anuncios de software escandalosos, pero este también es interesante. Habla de un tren de Nueva York a Londres. La última vez que lo comprobé, hay un pequeño charco en el medio. Y aquí hay otro. El Great Western Railway presenta un barco. Eso es extraño, ¿verdad? Pero esta era la visión que tenía la compañía. La parte occidental era sobre el oeste del Reino Unido, y se trataba de ir a los Estados Unidos, a las Américas. Y así, básicamente establecieron una visión que tenía muchas partes desconocidas en el medio. No solo tienes que averiguar cómo hacer las cosas del ferrocarril, también cómo hacer las cosas de construcción de barcos. Y de hecho, Brunel también sabía sobre eso. Es un tipo bastante asombroso. Pero creo que eso es una excepción. Así que a menudo, cuando intentamos establecer una visión más amplia, comenzamos a depender de otras personas para llenar los vacíos donde no conocemos todas las respuestas. Y al principio, cuando comencé a crecer de ingeniero senior a líder técnico, y lo hice en ambas compañías, se sintió muy incómodo porque no conoces el dominio del problema y tienes que depender de otros. Pero luego descubrí esta cosa interesante. También es extremadamente satisfactorio si no sabes algo. Estableces una dirección vaga. Planteas esta idea. Creo que este servidor puede comunicarse con ese sistema allá, no estoy seguro de cómo, pero puede lograr algo.

Y luego alguien lo construye, y eso es aún más satisfactorio que hacerlo por tu cuenta. Sin embargo, cambia algunas cosas. Así que donde tu herramienta favorita como ingeniero podría muy bien ser VS Code, de repente comienzas a usar otros productos de Microsoft. Pero esa es la transición hacia el liderazgo tecnológico.

Otra lección interesante que tuve que aprender aquí es que los proyectos de infraestructura, siempre que tienes una visión para un nuevo proyecto, siempre hay un problema de catch-22. Y a menudo va así. Tus clientes están como, oh, estoy muy emocionado con tu proyecto, suena realmente genial. Sin embargo, si la tecnología fuera madura, la estaría usando. Y tú estás como, sí, sí, si la usaras, sería madura. Necesito clientes para hacer esto maduro y tener buenos casos de prueba, etcétera. Y así tienes este catch-22 donde intentas encontrar una opción para algo que todavía es muy imperfecto. Y la única forma que he encontrado para lidiar con eso es simplemente tomando todos los atajos feos que puedas encontrar. Y no es una respuesta satisfactoria. Pero si tengo que construir una nueva biblioteca de UI y mi primer cliente necesita una casilla de verificación y no un botón de opción, le doy una casilla de verificación y no un botón de opción. Ese es solo un atajo que tomaré. Y dentro de dos años, alguien dirá, como, ¿cómo puede ser esto una biblioteca de UI seria? ¿Tiene un botón de opción? Eso es tan estúpido. Pero eso es a menudo porque la gente pierde el contexto de que hubo un tiempo en que la cosa no estaba establecida todavía. Y simplemente dan por sentada su existencia. Y luego tienes diferentes expectativas. Es como la estación de Paddington. Esa no fue la primera estación en ser construida. Es una hermosa. Pero primero tienes que probar el concepto de un ferrocarril y estación con algo feo en el vecindario de Liverpool antes de derribar la mitad de la ciudad de Londres. Y así, este es en realidad un caso de la vida real de esta fue una diapositiva que recibí el año pasado. Y habla sobre este proyecto. Comenzamos en 2010, que era básicamente un bus de servicio empresarial. No estoy seguro de por qué no usamos algo existente. Pero lo construimos por nuestra cuenta. Queríamos que fuera perfecto. Y luego, cuatro años después, la empresa creció tanto que la escala se volvió demasiado grande.

Y estábamos como, está bien, esto es arriesgado. Es un punto único de falla. Deberíamos deshacernos de él. Y luego recibí esta diapositiva otros siete años después, donde finalmente lo habían migrado fuera. Y la gente... Así que dejé la base de código Cat llena de comentarios como... Aquí, en este y aquel caso, esto eventualmente fallará. Y hubo bastantes de esos.

Y sucedió en bastantes casos donde la gente comenzó a elegir un problema, terminó en un comentario. Y estaban como... Oh, él ya lo sabía. ¿Por qué no lo arregló? Pero ese es el problema del Catch-22. Y así todos esos comentarios con soluciones temporales, que son muy permanentes, también serán eventualmente consistentemente verdaderos. Así que se trata mucho de las cosas que no haces. Los problemas que no resuelves. Las soluciones que no construyes tú mismo. Incluso las objeciones que no construyes.

Así que tal vez en este punto, estés como... Está bien. Esta es una historia un poco triste. El código será imperfecto. Tengo que aceptar eso. Mi conocimiento será incompleto. Tengo que aceptar eso. No es de extrañar que nuestra industria tenga tan mala reputación. Mira a esos ingenieros civiles. Diseñan la línea Elizabeth. Muy compleja. Muy grande. Y sí, se pasan de tiempo y mucho se pasan de presupuesto.

Pero no piensan a mitad de camino... Oh, vamos a usar este nuevo framework y construir un Hyperloop en su lugar. ¿Verdad? Tienen un plan y lo ejecutan. Pero para dejarte tranquilo, estaremos bien. Y voy a explicar por qué con una última cita de Grunell. Así que recuerda, ese tipo estaba construyendo puentes. Y si lo hacía mal, la gente moriría. Eso es básicamente lo que sucede si estás construyendo puentes. Así que tenía esta cita sobre la construcción de puentes. Estoy en contra de establecer reglas o condiciones que deban observarse en la construcción de puentes. Porque el progreso de las mejoras de mañana podría verse avergonzado o encadenado por grabaciones o registros como la, los prejuicios de los errores de hoy. También era bastante elegante. Pero básicamente está diciendo que, al igual que la ingeniería civil era joven en ese momento. No tenían todo resuelto, y por eso no querían encadenarse. Así que, por favor, ten eso en cuenta la próxima vez que añadas una nueva regla de ESLint a tu configuración.

Gracias. Yay. Muchas gracias, Michelle. Antes de invitarte a mi oficina para un par de preguntas, quiero recordarles a todos que pueden ir a Slido, S-L-I-D-O, con el código 2124, y poner sus preguntas para Michelle, que le preguntaremos, por favor pase a mi oficina, señor. ¿No es esto agradable? Es como un pequeño programa de entrevistas. Me siento muy Oprah ahora mismo.

¿Cómo estás? Bien. Bastante bien. Sí. Gracias por esa charla. Fue muy interesante. Lo primero de lo que quiero hablarte es de los equipos. Creo que mucho de lo que hablaste se aplica mucho en el mundo real a las personas que trabajan en equipos. Además, a veces las personas de código abierto son equipos. ¿Cómo en un equipo puedes ser tan generoso con el código de otros como lo eres con el tuyo propio o contigo mismo? Como dijiste, no es perfecto. Creo que a menudo tienes que construir una relación de confianza, y eso significa que cuanto más conoces a alguien y más confías en tu iniciador, más comentarios puedes dejar. En Matter, tenemos el dicho, como, el feedback es un regalo. Y realmente lo es. Pero solo se convierte en un regalo una vez que empiezas a apreciarlo. Entonces, cuando estás revisando código, y alguien es nuevo en el equipo, o nuevo en el proyecto de Opsource lo primero que intentas averiguar es, como, qué parte de este código es realmente riesgosa, ¿verdad?, que rompería el producto. Eso es lo que comentas primero. Luego, si está ahí, no mucho ahí, entonces puedes entrar en cosas más detalladas, y cuánto de eso dejas, creo que depende principalmente de cuánto tiempo has estado trabajando con esta persona. A veces, estoy como, está bien, ya tengo diez comentarios en este PR, lo dejo así. Habría hecho incluso más cosas ligeramente diferentes, pero, oye, también puedo mencionarlo en otro momento, o simplemente mantener una nota mental en el fondo de mi cabeza y volver más tarde si se convierte en un problema.

Entonces, no todos los comentarios que tenemos tienen que ser expresados. Ese es un gran punto, y en realidad se relaciona con una de las preguntas que recibimos a través de Slido, que es, Michel. Como ingeniero de software, ¿también leerías o modificarías el código de otros ingenieros, y tienes algún aprendizaje allí además de escribir tus propias pruebas y tu propio código? Sí, definitivamente. Creo que la gente debería sentirse muy libre en la empresa en general para tocar nuestro código. No posees el código.

Y debería tener sentido para todos. Y si... Bueno, quiero decir, no reescribas una pieza de código de otra persona solo porque no te gusta el estilo sin lograr nada. Eso será muy molesto y no será bueno para las relaciones. Pero en, creo, en general, los archivos no deberían tener la propiedad de una persona, ¿verdad? Es un equipo el que posee una pieza de código.

¿Dirías... Sabes cómo hay dos tipos de personas. Las personas que son como... Si funciona, déjalo entrar. Y las personas son como... No, seamos consistentes. Para que haya... Ciertos elementos de estilo y el equipo pueda saber... ¿En qué lado de ese espectro estás? Siempre he sido bastante pragmático, creo. Pero definitivamente con el tiempo he ido más en la dirección de como... Funciona. Dejémoslo. ¿Verdad? Me he dado cuenta cada vez más de lo efímero que es realmente el código. Lo perecedero que es. Así que puedes cambiarlo a la perfección. Y luego la próxima semana, un cliente viene, necesita una abstracción que no encaja en absoluto, y tienes que revisarlo de todos modos. Así que eres más como... Si funciona. No eres como un... Esto es una tabulación, no un espacio. Exactamente. Soy más como... Si funciona. Y quiero decir... Si es para hacerlo más rápido o probarlo más, entonces está bien.

Y ahora tenemos prettier. {{^}}Y tenemos prettier. Para todo el tiempo anterior. Sí. Déjame asegurarme. No tenemos ninguna pregunta. Preguntamos eso.

Bien. ¿Qué consejos o recursos compartirías con alguien que está tratando de tal vez entrar en un rol de tech lead, o algún rol de liderazgo que trate mucho con códigos y ese tipo de cosas? Creo que crecer a través de los controles no se trata tanto de recursos, creo. Es solo estar allí por un tiempo. Como, veo bastante cambio de trabajo en nuestra industria, a menudo tiene mucho sentido. Pero creo que ser tech lead a menudo se basa en conocer muy bien el contexto, conocer muy bien a las personas a tu alrededor, también, que no están en tu equipo. Así que no creo que cambiar de trabajo mucho sea beneficioso para crecer en un rol de tech lead. Así que creo que ese sería como mi principal beneficio, como, quédate un par de años o más y será mucho más fácil. Casi como si las relaciones fueran muy importantes en el coaching. Casi como si, sí.

Muchas gracias, Michel, por acompañarnos en la silla de preguntas y respuestas. Ahora eres libre de irte.