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 lo más británico posible. Fuimos al Distrito de los Lagos. Y allí tuvimos nuestra propia campaña de quedarse o irse. Eso resultó en el Brexit. Lo siento por eso. Lamentablemente, ya no vivo en Londres, pero definitivamente tuvimos el mejor año aquí. Así que feliz de estar aquí.

El comité me pidió que hablara un poco sobre tener una career de ingeniero de software y compartir algunas lecciones que he aprendido en el camino con ustedes. Trabajé durante algunos años en una startup llamada Mendix. He estado trabajando durante algunos años en Meta, y también tuve mi negocio de consultoría por un tiempo. Pero la mayoría de las personas probablemente me conocen por todo el negocio de open-source que está sucediendo, junto con Emer, Morbix y muchos más. Y así compartiré algunas lecciones personales sobre eso. Probablemente no las necesiten, pero yo las necesitaba. Así que eso es de lo que hablaré.

Y cuando pienso en carreras en ingeniería de software, básicamente se pueden pensar en esas tres direcciones diferentes. No estaba realmente interesado en la primera opción, así que no hablaré de esa. Y como creo que es bastante incómodo hablar mucho de mí mismo de todos modos, también hablaré de este tipo. Y me pregunto, tenemos muchas personas británicas aquí, así que deberían saber quién es este. ¿Puedo escuchar un grito? Sí, exactamente, es Eisenbart Kingdom Brunel. Probablemente el ingeniero más famoso de todos. Al menos tiene el mejor nombre y el mejor atuendo. Así que también hablaremos un poco de é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 esta pila perfecta, usar la mejor biblioteca para interfaces de usuario hoy en día, que es React. Usaré las reglas perfectas de ESLint que moldearán mi código y algo que es muy automático. Lamentablemente, después de un tiempo, te das cuenta de que la realidad se impone. Siempre hay esos clientes molestos que piden características que no encajan en tus abstracciones y las cosas se vuelven feas con el tiempo o las personas no entienden exactamente lo que estás haciendo. Así que la primera gran lección, creo, para crecer como ingeniero es aprender que el código será imperfecto.

De hecho, se podría 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 delante de él? ¿Qué pasaría si simplemente lo colocara en un tubo de aire, le aplicara presión y moviera los vagones hacia atrás y hacia adelante? 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 dio por 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 debemos 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 las personas estaban demasiado involucradas en la forma en que resuelven el problema y tenían todo tipo de peleas por básicamente nada, como los puntos y comas o algo así. Así que debemos estar un poco desapegados de lo que estamos construyendo.

Y también hay ventajas. Hace un tiempo me pidieron que investigara este producto que fue construido por un departamento muy diferente, y querían escalarlo en toda la organización a varios 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 mantenía durante dos años, y estaba muy indeciso al respecto, porque básicamente quería proponer reescribir el núcleo de la cosa. Pero presenté mi caso, y en realidad, para mi sorpresa positiva, estaban muy contentos con eso, y resultó en una colaboración realmente buena. Pero la única forma en que eso podría haber funcionado fue porque no se sentían demasiado apegados a lo que estaban construyendo, y aún 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 tener en cuenta el hecho de que el código es perecedero cuando reviso PR 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 tiempo. Así que quiero asegurarme de que, como, dondequiera 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 lo harías tú, lo haría yo. Todos abordan las cosas de manera ligeramente diferente. Creo que eso está bien, y si hay demasiado estrés, puedes tomar nota mental de ello, pero en general, creo que debemos preocuparnos mucho por las relaciones en torno al código. Y creo que eso construye relaciones duraderas. O parafraseando 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 testing.

El código será imperfecto, por lo que debemos tener una clara historia de pruebas. A veces veo, especialmente en el mundo Scrum, que las personas plantean las pruebas como una historia separada. No creo que funcione. Eso lo convierte en un problema de gestión, cuando en realidad es un problema de ingeniería. Es tu decisión determinar si quieres probar algo o no. Las pruebas siempre son una estimación del esfuerzo versus el 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á hacer más inversiones. Veo muchos casos en los que las personas no superan el obstáculo inicial de configurar suficientes pruebas para que sea económico 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 lo predeterminado. Pero nuevamente, las pruebas también son imperfectas.

Una cosa con la que realmente puedes destacarte como ingeniero es volverte muy bueno en la depuración. Creo que esta habilidad a menudo se subestima, así que aquí tienes algunos consejos realmente prácticos al respecto.

Uno de ellos es que no sé si la gente todavía usa console.log para depurar. No creo que sea un enfoque muy bueno. No tengo nada en contra de los console.logs. No los necesitas. Las herramientas actuales pueden encargarse de eso por ti. Toma, por ejemplo, las herramientas de desarrollo de Chrome. Simplemente puedes ir a un archivo fuente en tu navegador, encontrar la parte que deseas 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 personas no lo conocen.

Bienvenido. Sí, esto no es muy creativo, pero es práctico. Aquí tienes un escenario más complicado. A menudo intentamos averiguar cómo llegamos a este estado. Por ejemplo, ¿por qué los complementos están en un estado en el que no esperaba que estuvieran? Un truco simple para averiguar dónde se está cambiando esa cosa es simplemente envolver un getter y un setter a su alrededor. Coloca un depurador 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 depuración más importante que tengo para ti es básicamente dejarlo ir. Lo que quiero decir con eso es que si llevo varias horas intentando resolver un problema y identifico dónde está el error, dejo de intentar resolver el problema. En cambio, entro en un modo diferente en el que simplemente comienzo a observar el sistema. Interactúo un poco con él de manera aleatoria. Navego un poco por el código fuente. Reviso un poco los registros. No trato realmente de entenderlo. Solo trato de obtener información en mi cabeza. Y luego lo dejo ir, me alejo, hago otra cosa, me voy a casa, duermo bien y a menudo al despertar al día siguiente o en el momento en que salgo del metro, me doy cuenta de que este sistema probablemente está enviando mensajes allá y yendo allá y algo muy complicado, pero tu subconsciente es muy 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 que debemos prepararnos para lidiar con ello. Básicamente, pienso que cuando el código es perfecto, probablemente has tenido demasiado tiempo libre.

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, no tenía que justificarlo ante nadie, bueno, hasta que tuve una familia. Y luego puedes llegar a la perfección. Pero no hay clientes, al menos no al principio, a quienes debas satisfacer. Así que puedes verificar la forma a tu gusto.

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 será incompleto. Como ingeniero senior, a menudo podemos tener este dominio en el que somos muy especializados, sabemos exactamente qué está sucediendo, 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 funciona desde la estación de Pennington aquí hasta el oeste del Reino Unido. Pero aquí está lo interesante. La compañía se estableció en 1833, y nuestro amigo Brunel también estuvo involucrado como ingeniero. Y 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 desde 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 cuenta con un barco. Eso es extraño, ¿verdad? Pero esta fue la visión que tenía la compañía. La parte occidental se refería al oeste del Reino Unido, y se trataba de ir a Estados Unidos, a las Américas. Y así establecieron una visión que tiene muchas partes desconocidas en el medio. No solo tienes que descubrir cómo hacer cosas de ferrocarril, también cómo construir barcos. Y Brunel también sabía 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 confiar en los demás. 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.

Otra lección interesante que tuve que aprender aquí es que los proyectos de infraestructura, siempre que tengas una visión para un nuevo proyecto, siempre hay un problema de dilema. Y a menudo es así. Tus clientes dicen: oh, estoy muy emocionado con tu proyecto, suena realmente genial. Sin embargo, si la tecnología fuera madura, la estaría usando. Y tú dices: sí, sí, si la usaras, sería madura. Necesito clientes para que esto madure y tenga buenos casos de prueba, etc. Y así tienes este dilema en el que intentas encontrar una opción para algo que aún es muy imperfecto. Y la única forma que he encontrado para lidiar con eso es tomar 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 radio, le doy una casilla de verificación y no un botón de radio. Ese es solo un atajo que tomaré. Y dentro de dos años, alguien dirá, ¿cómo puede ser esta una biblioteca de UI seria? ¿Tiene un botón de radio? Eso es tan estúpido. Pero a menudo es porque las personas pasan por alto el contexto de que hubo un momento en el que la cosa aún no estaba establecida. Y simplemente dan por sentada su existencia. Y luego tienen expectativas diferentes. Es como la Estación Paddington. Esa no fue la primera estación en construirse. Es una hermosa estación. Pero primero debes demostrar el concepto de un ferrocarril y una 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 una diapositiva que recibí el año pasado. Y habla sobre este proyecto. Comenzamos en 2010, que básicamente era un bus de servicios enterprise. No estoy seguro de por qué no usamos algo existente. Pero lo construimos nosotros mismos. Queríamos que fuera perfecto. Pero luego, cuatro años después, la empresa creció tanto que la escala se volvió demasiado grande.

Y sucedió en varios casos donde la gente comenzó a encontrar un problema, terminó en un comentario. Y pensaron... Oh, él ya lo sabía. ¿Por qué no lo arregló? Pero ese es el problema de la paradoja. Y 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.

Tal vez en este punto, estés pensando... Okay. Esta es un poco una historia triste. El código será imperfecto. Tengo que aceptarlo. Mi conocimiento será incompleto. Tengo que aceptarlo. 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 retrasan y se pasan mucho del presupuesto.

Pero no piensan a mitad de camino... Oh, usemos este nuevo marco de trabajo y construyamos 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 cuando construyes puentes. Así que tenía esta cita sobre la construcción de puentes. Me opongo a establecer reglas o condiciones que se deben observar en la construcción de puentes. Porque el progreso de las mejoras de mañana podría verse obstaculizado o limitado por los prejuicios de los errores de hoy. También era bastante elegante. Pero básicamente está diciendo que la ingeniería civil también era joven en ese momento. No tenían todo resuelto, por lo que no querían encadenarse. Así que, por favor, tenlo en cuenta la próxima vez que agregues una nueva regla de ESLint a tu configuración.

Gracias. ¡Hurra! Muchas gracias, Michelle. Antes de invitarte a mi oficina para hacer un par de preguntas, quiero recordarles a todos que pueden ingresar a Slido, S-L-I-D-O, con el código 2124, y hacer sus preguntas para Michelle, que por favor entre a mi oficina, señor. ¿No es agradable? Es como un pequeño programa de entrevistas. Me siento muy Oprah en este momento.

¿Cómo estás? Bien. Bastante bien. Sí. Gracias por esa charla. Fue muy interesante. Lo primero de lo que quiero hablarles es de los equipos. Creo que mucho de lo que dijiste se aplica mucho en el mundo real a las personas que trabajan en equipos. Además, a veces las personas de código abierto también son equipos. ¿Cómo puedes ser tan generoso con el código de los demás como lo eres con tu 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 compañero, más comentarios puedes dejar. En Matter, tenemos el dicho de que los comentarios son un regalo. Y realmente lo son. Pero solo se convierte en un regalo una vez que comienzas a apreciarlo. Entonces, cuando estás revisando código y alguien es nuevo en el equipo o nuevo en el proyecto de código abierto, lo primero que intentas averiguar es, como, qué parte de este código es realmente arriesgada, ¿verdad?, lo cual podría romper el producto. Eso es en lo que comentas primero. Luego, si no hay mucho allí, puedes pasar a 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, pienso: `De acuerdo, ya tengo diez comentarios en esta PR, lo dejo así`. Habría hecho algunas cosas ligeramente diferentes, pero, hey, también puedo mencionarlo en otro momento, o simplemente tenerlo en cuenta en mi cabeza y volver más tarde si se convierte en un problema. Así que no todos los comentarios que tenemos tienen que ser expresados.

Ese es un buen punto, y en realidad se relaciona con una de las preguntas que recibimos a través de Slido, que es, Michelle. Como ingeniero de software, ¿también lees o modificas el código de otros ingenieros y tienes alguna experiencia además de escribir tus propias pruebas y tu propio código? Sí, definitivamente. Creo que las personas deberían sentirse muy libres en la empresa en general para tocar nuestro código. No eres dueño del código. No es tuyo.

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

¿Dirías... Sabes cómo hay dos tipos de personas. Las personas que son como... Si funciona, déjalo estar. Y las personas que son como... No, seamos consistentes. Para que haya... Ciertos elementos de estilo y el equipo pueda saber... ¿En qué lado de ese espectro te encuentras? Siempre he sido bastante pragmático, creo. Pero definitivamente con el tiempo me he inclinado más hacia... Si funciona. Déjalo así. ¿Verdad? Cada vez me doy más cuenta de lo efímero que es el código. Lo perecedero que es. Así que puedes cambiarlo hasta la perfección. Y luego, la próxima semana, llega un cliente y necesita una abstracción que no encaja en absoluto, y de todos modos tienes que rehacerlo. Así que eres más del tipo... Si funciona. No eres del tipo... Esto es una tabulación, no un espacio. Exactamente. Yo soy más del tipo... 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í. Permíteme asegurarme. No tenemos ninguna pregunta. Ya hicimos esa.

De acuerdo. ¿Qué consejos o recursos compartirías con alguien que está tratando de tal vez entrar en un rol de liderazgo técnico, o algún rol de liderazgo que lidie mucho con código y ese tipo de cosas? Creo que crecer a través de los controles no se trata tanto de recursos, creo. Es simplemente estar allí por un tiempo. Veo bastante cambio de trabajo en nuestra industria, a menudo tiene mucho sentido. Pero creo que liderar en tecnología se basa a menudo en conocer muy bien el contexto, conocer a las personas que te rodean muy bien, también a las que no están en tu equipo. Así que no creo que cambiar de trabajo con frecuencia sea beneficioso para crecer en un rol de liderazgo técnico. Así que creo que ese sería mi principal consejo, como, quédate un par de años o más y lo hará mucho más fácil. Casi como si las relaciones fueran muy importantes en el coaching. Casi como si, sí.

Muchas gracias, Michel, por unirte a nosotros en la silla de preguntas y respuestas. Ahora eres libre de irte. Por favor, un aplauso para Michel.