Guía de Bolsillo para la Seniority

Hola a todos. Gracias por venir a mi charla. Se titula A Pocket Guide to Seniority. De hecho, está inspirada en este libro que escribí hace algún tiempo. Y siéntanse libres de obtener el libro usando este código QR. Si lo siguen, se les pedirá que descarguen el PDF. Por supuesto, pueden pedir el libro en formato de tapa blanda desde Amazon y uno de los... sí, en realidad solo desde allí.

Así que hay 20 cosas dentro del libro. Las recopilé a lo largo de los años, y en algún momento decidí hacer un libro con ellas. Probablemente no tendré tiempo para todas ellas ya que mi presentación dura 20 minutos y tengo un minuto para cada uno de los temas. Y ya quemé un par de minutos hablando de esto. Así que, sí, solo sigan el código QR o contáctenme en alguna de las redes sociales. Les enviaré el PDF.

Así que la motivación detrás de todas estas cosas y de recopilarlas es que quería encontrar una manera de reconocer a las personas senior en los equipos de los que formo parte. Estoy mentoreando a esas personas, lo que significa que son personas de nivel medio que quieren llegar a posiciones senior. Así que decidí hacer una especie de lista de viñetas sobre lo que significa ser senior. La primera cosa es la comunicación. Creo que especialmente hoy en día, es una de las cosas más importantes que existen.

Y aquí hay un pequeño ejemplo. Digamos que alguien viene a ti con un problema de que la página de usuarios en tu aplicación es realmente lenta y sugieren, OK, añadamos paginación. Y esto es una especie de mala comunicación, una mala definición de una tarea porque lo que, por ejemplo, la persona de nivel medio hará es que, OK, seguro, tengo la página y simplemente añadiré una paginación del lado del cliente. Por supuesto, este no es el problema real, ¿verdad? Tal vez la aplicación está obteniendo cinco mil usuarios de la base de datos, y por eso es realmente lenta. Así que al final, el equipo de QA no está contento, la gestión de proyectos no está contenta, el equipo de desarrollo no está contento, por supuesto, después de eso.

Así que la comunicación es realmente importante. La forma en que comunicas lo que necesita hacerse como ingeniero senior es realmente importante. Y en este caso particular, podrías ser realmente específico diciendo, OK, el problema es que tenemos tantos usuarios y tienes que obtenerlos, por ejemplo, 20 por página y la página debería ser controlada por la URL y todo esto. Así que creo que es importante trabajar en la dirección de ser realmente claro. Y esto llevará a mejores resultados. Y especialmente hoy en día cuando tenemos la necesidad de comunicarnos no solo con personas sino con agentes. La capacidad de comunicar claramente lo que necesita hacerse es realmente, realmente, realmente importante. Sabemos esto desde hace un par de tal vez un poco más de un año que si escribes un mal prompt, si pides algo poco claro para que lo haga el agente, el resultado que obtienes, por supuesto, no es tan bueno.

Y para ser justos, creo que esta no es una habilidad que solo sea válida para ingenieros senior. Tengo dos hijos, de nueve y 14 años. Y estamos hablando con mi esposa muy a menudo, ¿cuál será la habilidad del futuro? Porque están cambiando de escuela ahora y estamos tratando de guiarlos, no realmente empujarlos, sino aconsejarlos sobre lo que deberían aprender. Y la verdad es que la comunicación es realmente, realmente importante para la capacidad de comunicarse con otros seres humanos. Y ahora con robots, es realmente, realmente importante. Así que la comunicación es la primera. Deberías ser capaz de comunicar claramente tus ideas, tus pensamientos. Deberías escuchar del otro lado. Así que, sí, la comunicación es la primera, especialmente si estás apuntando a roles de ingeniero agente. Hoy en día, como mencioné, hablar con máquinas no es, por supuesto, diferente, pero no elimina la necesidad de ser un buen comunicador.

Así que el otro es ver el panorama completo. Y cuando digo esto, quiero decir que muy a menudo las tareas que recibimos como desarrolladores, no tienen un camino claro porque quien da la tarea, realmente no conoce el panorama completo. Y tu trabajo como ingeniero senior es muy a menudo entender todo el stack, toda la aplicación, todo el sistema. Y en este ejemplo, los usuarios tienen problemas para restablecer sus contraseñas. Así que usualmente sabes cómo funciona. El usuario llega a la app, hace una solicitud para cambiar la contraseña, luego enviamos un correo electrónico. Hacen clic en el enlace en el correo electrónico y entran la nueva contraseña. Así que esto es como la idea general de cómo se construye el futuro. Y probablemente lo sabes. Pero si hay un problema en algún lugar y no conoces el panorama completo, básicamente no sabes dónde buscar. Y las personas senior muy a menudo, son curiosas y exploran todo el sistema en el camino de construir algo o tal vez por alguna otra razón. Pero aquí, digamos que el problema es que el servicio de terceros que usamos para la base de datos no paga o necesitamos llegar al nuevo contratante.

Y así olvidamos hacer eso. Así que la base de datos no está disponible y el usuario realmente no puede solicitar nada. Tal vez estamos almacenando la solicitud. Tal vez estamos generando el enlace para restablecer la contraseña y almacenando este enlace en la base de datos. La base de datos no funciona ahora. Así que si no conoces todo el panorama, probablemente no serás capaz de entender de dónde viene el problema. No serás capaz de siquiera comenzar a investigar sobre el problema. No serás capaz de escribir nada al agente para tratar de averiguar dónde está el problema. Así que conocer todo el panorama es una señal clara de que tu equipo es un ingeniero senior.

Y si estás trabajando en algo, no te limites. No te encierres en exactamente lo que estás haciendo. Solo mira alrededor un poco, toca diferentes cosas, haz preguntas sobre cómo funciona todo. Esto te ayudará a construir todo el panorama. La propiedad es la otra cosa que es realmente importante. Por supuesto, esto no es válido solo para personas senior que están escribiendo código e ingenieros. Es válido para todos. Hay muchos ejemplos sobre personas que poseen algo.

El ejemplo que decidí mostrar es este tipo John. Él es de Tanzania y fue elegido para ser parte de las Olimpiadas como corredor de maratón. Al principio, se lesionó. Se dislocó la rodilla, lo cual puedes imaginar el dolor probablemente. Y lo interesante es que él no aceptó el hecho de que tendría que ni siquiera terminar. Y las palabras famosas que dijo al final es que mi país no me envió aquí para comenzar la carrera. Me enviaron aquí para terminarla. Por supuesto, hay muchos, muchos ejemplos sobre personas llevando sus habilidades físicas al límite para lograr algo.

llevando sus habilidades físicas al límite para lograr algo. Espero que nosotros, como programadores, como desarrolladores, no tengamos que trabajar con una pierna o un brazo roto o algo así. Pero poseer tu tarea, poseer el trabajo es realmente importante y es definitivamente una señal de personas senior.

Si te preguntas si alguien en tu equipo está listo para ser senior, esta es probablemente una de las cosas que deberías observar. Por ejemplo, digamos que tienes que desarrollar una función. La haces. La terminas. Pero luego, una semana después, simplemente regresa. Ve cómo funciona. Observa las implicaciones de esta función desde un punto de vista empresarial.

Ve si esta función está tocando algo técnico, tal vez en tu stack. Cómo se está cargando en el sistema. ¿Está bien? ¿Está funcionando? Tal vez revisa los trabajos. Tal vez pregunta a tus colegas si es algo interno, si están contentos. Muy a menudo, poseer algo no significa solo terminarlo. Significa hacer un seguimiento de cómo va. Y ves que tu equipo, por ejemplo, tus colegas, que son personas senior, usualmente dan un paso más allá.

No solo implementan algo. Se aseguran de que funcione. Funciona junto con la otra parte del sistema que entrega valor a la empresa y al proyecto.

Tengo un buen ejemplo con mi práctica donde comencé a poseer algo que era realmente aburrido para la otra parte del equipo. Y muy a menudo, lo que sea que necesite hacerse en esta área, básicamente yo era el tipo porque sabían que realmente desarrollé la experiencia en esta área. Así que muy a menudo si alguien está haciendo algo realmente bien, es una señal de que podrías empujar a esta persona a poseer esta cosa porque probablemente le interesa y es más fácil.

Pero si estás en una posición para mentorizar a personas que están en camino de convertirse en desarrolladores senior, esta es una buena manera de ayudarlos a empujarlos hacia algo que definitivamente poseen. La gestión del ego es la otra gran cosa. Y aquí, desde la perspectiva de un programador, diría que el código que estás escribiendo, las aplicaciones que estás construyendo, las abstracciones que estás creando, esto no eres tú. No te identifiques con ellas, aunque esto pueda ser el comportamiento más natural porque si escribes algo, especialmente durante mucho tiempo, y si mantienes algo, alguna parte del sistema, muy a menudo las personas se identifican con esta cosa. La poseen.

Así que el ego no tiene lugar en el entorno que necesita un equipo, básicamente. Si trabajas solo, probablemente esté bien. Pero deberías aceptar el hecho de que el código que estás escribiendo no es el mejor que podría escribirse. Y muy a menudo, este es probablemente el caso. Sé abierto a la retroalimentación de diferentes personas, no solo de personas a tu nivel, incluso de personas junior. A veces ven cosas que tú no.

Así que nosotros, como programadores, deberíamos saber que las cosas que estamos escribiendo probablemente están mal y se convierten en legado al día siguiente. Deberíamos estar listos para dejar nuestro ego a un lado y hablar sobre lo que hicimos y aceptar toda la retroalimentación, incluso si es negativa. Sé que esto es difícil de manejar. Quiero decir, no es algo que puedas enseñar a alguien. No puedes decirle a alguien, oye, tienes un gran ego, así que solo bájalo.

Pero solo sé un ejemplo. Esto ayuda en la mayoría de los casos solo para guardar la retroalimentación de diferentes personas. El fracaso es el futuro. Personalmente creo que esto se convertirá en un gran problema muy, muy pronto porque las personas en general, nosotros como seres humanos, es difícil aceptar el hecho de que cometemos errores y a veces cuestan dinero. Pero al mismo tiempo, todos sabemos que cometer errores es la forma en que progresamos, cómo aprendemos. Y especialmente en la edad más joven, cuando estamos en la escuela, sabemos que cuando cometes un error, este es probablemente el momento en que estás aprendiendo algo.

Y mi preocupación hoy en día es que no solo las personas están temerosas, tal vez es una palabra fuerte para eso, pero la gente no está cometiendo suficientes errores. Y especialmente en el mundo de la IA, los agentes no cometen errores. Ellos no cometen errores de sintaxis. A menudo, casi siempre, el código que escriben se compila sin errores. Los errores que cometen los agentes son a nivel conceptual, lo cual es realmente difícil de detectar. Tal vez más tarde en el proceso, los ves, pero los fundamentos reales y la forma en que aprendemos a programar para entender el lenguaje, aprendes los paradigmas en este lenguaje, simplemente están desapareciendo lentamente, pero están desapareciendo porque ya no escribimos tanto código.

Y creo que esto podría ser un problema, porque, nuevamente, siendo padre, sé que cuantos más errores cometes, te vuelves mejor y mejor en lo que estás haciendo porque toma más tiempo. Practicas más. Repites el mismo error tal vez múltiples veces, pero al final realmente sabes cómo funciona. Y no veo que esto suceda ahora con los agentes. Así que esto es definitivamente algo en lo que deberías pensar, especialmente como persona senior. Recomiendo encarecidamente que dediques tiempo a veces a codificar por tu cuenta sin un agente. Estoy luchando con esto yo mismo. Estoy viendo cómo, especialmente para las partes aburridas, siempre pido a alguien que lo haga. Pero sí, definitivamente es algo en lo que deberíamos pensar.

Hay un discurso famoso de Roger Federer sobre cómo ganó solo la mitad de los puntos en sus partidos profesionales. Y es realmente, realmente interesante, realmente extraño cómo uno de los mejores tenistas en realidad ganó solo la mitad de ellos. El resto son solo errores, lo que demuestra que incluso los mejores, cometen errores y aprenden de ellos. Es un discurso realmente interesante, por cierto, así que asegúrate de verlo. El sexto consejo es ser un buen cocinero. Y cada vez que entramos en una base de código y cuando miras los componentes, ves algo un poco fuera de lugar. Tal vez sea algo menor, pero solo asegúrate de limpiarlo. Creo que hay una cita famosa sobre dejar la base de código mejor de lo que la encontraste. Creo que todos lo sabemos. Es un buen consejo en general. Lo que diría que odio más es cuando alguien ve algo mal y dice, esto no es mi trabajo. Esto no es lo que estoy haciendo ahora o esta no es la aplicación que estoy manteniendo o desarrollando. No voy a arreglarlo.

Lo peor que podrías decir es que no es mi trabajo. Realmente, realmente odio eso, porque es tu trabajo. Aunque no seas QA, por ejemplo, sí, arregla las pruebas o no seas un desarrollador front end, pero ves una etiqueta que no está cerrada o algo, simplemente ciérrala. Esto es como mantener tu hogar porque la base de código, tal vez no estés tocando todo. Tal vez no seas responsable de cada pieza de tu stack o tu aplicación o tu producto. Pero este es tu hogar y es una actitud pésima simplemente saltarse algo porque no es tu trabajo. Todo es tu trabajo. Eres parte de esta empresa, especialmente las personas senior. Ellos poseen cosas. Deberían preocuparse por todo el código que todos tenemos. Así que, sí, sé un buen, buen cocinero y limpia después de lo que veas.

La simplicidad es otra cosa interesante y un concepto que creo que la mayoría de las personas senior tienen. Ser pragmático sobre las cosas es realmente importante. Y el pragmatismo muy a menudo significa encontrar el equilibrio entre la perfección y avanzar. La otra cita realmente famosa es progreso sobre perfección. Y muy a menudo el progreso viene de hacer las cosas simples. Y nuevamente, quiero que veas cómo estoy empujando todo a un tipo de punto de vista, porque creo que todos vivimos en esta especie de burbuja en este momento. Pero escribir código usando agentes y producir código usando agentes es, ya sabes, la forma en que trabajan, usando patrones en todas partes que ellos vieron estadísticamente, probablemente usarán el patrón más usado. Y en tu caso, este puede no ser el mejor. Y muy a menudo sobrecomplican las cosas. Ellos sobreingenierizan las cosas porque así es como otras personas lo están haciendo. Y así es como nuestros proyectos similares al tuyo se hacen. Así que.

Sí, intenta ser simple, no sobre ingenierices las cosas. Y porque tengo solo un par de minutos, creo que aceleraré un poco. Todo lo que es aburrido es una tarea potencial para el agente. Solo asegúrate de que esté haciendo el trabajo más simple, más simple. Cuando te escuches a ti mismo diciendo, pero podríamos necesitar esto, probablemente no lo necesites, no construyas cosas que pienses que tal vez necesites, solo constrúyelas cuando realmente las necesites. Cuando algo es mágico, definitivamente significa que es complicado.

Si no entiendes eso, probablemente no es simple. Así que deberías entender lo que estás produciendo. {{^}}Si no lo haces, significa que hay algo de magia allí. Así que tal vez solo replantea. Y al final, no caigas en la trampa de usar las herramientas más de moda porque te estás perdiendo de algo. Solo encuentra la herramienta adecuada para el trabajo. Y sí, hay un tiempo y lugar para todo si tienes tiempo. Pero construir cosas solo porque quieres usar la última versión de Kubernetes probablemente no es la elección correcta.

Los fundamentos son tal vez lo último en lo que quiero enfocarme. Son realmente, realmente importantes. Estoy tratando de mencionar los fundamentos en cada presentación que hago porque si no construyes tu casa sobre una base sólida, probablemente colapsará en algún momento. Y hay otro ángulo con esto. Hoy en día, es realmente difícil enfocarse en los fundamentos porque están ocultos en las soluciones que obtienes de la IA. No necesitas entender estructuras de datos. No necesitas conocer algoritmos para construir software.

Y creo que la mayoría del código que se produce hoy en día, desafortunadamente, se hace sin realmente saber qué hay debajo, lo cual a gran escala no es realmente una buena solución. Entiendo que tal vez no necesites conocer los procedimientos básicos en Assembler para escribir un sitio web, por ejemplo, para producir un sitio web. Eso está bien. Pero para mí, la programación no es solo mi trabajo. Es un oficio. Es algo. Es una profesión que tiene historia. Y para hacerlo bien, creo que deberías conocer los fundamentos. Y por supuesto, hay algunas implicaciones prácticas de conocer lo que sucede detrás de escena. Y las implicaciones son que probablemente serás capaz de escribir un mejor prompt porque sabes cómo funcionan las cosas.