El 2 de octubre de 2020, se fusionó mi primera solicitud de extracción a un proyecto de código abierto.
No sabía que esto me llevaría a un ascenso a Arquitecto de Sistemas y que hablaría de ello en la Cumbre TLV de AWS en Israel.
En este blog, explicaré cómo esta PR cambió mi carrera y cómo usted también puede avanzar en su carrera mientras mantiene bajo control el equilibrio entre el trabajo y la vida personal.
¿Cómo empezó?
Hola, mi nombre es Ran Isenberg y he estado desarrollando software durante más de diez años.
El 2 de octubre de 2020, fui arquitecto de software en CyberArk, parte del grupo de ingeniería en la nube (más información aquí ), tratando de descubrir mi camino en el mundo de AWS Serverless.
Todo comenzó cuando tuve un problema con la validación de entrada de AWS Lambda y, más específicamente, traté de averiguar cómo analizar y validar diferentes eventos en la función de AWS Lambda. La búsqueda en Google de "mejores prácticas de validación de entrada de AWS Lambda" no arrojó ningún resultado en ese momento, por lo que recurrí a averiguarlo por mi cuenta.
Después de unas semanas, mientras navegaba por GitHub, encontré un excelente repositorio que me llamó la atención: AWS Lambda Powertools for Python . Prometía ofrecer las mejores prácticas para las funciones de AWS Lambda, como el registro, la observabilidad y más. Noté que los ingenieros de AWS lo mantenían, así que sabía que se trataba de un repositorio de nivel profesional.
Revisé sus problemas de GitHub por curiosidad, y hubo un problema de RFC que me intrigó muchísimo.
El problema de RFC describía la necesidad de una utilidad de análisis para validar los eventos entrantes a la función AWS Lambda. Este es el mismo problema que me había preocupado antes y que había resuelto.
Me hizo pensar.
Siempre he oído a gente decir que se debe donar código a proyectos de código abierto. Sin embargo, nunca lo he hecho ni sé por dónde empezar.
Decidí intentarlo. Pensé que sería una experiencia agradable y que no tenía nada que perder.
Publiqué un mensaje en ese número de RFC e inicié un debate. Sugerí mi solución a los encargados del mantenimiento y expliqué por qué era la mejor.
Fueron muy amables y serviciales y querían ver un POC en funcionamiento para poder juzgar la experiencia del usuario.
Después de que mis hijos se fueron a dormir, procedí a clonar el proyecto y comencé a trabajar en ese PR. Dediqué aproximadamente 1 o 2 horas por noche durante una semana hasta que finalmente obtuve un PR verde.
Pasaron varias semanas, se revisaron los códigos y la experiencia del usuario y se acordó fusionar y publicar la PR en la próxima versión. ¡Éxito!
Sentí una enorme satisfacción. Todo ese arduo trabajo dio sus frutos y supe que ahora los desarrolladores de todo el mundo podían resolver el mismo problema con facilidad.
Pero no acabó ahí, ni mucho menos.
Para obtener más información sobre la utilidad del analizador , puede consultar la documentación o mi blog aquí .
El efecto mariposa
Este PR inició un efecto mariposa .
La fusión de las relaciones públicas rompió un muro interno en mi mente. Una oportunidad llevó a otra.
Para donar el código a AWS, tuve que usar sus herramientas y comprender cómo funciona su canalización. Descubrí nuevas herramientas y mejores prácticas con las que no estaba familiarizado hasta entonces.
Decidí utilizarlos en nuestro pipeline, lo que mis gerentes consideraron una excelente iniciativa.
Se me ocurrió una idea para una nueva utilidad, la utilidad de indicadores de características . Se la sugerí al equipo de AWS Lambda Powertools y escribí una RFC. ¡Y listo! Se fusionó otra utilidad.
Continué trabajando con Parser y agregué más compatibilidad con eventos de AWS. Lo entendí y empezó a ser más fácil.
Durante este proceso, conocí desarrolladores y creé conexiones con personas de todo el mundo.
Más tarde, me invitaron a participar en un seminario web de AWS sobre la utilidad del analizador. Nunca había hecho algo así antes y decidí intentarlo, desafiarme a mí mismo y probar algo nuevo .
La experiencia fue estupenda, ¿quién iba a pensar que hablar en vivo sobre código podía ser tan divertido?
Me di cuenta de que ser promotor de desarrolladores es algo que me gusta. Descubrí que disfruto debatir y explicar las utilidades y las mejores prácticas. Así que también presenté las utilidades internamente en CyberArk. Puedes ver las grabaciones de los seminarios web de AWS aquí .
A partir de ese momento, decidí que quería probar cosas nuevas y salir de mi zona de confort para ponerme a prueba. Tenía una lista de cosas interesantes que quería aprender y probar.
Decidí escribir blogs sobre las utilidades que creé para ayudar a difundirlas y desafiarme a mí mismo a hacer cosas nuevas. CyberArk me ayudó con un taller de blogs donde adquirí los conceptos básicos. Sin embargo, escribir blogs es como un músculo: hay que entrenarlo para mejorar.
Así que continué escribiendo sobre mi experiencia con AWS Serverless en mi tiempo libre.
He escrito más de 15 blogs en Medium y aquí, en mi nuevo sitio web, y planeo seguir haciéndolo.
Construyendo una reputación
Cuando escuché sobre el programa AWS Community Builders , supe que tenía que postularme.
Como ya tenía una cartera de trabajos comunitarios relacionados con AWS, como blogs, donaciones de código y seminarios web, me aceptaron en el programa. Este programa fortaleció mi conocimiento de AWS y me ayudó a crear nuevas conexiones con desarrolladores de todo el mundo, lo que me permitió obtener aún más exposición y oportunidades.
En el trabajo, las cosas también cambiaron. Empezamos a utilizar las utilidades que doné internamente en CyberArk y la gente empezó a reconocerme como un asesor de confianza de AWS para las mejores prácticas en funciones AWS Lambda y Serverless.
Entonces, cuando surgió la oportunidad y se abrió un nuevo puesto (un arquitecto de sistemas para mi grupo), presenté mi solicitud y conseguí el trabajo.
Cumbre TLV de AWS
El evento más importante de AWS en el que hablé fue la Cumbre de AWS TLV en mayo pasado. Tuve el placer de presentar la utilidad de análisis frente a una audiencia en vivo, algo que no había hecho durante un tiempo debido a la COVID-19. Fue emocionante y muy divertido, y un pequeño cierre para esa donación de código que lo inició todo.
Creo que mi experiencia demuestra que nunca sabes qué puede pasar cuando te desafías a ti mismo y pruebas nuevas experiencias.
Esta PR me llevó a realizar seminarios web, escribir blogs, hablar en conferencias, convertirme en un asesor de confianza en asuntos de AWS Serverless y, finalmente, a mi ascenso.
Bueno, ¿y tú qué?
Las donaciones de código pueden ser pura diversión. Es una sensación fantástica saber que los desarrolladores usan tu código en todo el mundo y que aporta valor.
Las donaciones de código pueden ser un buen desafío y una forma de aprender algo nuevo.
Las donaciones de código pueden ayudarte a conocer nuevos desarrolladores y crear nuevas conexiones.
Las donaciones de código pueden abrirte puertas, pueden ser un proyecto interesante que puedes discutir en una entrevista de trabajo o ayudar a construir una reputación.
Quién sabe lo que estas oportunidades pueden crear para ti. El cielo es el límite.
Desde una perspectiva personal, puedo decir que las donaciones de código despertaron algo en mí que no conocía. Me enganché. Una vez que superaba un desafío o tenía una nueva experiencia, ya fuera un seminario web o una presentación presencial, quería seguir adelante.
Consejos
Ahora, al mirarlo en retrospectiva, creo que puedo recordar varios consejos que me ayudaron en el camino.
Así que mis principales consejos para ti son:
Sigue planteándote desafíos: sal de tu zona de confort. Prueba cosas nuevas, ya sean donaciones de código, blogs, seminarios web, aprender un nuevo lenguaje de programación, etc. Cada experiencia única es gratificante a su manera.
Sé curioso y trata de mejorar tu oficio y a ti mismo. Siempre puedes aprender algo nuevo de cualquier persona.
Manténte abierto a los comentarios. Las revisiones de código realizadas por desconocidos pueden ser duras. Intenta aprender de todos y no te lo tomes como algo personal.
Mantén una lista de cosas que deseas hacer para que nunca te aburras ni te quedes estancado.
Establece un tiempo en tu agenda para completar el trabajo pendiente. Puede ser de 5 horas o 30 minutos por semana. Lo importante es perseverar, PERO en un horario que se adapte a tu agenda. No lo fuerces ni te esfuerces demasiado. Tu salud mental es más importante que tachar un elemento de tu lista de tareas pendientes.
¡Divertirse!
Nunca se sabe realmente a dónde puede llevar este enfoque.
Podría ser un ascenso, un nuevo trabajo o simplemente una satisfacción total.
Sin embargo, sé una cosa: estas experiencias te ayudarán a crecer como persona y como desarrollador.
Comments