Em 2 de outubro de 2020, minha primeira solicitação de pull para um projeto de código aberto foi mesclada.
Eu mal sabia que isso me levaria à promoção para Arquiteto de Sistemas e que eu estaria falando sobre isso no AWS TLV Summit em Israel.
Neste blog, explicarei como essa RP mudou minha carreira e como você também pode progredir em sua carreira mantendo o equilíbrio entre vida pessoal e profissional.
Como tudo começou
Olá, meu nome é Ran Isenberg e desenvolvo software há mais de dez anos.
Em 2 de outubro de 2020, eu era arquiteto de software na CyberArk, parte do grupo de engenharia de nuvem (mais sobre isso aqui ), tentando descobrir meu caminho no mundo sem servidor da AWS.
Tudo começou quando enfrentei um problema com a validação de entrada do AWS Lambda e, mais especificamente, tentei descobrir como analisar e validar diferentes eventos na função do AWS Lambda. Pesquisar no Google por "melhores práticas de validação de entrada do AWS Lambda" não produziu nenhum resultado naquela época, então recorri a descobrir sozinho.
Depois de algumas semanas, enquanto navegava no GitHub, encontrei um excelente repositório que chamou minha atenção: AWS Lambda Powertools for Python . Ele prometia entregar as melhores práticas para funções do AWS Lambda, como registro, observabilidade e muito mais. Percebi que os engenheiros da AWS o mantinham, então eu sabia que este era um repositório de nível profissional.
Dei uma olhada nos problemas do GitHub por curiosidade, e um problema do RFC me intrigou muito.
O problema do RFC descreveu a necessidade de um utilitário de parser para validar eventos de entrada para a função AWS Lambda. Esse é o mesmo problema que me incomodou antes, que eu tinha resolvido.
Isso me fez pensar.
Sempre ouvi pessoas dizendo como você deveria doar código para projetos de código aberto. No entanto, nunca fiz isso de verdade nem sabia por onde começar.
Decidi ir em frente. Pensei que seria uma experiência agradável e não tinha nada a perder.
Então postei uma mensagem naquele problema de RFC e comecei uma discussão. Sugeri minha solução aos mantenedores e expliquei por que ela é a melhor.
Eles foram muito simpáticos e prestativos e queriam ver um POC funcionando para poderem avaliar a experiência do usuário.
Depois que meus filhos foram dormir, fui clonar o projeto e comecei a trabalhar naquele PR. Passei cerca de 1-2 horas por noite durante uma semana até que finalmente consegui um PR verde.
Avançando várias semanas, revisões de código e revisões de experiência do usuário, o PR foi acordado para ser mesclado e lançado na próxima versão. Sucesso!
Senti uma satisfação imensa. Todo aquele trabalho duro valeu a pena, e eu sabia que desenvolvedores do mundo todo agora poderiam resolver o mesmo problema com facilidade.
Mas não parou por aí, longe disso.
Para saber mais sobre o utilitário do analisador , você pode verificar a documentação ou meu blog aqui .
O efeito borboleta
Este RP desencadeou um efeito borboleta .
Mesclar o PR rompeu uma parede interna na minha mente. Uma oportunidade levou a outra.
Para doar o código para a AWS, tive que usar as ferramentas deles e entender como o pipeline deles funciona. Eu encontrei novas ferramentas e melhores práticas com as quais eu não estava familiarizado até então.
Decidi usá-los em nosso pipeline, o que meus gerentes consideraram uma excelente iniciativa.
Eu tive uma ideia para um novo utilitário, o utilitário feature flags . Eu o sugeri para a equipe do AWS Lambda Powertools e escrevi um RFC. Boom, outro utilitário mesclado.
Continuei meu trabalho com o Parser e adicionei mais suporte a eventos da AWS. Peguei o jeito e começou a ficar mais fácil.
Durante esse processo, conheci desenvolvedores e criei conexões com pessoas do mundo todo.
Mais tarde, fui convidado para participar de um Webinar da AWS sobre o utilitário parser. Nunca tinha feito algo assim antes e decidi ir em frente, me desafiar e tentar algo novo .
A experiência foi ótima, quem diria que falar ao vivo sobre código poderia ser tão divertido.
Percebi que ser um defensor do desenvolvedor é algo que eu gosto. Descobri que gosto de discutir e explicar utilitários e melhores práticas. Então, também fui em frente e apresentei os utilitários internamente na CyberArk. Você pode conferir as gravações dos webinars da AWS aqui .
Daí em diante, decidi que queria tentar coisas novas e sair da minha zona de conforto para me desafiar. Mantive um backlog de coisas legais que queria aprender e tentar.
Decidi escrever blogs sobre os utilitários que criei para ajudar a espalhar a palavra sobre eles e me desafiar a fazer coisas novas. A CyberArk me ajudou com um workshop de blogs onde aprendi o básico. No entanto, escrever um blog é como um músculo; você deve treiná-lo para melhorar.
Então continuei escrevendo sobre minha experiência com o AWS Serverless no meu tempo livre.
Já escrevi mais de 15 artigos no Medium e aqui, no meu novo site, e pretendo continuar.
Construindo uma reputação
Quando ouvi falar do programa AWS Community Builders , soube que tinha que me inscrever.
Como agora eu tinha um portfólio de trabalho comunitário relacionado à AWS, como blogs, doações de código e webinars, fui aceito no programa. Este programa fortaleceu meu conhecimento sobre AWS e me ajudou a criar novas conexões com construtores ao redor do mundo, o que levou a ainda mais exposição e oportunidades.
No trabalho, as coisas também mudaram. Começamos a usar os utilitários que doei internamente na CyberArk, e as pessoas começaram a me reconhecer como um consultor confiável da AWS para melhores práticas em funções AWS Lambda e Serverless.
Então, quando surgiu a oportunidade e uma nova vaga apareceu - Arquiteto de Sistemas para o meu grupo, me candidatei e consegui o emprego.
Cúpula AWS TLV
O maior evento da AWS em que falei foi o AWS Summit TLV em maio passado. Tive o prazer de apresentar o utilitário parser para uma audiência ao vivo, o que não fazia há algum tempo devido à Covid-19. Foi emocionante e muito divertido e um pouco de encerramento para aquela doação de código que deu início a tudo.
Acredito que minha experiência prova que você nunca sabe o que pode acontecer quando você se desafia e tenta novas experiências.
Esse RP me levou a fazer webinars, escrever blogs, falar em conferências, me tornar um consultor confiável em questões do AWS Serverless e, por fim, à minha promoção.
Certo, e você?
Doações de código podem ser pura diversão. É uma sensação fantástica saber que os desenvolvedores usam seu código em todo o mundo e que ele fornece valor.
Doações de código podem ser um bom desafio e uma maneira de aprender algo novo.
Doações de código podem ajudar você a conhecer novos desenvolvedores e criar novas conexões.
Doações de códigos podem abrir portas para você; podem ser um projeto legal que você pode discutir em uma entrevista de emprego ou ajudar a construir uma reputação.
Quem sabe o que essas oportunidades podem criar para você. O céu é o limite.
De uma perspectiva pessoal, posso dizer que as doações de código acenderam algo em mim que eu não sabia que existia. Fiquei fisgado. Depois que conquistei um desafio ou tive uma nova experiência, seja um webinar ou uma apresentação frontal, eu queria continuar insistindo.
Pontas
Olhando para trás agora, acho que consigo lembrar de várias dicas que me ajudaram ao longo do caminho.
Então minhas principais dicas para você são:
Continue se desafiando - saia da sua zona de conforto. Tente coisas novas, sejam doações de código, blogs, webinars, aprender uma nova linguagem de programação, etc. Cada experiência única é gratificante à sua maneira.
Seja curioso e tente melhorar a si mesmo e sua arte. Você sempre pode aprender algo novo com qualquer um.
Esteja aberto a feedback. Revisões de código de estranhos podem ser duras. Tente aprender com todos e não leve para o lado pessoal.
Mantenha uma lista de coisas que você quer fazer para nunca ficar entediado ou preso.
Defina um horário na sua agenda para cumprir o backlog. Pode ser 5 horas ou 30 minutos por semana. O importante é continuar, MAS em um horário que se encaixe na sua agenda. Não force ou se esforce demais. Sua saúde mental é mais importante do que riscar um item do seu backlog.
Divirta-se!
Você nunca sabe realmente onde essa abordagem leva você.
Pode ser uma promoção, um novo emprego ou apenas satisfação.
No entanto, sei de uma coisa: essas experiências ajudarão você a crescer como pessoa e desenvolvedor.