Leo Cavalcante
Staff Engineer no PicPay
Abrindo a nova “temporada“ da newsletter, uma entrevista com uma figura importante da comunidade PHP brasileira, o Leo Cavalcante.
Conte um pouco sobre sua posição atual. Qual é o seu título e que tipo de trabalho você faz geralmente?
Atuo como Staff Engineer na PicPay, trabalho na unidade de serviços financeiros para pessoas físicas, especificamente na squad responsável pela orquestração das transações, chamada Core Transacional. São nossos serviços os responsáveis pelos registros de transações e por fazer aquilo que é comum à todos os produtos transacionais (pix, p2p, boleto, qrcode etc), com coisas como integração com o gateway de adquirentes, movimentações na carteira, validação com anti-fraude, ativar cashback, estorno e por aí vai.
Que tipo de impacto você sente que mais gera na sua posição atual? E como isso é diferente em relação a sua posição anterior?
Hoje sinto que posso colaborar de forma ativa e direta em toda a unidade de negócio, então, inclusive já sendo essa uma das diferenças, é estar ciente de problemas e dores que possam estar acontecendo em mais de uma squad e ser referência técnica para um número maior de pessoas desenvolvedoras dentro dessas squads na hora de tomar decisões com relação à design de software e arquiteturas.
Qual é o percentual de trabalho entre código e liderança que você desempenha hoje? 50/50? Passa mais tempo trabalhando com tecnologia/codando ou mais tempo liderando pessoas?
Não tenho nada mensurando de verdade, então arrisco dizer que é um Pareto, 80 codando e 20 exercendo papel de líder técnico de alguma forma, seja atendendo à reuniões de definição de arquitetura, até calls mais simples e diretas, agendadas por pessoas de uma squad, ou pequenas ajudas pontuais, de forma assíncrona ali pelo Slack mesmo. Então meu tempo hoje é com certeza muito mais com tecnologia/codando, ou ajudando a resolver problemas tecnológicos (forma bonita de dizer bugs), o que eu acho ótimo e é o que me motivou a seguir uma trilha técnica ao invés de gestão. Lido melhor com essa questões tecnológicas do que com pessoas.
Como é um dia normal na sua rotina? Ou como é uma semana normal para você? Quais são suas rotinas principais?
Dependendo da semana, sou o responsável, junto com um pair, pelo deploy e acompanhamento do nosso principal serviço, o monolito/legado, o que curiosamente aconteceu exatamente nessa semana. Depois parto para a famosa daily, ainda tenho mixed-feelings sobre esse rito, mas tô lá sempre participando. A gente tem um espaço entre a daily e o almoço chamado pós-daily que “sempre” tá preenchido, “sempre” temos algum assunto para debater, o que é bem legal, é um espaço interessante, já ajudou a destravar bastante coisa e é facultativo, não atrapalha a sprint.
Na volta do almoço, eu confesso que é um momento que eu preciso pegar no tranco de volta, então geralmente to revisando PRs, respondendo dúvidas pelos canais e DMs do Slack, mapeando próximos passos, coisas assim “mais leves”.
Depois é pau-na-máquina, é o momento que eu consigo ficar muito focado, consigo me concentrar bastante e com exceção das manhãs que não tem deploy, é um dos momentos mais produtivos.
No fim do dia é quando procuro deixar a maioria das reuniões, pra mim é o melhor momento, é o que tem funcionado pra mim até então, é quando já codei o que eu queria no dia (o de hoje já tá pago) é quando tem minha review/retrospectiva, por exemplo e também é o horário que eu deixo reservado para as entrevistas, um trabalho não tão técnico que tenho gostado de colaborar na PicPay é participar do processo de seleção.
Como você mede seu sucesso? Quando somos pessoas desenvolvedoras de software é comum medirmos nosso sucesso pelo número de commits, pull requests, entregas realizadas. Isso mudou de alguma forma em sua posição atual?
Pessoalmente, ainda é sobre entregas e resultados, é numa avaliação, até um pouco subjetiva, no feedback das pessoas que estão perto de mim, mas também entendo, que na minha posição, estou ainda mais próximo dos OKRs da empresa e quanto mais acima nessa trilha, mais perto do que a empresa tem como objetivo é que deve ser a medida a ser buscada.
Então, o que eu diria que mudou é com relação à atuação mais abrangente mesmo, agora os objetivos a serem atingidos são de toda uma unidade de negócio e não apenas de uma squad.
Você participa das decisões de tecnologia ou arquitetura? Como gerencia essa influência em relação aos demais times? Você toma boa parte das decisões ou guia os times para que eles cheguem às conclusões?
Participo, inclusive nessa posição, somos ativamente consultados por outras squads nessas decisões, e sempre procuramos não “tomar” as decisões, mas passar nossa experiência com relação às opções na mesa e em conjunto chegar em uma conclusão sobre qual rumo tomar. Uma coisa que é verdade nessa área é que nada é bala-de-prata. Engenharia é justamente sobre trade-offs, é sobre entender até onde vai uma tecnologia, como ela vai te ajudar e principalmente: onde ela vai te atrapalhar. Gosto de dizer que se a pessoa conhece de verdade uma ferramenta, é porque ela sabe os problemas da ferramenta, não é só sobre o que ela sabe de bom da ferramenta.
Que soft-skills você percebe que fazem a diferença na sua posição? E como eles diferem da posição anterior, como dev senior?
A comunicação ainda é algo que pra mim é primordial, sinto que é o que faz de verdade a diferença pra você seguir evoluindo (até não só nessa área), mas no caso, nesse passo de “pós-sênior” eu vejo que você tem que se comunicar ainda mais do que faz hoje, principalmente com pessoas fora da bolha que você está inserido, pelo menos aqui, essa é a grande diferença, é sobre expandir sua atuação em outras squads, outras tribos, até outras BUs, pra poder ser referência em praticamente toda empresa, e para isso você precisa expor suas ideias, saber colocar bem elas, saber ouvir bem outras ideias (também é super importante), mas basicamente se resume em: comunicação.
Você dedica tempo para mentorar as demais pessoas dos times?
Sim, inclusive aqui na empresa há um programa de mentorias, isso é processo um bem definido, inclusive uma experiência bem legal é sobre fazer pairs com pessoas que acabaram de chegar, tive essa oportunidade, me ajudou bastante, acredito que pude ajudar a pessoa que chegou também e hoje me sinto mais apto a fazer esse tipo de trabalho pra comunidade, não só para outros times, mas também para pessoas de fora da empresa.
Para chegar a esta posição, você entregou algum projeto especial, ou você sente que foi uma progressão pelo conjunto das suas contribuições?
Um misto dos dois, mas acredito que existam projetos que deem mais projeção, no meu caso foram dois trabalhos: o primeiro foi em trazer a Swoole para a PicPay, é uma tecnologia que traz novos ares para o PHP, que é uma das principais stacks da empresa. Inclusive, o trabalho como referência técnica é justamente sobre essa tecnologia, sobre estar presente para as pessoas que tem adotado ela dentro da empresa. O Hyperf é outra tecnologia que trouxemos para a PicPay, conseguimos advogar por seu uso, que fica no lugar do Laravel, que é um framework super popular, e mesmo assim tem muito gente embarcando com a gente, então acredito que foi um case muito legal que ainda tá crescendo bastante e tem potencial enorme.
Outro case foi o uso de OpenTelemetry. Trazendo a Swoole pra casa, descobrimos um pequeno débito técnico, a Swoole não funciona com o APM que a empresa toda usa para observabilidade (“só” esse detalhe), mas ao invés de abandonar a tecnologia, fui atrás de uma forma de tornar possível enviar traces e métricas para nosso serviço de monitoramento, e o salvador da pátria foi o OTel, além de vários outros benefícios, como evitar vendor-lockin, ele também nos ajudou a instrumentar as aplicações feitas em Swoole/Hyperf e enviar os dados para o nosso serviço habitual de observabilidade.
Além de claro, junto desses cases, ainda ser um dos responsáveis e participar ativamente da reconstrução do novo core transacional da empresa, que é uma empresa justamente de pagamentos.
Que dicas você pode dar para quem está decidindo se continua o caminho de desenvolvimento ou se deve ir para a área de gerenciamento de pessoas? O que levou você a escolher pelo primeiro caminho?
Acho que a dica seria ver certinho o que a pessoa gosta com relação a gestão de pessoas, porque isso é muito complicado, o que a galera que foi pro ramo de Tech Manager e Head me contam, me faz sentir mais certeza ainda que fui pra trilha “certa”, pra trilha que tem a ver comigo. Mas não que tenha um desafio mais fácil ou mais difícil, a ideia é tentar se imaginar arrancando os cabelos por causa de pessoas ou por causa de computadores, no meu caso, prefiro me estressar por causa de computadores, não tenho tino para lidar com pessoas e mesmo nas horas vagas eu gosto de lidar com computadores.
Você lembra de algum conselho ou dica que recebeu quando entrou nesta posição e que foi importante para você?
Recebi dicas bem legais sobre livros, o que linka com a próxima pergunta, e sobre atuação externa, o que achei bem interessante, sobre representar de alguma forma a empresa nos lugares, sobre engajar a empresa em comunidades e que é um tema inclusive com discussões sobre um novo archetype para Staffs que é essa pessoa líder de comunidade/relacionamento com desenvolvedores.
Quais fontes você usa para se especializar? Blogs, livros, canais do Youtube.
Newsletters me ajudam bastante, meu feed no Twitter também costuma ser bem rico. Coisas como Reddit também estão sempre bem atualizadas, mas sou daqueles que vai dizer que nada supera um bom livro; das coisas que eu aprendi, que ficaram de verdade enraizadas na cabeça e levo por um bom tempo, é depois de ter lido um bom livro. Nem precisa ser físico, não tenho essa pira, não. Adoro meu Kindle.
Onde as pessoas podem te encontrar? Site, Linkedin, Twitter, etc.
Onde ver meu nome, pode me pingar: