Una Carrera Como Ingeniero de Software

Rate this content
Bookmark
Slides

Normalmente hablo mucho sobre conceptos técnicos profundos como TypeScript, sistemas de tipos, (in)mutabilidad, MobX, Immer, etc. Pero esta vez será personal y compartiré lecciones, buenas y malas, sobre cómo crecer como ingeniero. He liderado proyectos de código abierto, proyectos de corta duración como freelancer y he pasado por la transición de ingeniero a líder técnico dos veces. Tanto en una startup joven como en Meta. Esta charla tratará sobre experiencias personales, opiniones impopulares e incluso acciones, y cualquier otra cosa que pueda ser contraintuitiva. Únete para obtener algunas lecciones para cualquiera que aspire a una carrera enfocada en la ingeniería. Probablemente estaré equivocado en la mayoría de las cosas, ¡así que no pierdas la oportunidad de seguir después!

24 min
21 Oct, 2022

Video Summary and Transcription

El código será imperfecto y perecedero, por lo que las pruebas y la depuración son cruciales. Construir relaciones y ser generoso con las revisiones de código son importantes para los equipos. La propiedad del código debe pertenecer al equipo, no a los individuos. Priorizar la funcionalidad sobre la consistencia puede llevar a un desarrollo más eficiente. Crecer en un rol de líder técnico requiere construir relaciones y habilidades de coaching.

Available in English

1. Introducción y Lección de Código Imperfecto

Short description:

Compartiré algunas lecciones personales sobre carreras en ingeniería de software. Y cuando pienso en carreras en ingeniería de software, básicamente se pueden pensar en esas tres direcciones diferentes. La primera gran lección que tuve que aprender es que el código será imperfecto.

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.

2. Code Imperfecto y Construcción de Relaciones

Short description:

El código es perecedero y no debe ser apegado. Debemos enfocarnos en el objetivo final en lugar de cómo lo implementamos. Construir relaciones es importante en las revisiones de código. Ama el código y a los demás como a ti mismo. Las pruebas ayudan a lidiar con las imperfecciones.

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.

3. Pruebas y Depuración

Short description:

El código será imperfecto, por lo que debemos tener una clara historia de pruebas. A veces, las personas plantean las pruebas como una historia separada, pero eso lo convierte en un problema de gestión, cuando en realidad es un problema de ingeniería. Las pruebas siempre son una estimación del esfuerzo versus el riesgo. A medida que tu producto se vuelve más exitoso, el riesgo aumenta, justificando más pruebas. Trabaja en una cultura donde las pruebas sean lo predeterminado.

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.

4. Consejos de Depuración

Short description:

Una cosa con la que realmente puedes destacarte como ingeniero es volverte muy bueno en la depuración. Console.log no es un enfoque muy bueno para la depuración. Utiliza las herramientas de desarrollo de Chrome para agregar un punto de registro en tu código fuente. Envuelve un getter y un setter para averiguar de dónde proviene un cambio. El consejo de depuración más importante es dejarlo ir y observar el sistema. Tu subconsciente es muy inteligente y hay trucos para aprovecharlo.

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.

5. Imperfect Code and Incomplete Knowledge

Short description:

Los únicos casos en los que pude acercarme a un código bastante perfecto fue cuando estaba en proyectos de código abierto. 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. 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. 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.

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.

6. Building Projects and Dealing with Imperfections

Short description:

Y luego alguien lo construye, y eso es aún más satisfactorio que hacerlo por tu cuenta. 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 la única forma que he encontrado para lidiar con eso es tomar todos los atajos feos que puedas encontrar. 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. Comenzamos en 2010, que básicamente era un bus de servicios empresariales. Pero luego, cuatro años después, la empresa creció tanto que la escala se volvió demasiado grande.

Sin embargo, eso cambia algunas cosas. Por lo tanto, donde tu herramienta favorita como ingeniero podría ser VS Code, de repente comienzas a usar otros productos de Microsoft. Pero eso es la transición hacia el liderazgo técnico.

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.

7. Code Imperfections and Industry Reputation

Short description:

Y dijimos, okay, esto es arriesgado. Es un único punto de fallo. Debemos deshacernos de eso. Entonces, 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. El código será imperfecto. Mi conocimiento será incompleto. 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.

Y luego recibí esta diapositiva otros siete años después, donde finalmente lo habían migrado. Y la gente... Así que dejé la base de código de Cat llena de comentarios como... Aquí, en este y aquel caso, esto eventualmente fallará. Y había bastantes de esos.

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.

8. Building Bridges and Avoiding Rules

Short description:

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.

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.

9. Teams and Code Review

Short description:

Lo primero de lo que quiero hablarles es de los equipos. ¿Cómo puedes ser tan generoso con el código de los demás como lo eres con el tuyo propio? Al revisar código, lo primero que intentas averiguar es qué parte de este código es realmente arriesgada. No todos los comentarios tienen que ser expresados. Como ingeniero de software, debes sentirte libre de leer o modificar el código de otros ingenieros.

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.

10. Code Ownership and Prioritization

Short description:

La propiedad del código debería pertenecer al equipo, no a los individuos. Hay dos tipos de personas: aquellos que priorizan la funcionalidad y aquellos que priorizan la consistencia. Yo me inclino hacia la funcionalidad y entiendo que el código es efímero y perecedero. Si funciona y cumple con los requisitos, eso es suficiente.

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.

11. Tips for Growing into a Tech Lead Role

Short description:

Y ahora tenemos prettier. Quédate un par de años o más y lo hará mucho más fácil. Las relaciones son muy importantes en el coaching.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Top Content
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn