Aumentando tu Esfera de Influencia como Ingeniero de Personal

Muy bien. Mi nombre es Ian Schwartz. Bienvenidos a mi charla en React Advanced 2024, Cómo Aumentar Tu Impacto como Ingeniero de Personal.

Esto es, así que déjenme hablar un poco sobre quién soy. Trabajo en una empresa llamada CarGurus. Creamos un mercado para, ya saben, no vendemos coches, pero podrías vender tu coche en CarGurus. Y aunque mi título es Principal, no tenemos un título de personal, pero Principal es el título que tiene muchas de las mismas responsabilidades que típicamente verías en personal y otros roles. He estado escribiendo JavaScript de una forma u otra desde 2015. Me encanta TypeScript y la programación funcional. De hecho, la mayoría de las charlas que he dado en otras conferencias han sido sobre programación funcional en TypeScript.

Y realmente, ya saben, el objetivo de esta presentación, esto en realidad surgió de otra presentación a la que asistí donde esperaba este tipo de contenido. Y cuando no estaba allí, dije esta es la charla que tengo que dar. Así que, ya saben, básicamente vamos a darles algunos consejos prácticos sobre cómo aumentar su influencia como desarrollador de personal. Esto se centra principalmente, ya saben, esto no se va a centrar en ninguna relación donde tengas reportes directos o uno a uno con personas. Ya saben, si acaso, el desafío de este rol es que usualmente no los tenemos. Así que hablemos un poco sobre lo que es un ingeniero de personal. Pueden ver mis memes generados por IA que hice. Así que ya saben, cuando pienso en un ingeniero de personal, es una definición realmente amplia, y voy a pasar rápidamente por muchos de estos. Pero ya saben, a un nivel muy alto, se supone que debes centrarte en proyectos estratégicos de valor para la empresa y elevar al equipo. Quieres establecer la dirección técnica. Ya saben, ¿qué significa esto? Ya saben, podría significar que quieres instituir una mayor calidad de, ya saben, pruebas o revisión de código o proceso. Hay muchas maneras en las que puedes ir con esto, pero es tu trabajo como ingeniero de personal ser el defensor de las necesidades tecnológicas de la empresa, ¿verdad? En un mundo donde cada desarrollador está tratando de cumplir sus objetivos y sus plazos, ya saben, es tu trabajo pensar, bueno, ¿cómo podemos hacer el sistema más eficiente? ¿Cómo puedo ayudarlos a prosperar en este entorno sin que realmente, como, sean mis subordinados que me reportan? Así que hay mucho de mentoría involucrada. Ya saben, un desarrollador junior que llega o alguien nuevo en la empresa, van a acudir a ti y deberías poder apoyarlos. Así que realmente, es tu trabajo ayudar a las personas a crecer. Ya saben, hacemos mucho de planificación. Así que participamos en discusiones de alto nivel, ya saben, tomando decisiones que son decisiones sensibles al tiempo en el contexto de la ingeniería. ¿A qué podemos comprometernos? ¿A qué no podemos comprometernos? Estas son cosas que buscaría en los ingenieros de personal. Creación de prototipos y resolución de problemas y desafíos ambiguos de alto impacto. Esta es una gran parte de lo que hago. Ya saben, la mayoría de las veces entras en una base de código y hay estos tipos de patrones que se han arraigado en la base de código.

Y espero que los ingenieros de personal observen y vean dónde están las ineficiencias, vean dónde los desafíos repetidos que la gente enfrenta, pero no necesariamente expresan. Este es un trabajo de ingeniero de personal para mí.

Veamos. Ser el pegamento. Me encanta este gráfico. La IA está mejorando mucho. Ser el pegamento. Muchas veces los ingenieros de personal son los que realizan las tareas de fondo, como, ya sabes, actualizar dependencias o encargarse de la deuda técnica o realizar refactorizaciones, que a menudo son invisibles para la empresa. Ya sabes, asegurarse de que el trabajo se realice a la velocidad correcta. Una gran parte de lo que hago en el trabajo es, ya sabes, escribir tickets y asegurarme de que escribas los tickets de la manera correcta y el trabajo se pueda hacer mucho más rápido que si los escribes de una manera diferente. Correcto.

Pensamos en esas cosas. Muchas veces cuando entras en una empresa como ingeniero de personal, se espera que escribas código. Y, ya sabes, pregunté en Reddit y obtuve las opiniones de la comunidad y casi unánimemente dijeron, oh, si eres un ingeniero de personal, no deberías estar haciendo el trabajo diario de sprint. Pero la verdad es que en muchas empresas se espera que equilibres el trabajo diario de sprint con más, ya sabes, tareas del tipo ingeniero de personal. Y esto es realmente un desafío de hacer.

Y no siempre es obvio cómo encontrar el tiempo o hacer el espacio para hacer los trabajos más de ingeniero de personal cuando tienes objetivos diarios. Pero dicho esto, creo que es importante mantener las manos sucias y en la base de código porque, ya sabes, hay una cosa en resolver problemas de alto nivel. Pero para poder ver esos problemas, creo que es realmente importante, ya sabes, saber por lo que todos los demás están pasando.

Y así, un trabajo que tenía un ingeniero de personal que no hacía ningún trabajo de sprint, cuestionaría qué tan en contacto estaban con los problemas que el resto del equipo enfrentaba. Siempre tienes que estar aprendiendo y desarrollando habilidades. De hecho, creo que así es como llegas a ser un ingeniero de personal si ya estás haciendo esto de todos modos. Así que muchos de ustedes probablemente ya tienen esto marcado. Pero especialmente el último punto sobre buscar retroalimentación regular, realmente creo que la retroalimentación es algo que debería estar sucediendo de todos en el equipo. El desarrollador más junior está tan calificado para hacer revisión de código como el desarrollador más senior. Y nunca sabes lo que la gente sabe o qué perspectiva aportarán o qué preguntas harán que te hagan ver las cosas de una manera diferente. Así que, ya sabes, lidera con el ejemplo al recibir revisión de código. Sé agradecido con los comentarios. Sé, ya sabes, estar dispuesto a realmente escuchar la retroalimentación de las personas porque eso les ayuda a crecer.

Y eso también es una gran parte de tu trabajo. Compartir conocimientos, los ingenieros de personal hacen mucha documentación. Lo hacen. Tienden a hacer presentaciones en mi empresa. Tenemos charlas técnicas específicas de la empresa que otras empresas han visto como Lunch and Learns y ese tipo de cosas. Mentoría y sesiones de formación interna. Sabes, si no estás haciendo estas cosas, no significa que no estés siendo un ingeniero de personal. Pero esta es solo la forma en que el rol se ha presentado para mí. Y creo que realmente ayudar a los desarrolladores junior a crecer es es es tan importante. Correcto. Porque las semillas que siembras con las personas hoy van a afectar la forma en que se escribe el código dentro de seis meses o un año. Así que realmente lo creo.

Construir y liderar proyectos de alto impacto, ya sabes, una gran parte de ser un ingeniero de personal, incluso si puedes estar haciendo trabajo de sprint, es también tener proyectos que tú mismo estás encabezando. Y es una cosa tener objetivos técnicos y cosas que quieres investigar. Pero es realmente importante asegurarse de que esas cosas tengan un alto impacto y valor para la empresa. Y según lo bien que hagas esto, realmente te ayudará a ayudarte con los otros aspectos de ser un ingeniero de personal. Sabes, necesitas que personas además de otros ingenieros te noten y necesitas que otros ingenieros te noten. Así que creo que eso es muy importante.

Liderar discusiones de diseño y arquitectura dentro de tu equipo. Aquí hay una pregunta. ¿Tu equipo tiene conversaciones sobre, ya sabes, diseño y arquitectura? ¿Están pensando en cómo estructurar su código de una manera que lo haga fácil de trabajar en el futuro y cómo diseñar la aplicación de una manera y arquitectarla de una manera que se mantenga flexible? Y, ya sabes, muchos equipos no tienen esas discusiones. Las presiones del trabajo diario de sprint son demasiado para poder realmente dar un paso atrás y luego pensar en cómo refactorizar esto o cómo construir de manera diferente en el futuro. Así que creo que es muy importante liderar esas discusiones y deberían venir de los niveles de ingeniero de personal.

Asegurar entregables de alta calidad a través de pruebas internas rigurosas y revisiones. Realmente me escucharás decir revisión de código un par de veces en esta presentación. Me encanta la revisión de código. Creo que es una de las mejores cosas que tenemos en cualquier equipo de desarrollo en el que he trabajado. Y si no lo tienes, deberías. Pero las pruebas también son importantes. Realmente he encabezado asegurarme no solo yo, todo mi equipo se ha asegurado de que nuestra cobertura de pruebas sea una de las más altas de nuestra empresa y realmente vale la pena porque no solo tenemos menos errores y todas las otras ventajas de las pruebas, no necesito venderte la idea de las pruebas. Pero cuando escribes código que está bien probado, la consecuencia de eso es que estás escribiendo mejor código.

Normalmente, si las pruebas son dolorosas de escribir, si las pruebas son la peor parte de tu trabajo, eso probablemente sea un indicio de mal código. Y así, tener pruebas de alta calidad asegura un código de alta calidad, en mi opinión. ¿Qué más tenemos aquí?

Abogar y ayudar a implementar las mejores prácticas de codificación en toda la empresa, esto no es siempre fácil de hacer, pero realmente necesitas ser vocal como ingeniero de personal y no siempre estás en una posición para decir así es como lo vamos a hacer. Yo ciertamente no lo estoy. No puedo tomar una decisión en mi empresa y decir que todos en la empresa lo van a hacer de esta manera. Pero lo que puedo hacer es abogar por las mejores prácticas. Sabes, las cosas no negociables que puedes exigir, ciertamente accesibilidad, alta cobertura de pruebas etcétera.

Pero mucho de esto es, ya sabes, decir, mira, creo que he encontrado una mejor manera de hacer esto o creo que si, ya sabes, cambiamos nuestra estrategia, no lo sé. Así que quieres establecer los principales estándares y guías de codificación en el equipo. Esto nuevamente se refiere a la revisión de código. Tuve un jefe que una vez dijo que cualquier regla que vayas a escribir en un knit, probablemente deberías hacer una regla de linter para ello. Así que, ya sabes, asegúrate de que haya un linter en tu proyecto, ¿verdad? Y asegúrate de que esté configurado de la manera que tú y el resto del equipo vean como representativa de buenas prácticas.

Utiliza herramientas internas para el análisis de calidad y rendimiento del código. Bueno, acabo de mencionar el linter, realmente quieres hacer que escribir buen código en tu base de código sea infalible. Cualquier comentario que dejes en una pull request y digas, bueno, ya sabes, knit, me gustaría que se hiciera de esta manera, ¿verdad? , eso solo existe en esa pull request. Nadie está revisando tu pull request buscando sugerencias de cómo escribir el código. Así que si es un knit, probablemente debería ser una regla de linter o al menos estar representado en algún lugar de la documentación donde alguien pueda hacerlo. Pero si puedes descargar ese trabajo a herramientas automatizadas, ¿verdad? , y hacer que el linter y el verificador de tipos, etc.

, etc. los hagan cumplir por ti, tendrás un tiempo mucho más fácil porque estos problemas nunca llegarán a la revisión de código y, por lo tanto, no tendrás que dejar esos comentarios. Impulsar la innovación, no lo sé, no me di cuenta de que este salió de lado. Sabes, esto es algo bastante típico, pero, ya sabes, pasé mucho tiempo probando cosas nuevas, probando nuevas estrategias y escribiéndolas, y aprendes tanto de los fracasos como de los éxitos. Sabes, siempre hay mucho en el mundo de JavaScript, mucho bombo sobre esto es hacia donde vamos. Oh, todos estamos usando Redux. Oh, todos estamos usando Zustand. Oh, todos estamos usando lo que sea. ¿Verdad? Vas a tener que dar esas opiniones al ingeniero de personal. Y, ya sabes, hay una expresión sobre cómo son las opiniones porque todos tienen una. Pero asegúrate de que tus opiniones estén fundamentadas en experiencia real. Muchos ingenieros, simplemente tienen esta idea de aquí está la forma en que escribo código. Pero mira, somos ingenieros de JavaScript. Esta es una conferencia de JavaScript en la que estamos aquí, una conferencia de React, ¿verdad? Las mareas cambian y necesitas saber cuáles de esos cambios son bombo y cuáles realmente representan un cambio en la forma en que las personas están escribiendo el código. Ya no todos usamos Enzyme para escribir pruebas. Ahora todos estamos usando, ya sabes, test library. ¿Verdad?

Tienes que intentarlo. Tienes que intentarlo. Si tienes tiempo para hacer un prototipo, haz un prototipo. Si tienes la libertad de simplemente usarlo, ya sabes, en el código, especialmente si estás hablando de cosas como herramientas de prueba o linters, ya sabes, simplemente hazlo.

Experimentar es realmente importante. Mentoría, de eso hablamos. No puedo enfatizar lo suficiente cuánto ser un buen mentor marca la diferencia para tu equipo en el futuro. Quieres que las personas se sientan envalentonadas para experimentar y aprender y tratar de mejorarse a sí mismas en la base de código. Y quieres especialmente que cuanto más junior sean las personas, más importante es empoderarlas. No te equivoques, la gente renuncia debido a malos ingenieros senior en el equipo. OK, ser un buen ingeniero senior es realmente, realmente importante. Quieres que se vayan del trabajo y piensen en ti como la persona que los ayudó a crecer. Y, ya sabes, aprender como ingeniero es muy importante. Siempre digo, ya sabes, incluso si tienes un trasfondo en ciencias de la computación o te enseñaste a ti mismo, todos somos autodidactas como ingenieros.

Y, ya sabes, quiero que las personas desafíen constantemente sus ideas de lo que significa escribir buen código. Lo que nos lleva de vuelta al título de la charla, cómo realmente construir influencia, ¿verdad? , porque muchas de estas cosas, OK, es fácil decir que voy a liderar con el ejemplo, pero ¿la gente me ve como un líder? A veces lo hacen, a veces no. Cuanto más grande es la empresa, más difícil es. Y, ya sabes, para mí, soy una persona muy extrovertida. Soy el tipo de persona que inicia conversaciones y simplemente expresa mi opinión. Pero no todos lo son y no todos deberían serlo. Y aún necesitas poder construir influencia, incluso si no eres ese tipo de persona. Entonces, ¿cómo lo hacemos? Lo primero es liderar con el ejemplo, y esto, ya sabes, hablamos sobre lo importante que es escribir código real, ya sabes, y hacer trabajo de sprint en tu aplicación. Nunca convencerás a tu equipo de tener una buena cobertura de pruebas a menos que les muestres cómo escribir esas pruebas. OK, nunca les mostrarás cómo escribir, ya sabes, código seguro que no tenga any's a menos que también estés escribiendo código seguro sin any's. Tu documentación debería ser, ya sabes, de chef's kiss. Hermosa, ¿verdad? Usa JS stock donde tengas que usar TypeScript donde sea posible, ya sabes. En términos de gestión de proyectos, nuevamente, creo que mencioné antes, pienso mucho sobre las formas correctas de escribir tickets para mí. Soy un gran fan de tengo este objetivo de hacer todo el trabajo que tengo que hacer simplemente perfectamente paralelizable. Sabes, tenemos tres desarrolladores front-end en el equipo.

Así que liderar con el ejemplo es realmente, realmente importante. Cuando dejo comentarios en una revisión de código que dice, ya sabes, esto no es una buena práctica, realmente quiero poder señalar lugares en el código donde lo he hecho de la manera que creo que es correcta. Y quiero que esos lugares estén respaldados por pruebas para que cuando otras personas intenten implementar esas cosas y les diga que necesitan escribir pruebas, haya un ejemplo de cómo hacerlo.

Sabes, no es tan difícil de hacer, pero si no te ensucias las manos en la base de código, no podrás hacerlo. Pensamiento estratégico y resolución de problemas. Sabes, es realmente importante estar pensando en el futuro cuando se trata de código, y esto es algo que los desarrolladores de rango y archivo no siempre pueden hacer porque no es por ningún problema con ellos, sino que están recibiendo presión constantemente de gerentes de proyecto y gerentes de producto y diseñadores y sus, ya sabes, sus gerentes técnicos para, ya sabes, este trabajo tiene que hacerse para una fecha límite.

Y al final del día, a veces pasar una hora o dos adicionales en un PR y hacer algunos cambios te ahorrará más trabajo en el próximo PR, ¿verdad? Haremos esto más sostenible. Así que tú, como ingeniero de planta, es tu trabajo estar mirando hacia el futuro. OK, así que significa pensar más allá de tus desafíos técnicos inmediatos y significa realmente idear enfoques para.

Para resolver estratégicamente, solo estoy parafraseando los enfoques para la resolución estratégica de problemas. Es muy común para mí tener esta sensación cuando estoy trabajando en un ticket de, ya sabes, hay este punto problemático con el que me he encontrado tres o cuatro o 10 veces antes y simplemente tienes este momento de eureka donde te das cuenta de que no hemos encontrado realmente un enfoque para resolver este problema. Y es por eso que seguimos encontrándonos con él. Es tu trabajo como ingeniero de planta ver eso y estar constantemente desafiándote a ti mismo para verlo. Y honestamente, los otros desarrolladores en tu equipo te estarán agradecidos por haberlo hecho. Si puedes tomar una canalización que tomó cuatro pasos dolorosos que tenías que ejecutar manualmente y convertirla en un comando de yarn, nadie se enojará contigo. OK. Obviamente, implementar estas cosas y lograr que las personas las adopten nos lleva de vuelta a nuestra última diapositiva. ¿Verdad? Si no estoy escribiendo código, puedo decirle a alguien, esto es lo que creo que deberías hacer. Pero, ¿estoy realmente diagnosticando el problema con precisión?

Y quién me va a escuchar si no lo he hecho? Nuevamente, no tengo la autoridad para exigirlo en equipos que no sean el mío. ¿Verdad? Y entonces, ¿quién me va a escuchar a menos que les esté mostrando la manera correcta de hacerlo? En mi opinión. Creo que es realmente importante ser un experto en la materia.

Este año, escuchas sobre ser un desarrollador en forma de T, alguien que sabe mucho sobre muchas cosas, pero también tiene un tema en el que son realmente profundos. En realidad, creo que es aún mejor ser lo que sea que esta forma que dibujé. Hay mucho, ya sabes, deberías ser, es bueno ser un experto en la materia, pero no te limites a la cosa para la que eres un experto en la materia cuando te contrataron.

Soy principalmente un desarrollador de React, pero a medida que la empresa ha, ya sabes, todos en mi empresa comenzamos a usar Remix, lo que ha significado necesitar mucho de lo que tradicionalmente se pensaba como conocimiento de back end o full stack. Y así, porque tengo otras áreas de experiencia además de solo React, a medida que avanzamos en el uso de Remix, ya sabes, hay ideas que puedo aportar que no habría podido. Y estoy constantemente tratando de ampliar mi conocimiento sobre esos temas para que a medida que nos enfrentamos a nuevos desafíos y nos estamos enfrentando a muchos de ellos porque ninguno de nosotros ha creado una aplicación SSR antes. Correcto.

Lo siento, no SSR, SSG. Sabes, necesitas ser capaz de identificar problemas y resolverlos, y no puedes hacer eso si estás demasiado aislado. Cada conferencia, incluida esta, va a estar hablando sobre IA durante los próximos años, y tengo una gran opinión sobre la IA. En realidad, realmente no me gusta usarla para la generación de código, no porque no crea que sea buena o porque crea que es buena o no buena en ello, sino porque me gusta escribir código. La parte del trabajo que es difícil de hacer es la parte del lenguaje, la parte del lenguaje natural, dejar buenos comentarios en las solicitudes de extracción, comunicar cosas de una manera que no haga que la gente se enoje contigo.

Tuve un jefe que me dio la idea de usar análisis de sentimientos en mi solicitud de PR, así que instalé Grammarly. Y tenía falsos negativos porque si decías la palabra error, por ejemplo, que es una palabra de programación, pensaría que estabas siendo negativo. Pero hubo suficientes veces verdaderas en las que me atrapó hablando de una manera que podría haber parecido más crítica o enojada o cortante de lo necesario. Y así, en realidad usé análisis de sentimientos y mejoré la calidad de mi retroalimentación de revisión de código. Y esto es importante porque he visto a personas renunciar por tener seniors que no podían comunicarse efectivamente. Chat, GPT o Claude u otros LLMs son una excelente manera de hacer eso también. Puede que trabajes en una empresa que no te permita usar IAs para código. Pero, ya sabes, poder decir cómo le digo a este desarrollador que creo que están implementando un anti-patrón sin sonar como un idiota y chat GPT hará un buen trabajo diciéndote cómo hacerlo.

Esto incluso va hay algo que no puse en la diapositiva, pero lo voy a decir de todos modos. ¿Puedo recomendar algo que no recomiendo? Lo recomiendo un poco, que es que tuve un jefe hace muchos años antes de ser desarrollador que me dijo que mis correos electrónicos eran demasiado cortantes. Este es un problema que tengo. Y su consejo para mí fue usar emojis. Y sé lo que todos están pensando. Pero la verdad es que un emoji de cara sonriente al final de una declaración podría hacer mucho para suavizar la forma en que se recibe. Puedes usar ese consejo o no. Tu experiencia puede variar. Esto es lo más importante sobre construir influencia, sin embargo, es que todo lo que haces tiene que hacerse en público. OK, bueno, no todo, pero muchas cosas.

Los DMs son el peor lugar para compartir conocimiento. No puedes buscarlos. No puedes indexarlos. La gente se olvida de ellos. Si alguien deja la empresa, ¿puedes siquiera acceder a ellos? Y ciertamente no puedes llevártelos contigo. Así que creo que es realmente importante asegurarse de que mucho de lo que estás haciendo como ingeniero de planta sea en público.

Y he clasificado esto en orden de lo que creo, cómo creo que deberían hacerse. Si puedes lograr que tu empresa te permita open source algo de tu código, hace mucho para liderar con el ejemplo. Hace mucho para compartir y aplicar las mejores prácticas y la calidad del código. Porque realmente puedes decir que no vamos a poner código de mala calidad en un repositorio open source. Y también es bueno para tu carrera porque, ya sabes, tu nombre siempre estará en esos pull requests iniciales. Siempre serás la persona que comenzó ese repositorio.

Las publicaciones en el blog de la empresa, si las tienes, la mayoría de las empresas tienen un blog o les gustaría tener uno. Y si lo tienen, es muy difícil encontrar personas que estén entusiasmadas con publicar regularmente. Nuevamente, es genial para tu carrera. Cuando estés solicitando tu próximo trabajo, querrás tener esas publicaciones en el blog. Y si no eres un ingeniero de planta, probablemente aún puedas publicar en el blog. En mi empresa, la barrera para publicar en el blog es muy baja. Y sin embargo, la gente no lo hace tanto como debería.

Lo siguiente sería confluence o documentación similar, porque realmente puedes buscar a través de ella. Lo mismo con los canales públicos de Slack, especialmente una conversación sobre la recopilación de requisitos o, ya sabes, implementar una mejor práctica. Me encantaría verlo en confluence y en un canal público de Slack, ambos porque la gente buscará esas cosas. Y si alguien tiene un problema, me encantaría que lo publicara en un canal público de Slack para poder darle la respuesta en público y no en un mensaje directo porque entonces, cuando la próxima persona tenga ese problema, ya sabes, me gustaría poder enlazarlos a ello.

Y luego el último son los comentarios en pull requests. Y realmente los comentarios en pull requests son buenos para cosas que están documentadas en otros lugares. Correcto. Si vas a aplicar algo en un comentario de PR, con suerte tienes un confluence o una publicación en el blog o una referencia externa en algún lugar a la que puedas enlazarlos, porque eso va a surgir una y otra vez. Y nadie revisa los viejos comentarios de pull requests y los busca.

Cuanto más público seas, mejor te ayudará en tu empresa cuando estés haciendo tus OKRs para el año y tratando de justificar tu promoción. Puedes apostar que a la gerencia le encanta ver publicaciones en el blog y repositorios open source porque, ya sabes, son concretos y no solo para los nerds en ingeniería para verlos.

Correcto. Puedes realmente mostrárselos y decir, este es el trabajo útil que he hecho. El código open source es tan genial porque puedes ir a tu próximo trabajo y decirles, mira, escribo buen código, pero si realmente puedes mostrarles tus commits en público, entonces eso es aún mejor.

Y así que lo que hice en el trabajo fue que logré dividir un montón de nuestro código en su propio repositorio y hacerlo open source. Quiero que otras personas en la empresa lo usen. Algunos de ellos lo están haciendo, pero incluso si no lo hicieran, ¿verdad?, aún tendría eso como un logro en mi haber por haber trabajado aquí, lo cual es una forma un poco cínica de decirlo. Es una forma cínica de verlo. Pero, ya sabes, estamos hablando de cómo gestionar tu carrera.

Así que un cierto grado de cinismo está justificado, lo que nos lleva al final de la charla. Ya sabes, solo para resumir, puedes ver muchas definiciones diferentes de lo que significa ser un ingeniero de planta, pero es tan importante asegurarse de que la gente sepa tu nombre y sepa quién eres. Y la forma de hacerlo es hacer lo que sea que estés haciendo en público. Así que esa es mi recomendación número uno. Sabes, no tienes reportes directos. Necesitas que la gente piense que esta persona, Ian Schwartz, es el tipo al que, si tengo una pregunta sobre React o testing, ¿verdad?, voy a acudir a Ian Schwartz. Y eso es cierto para muchas personas en mi empresa. Pero, ya sabes, aumentar el número de personas que piensan de esa manera es realmente importante y solo se puede lograr asegurándose de que lo que sea que hagas sea descubrible y abierto para que el mundo lo vea. No tengo mucho más que decir al respecto aparte de eso. Muchas gracias por venir a mi charla y prestar atención hasta ahora.