Bruno Rocha
Principal Software Engineer na Red Hat
Nesta edição a participação de uma pessoa que eu sou muito fã. O grande Bruno Rocha, expoente da comunidade Python e Rust, Principal Software Engineer na Red Hat.
Conte um pouco sobre sua posição atual. Qual é o seu título e que tipo de trabalho você faz geralmente?
Sou Principal Software Engineer na Red Hat, trabalho na empresa já tem 7 anos e estou a 3 anos desenvolvendo a plataforma Ansible Automation especificamente no serviço de repositório de Ansible collections.
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?
Eu sinto que na minha posição atual eu tenho maior responsabilidade sobre as decisões criticas do projeto, atuando como Senior anteriormente eu tinha o papel mais focado em assumir a opinião de alguém de nível superior, eu tinha sim a oportunidade de participar das análises e todo o processo de design das soluções, porém o maior foco era em transformar a decisão estratégica em implementação via código, agora percebo que este trabalho de transformar a estratégia em solução passa por mais camadas além do código.
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?
Hoje eu dedico apenas uns 30% do meu tempo a escrever código, a maioria do meu tempo é dedicado em articular conexões e conversas entre pessoas do time ou outros projetos dentro da empresa, lidar com customer cases, participar de reuniões, redigir e revisar documentos de arquitetura e decisões e revisar código.
Como é um dia normal na sua rotina? Ou como é uma semana normal para você? Quais são suas rotinas principais?
Eu sempre tenho entre uma e duas features/epics em que estou trabalhando, portanto, no Jira sempre vai ter esses cards na minha coluna “Em Progresso”, o trabalho com features envolve muita reunião, testes manuais, validação de ideias e é sempre algo que carrego durante muitas semanas (às vezes até meses), nós não usamos o conceito de sprints, mas dentro de cada feature epic temos as tarefas individuais que servem de indicador de progresso.
Além das big tasks sempre estou envolvido em alguma task com escopo menor como, por exemplo, a solução de algum problema priorizado para um cliente, um bug, contribuir com alguém do time na resolução de algum problema, mentoria ou onboarding além das tarefas de rotina como triagem, débito técnico e code reviews.
Como meu time está praticamente todo nos Estados Unidos e eu moro na Europa, temos uma boa diferença de time zone, então eu uso meu horário da manhã para resolver coisas pessoais como levar filho a escola, atividades familiares, compras, exercícios, estudos particulares e criação de conteúdo para meus canais.
Logo após o almoço, 13h de Portugal, eu de fato começo a trabalhar, começo meu dia organizando a minha lista de tarefas, eu mantenho um work-log em formato markdown aonde vou anotando tudo que eu faço em cada dia, as pessoas com quem falei e as tarefas que vão acumulando, antes eu usava um arquivo de texto e editava no vim, mas recentemente comecei a usar o Obsidian que já tem essa funcionalidade built-in e me ajuda muito, portanto começo meu dia colocando esse documento em ordem, transformando as tarefas inacabadas do dia anterior em novas tarefas, enviando as mensagens, e-mails e invites que preciso enviar e atualizando situação em Jira e Github e isso leva mais ou menos 1 hora.
Quando dá 14h em Portugal é entre 9 e 10 da manhã para as pessoas do meu time e é nesse período que acontecem as primeiras reuniões e minha tarde é praticamente cheia com reuniões de segunda a quinta (sexta é meeting free), entre daily com o time, sync com outros times, product check-in, reunião com cliente e 1:1s se vai toda a minha tarde, portanto fico até as 16h, às vezes 17h em reuniões e conversas e após isso faço uma pequena pausa, às vezes preciso ir buscar o meu filho na escola e volto ao computador por volta das 18h e então é quando finalmente dedico 2h do meu dia a escrever código, o meu objetivo é sempre trabalhar no máximo até as 20h, mas às vezes quando me empolgo acabo ficando um pouco mais.
As sextas-feiras são um pouco diferente, pois não temos reuniões da empresa, uma vez por mês a sexta é day-off (chamamos de RechargeDay), eventualmente a sexta será dedicada a algum evento sincronizado na empresa como test-day ou learning day, mas eu como mantenho um projeto open-source considerado critico no ecossistema Python tenho a minha sexta-feira livre para trabalhar no desenvolvimento da biblioteca Dynaconf, um projeto pessoal open-source que comecei antes de entrar na Red Hat.
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?
Eu antes me importava muito com essas métricas como número de commits, projetos mantidos, tasks fechadas, etc. mas hoje vejo de forma bem diferente, a minha carreira extrapola a empresa para quem eu trabalho, portanto, eu não costumo medir meu sucesso apenas pelas coisas que desenvolvo na Red Hat, eu tenho uma boa participação na comunidade open-source especialmente relacionadas a Python e Rust, crio conteúdo educacional e gosto muito de participar de eventos e disseminação livre de conhecimento, para mim esses indicadores de “sucesso” hoje tem um valor muito grande, quando percebo o impacto do meu trabalho seja na vida e aprendizado de alguma pessoa ou na aplicação de algo que ajudei a construir na solução de problemas reais.
Recentemente fiquei sabendo que a Intel tem um framework de testes de processadores que usa a lib de configurações que criei, é uma sensação boa saber que meu código roda para testar cada novo modelo de processador que será usado por pessoas em todo o mundo, um impacto global, bom, não ganho nada diretamente com isso, mas a sensação é boa.
Outro exemplo que dá esse sentimento de sucesso é quando pessoas que assistem meus vídeos e cursos me mandam mensagem dizendo que concluíram um projeto ou que arrumarem um emprego com ajuda do conhecimento que compartilhei.
Dentro da empresa nós temos um sistema de Desempenho & Desenvolvimento onde alinhamos de tempos em tempos nossas metas e objetivos, não é ninguém superior que dita os itens desse plano, somos nós mesmo que definimos desafios para nosso desenvolvimento e colaboração com as estratégias da empresa e é claro que alinhamos isso com o plano de carreira.
Na empresa eu percebo o sucesso quando vejo que alguém que eu mentorei no início da carreira recebe reward ou promoção, quando alguma feature que ajudei a planejar ou codificar aparece nos indicadores de uso nos clientes, com impacto significativo na evolução dos projetos e faturamento da empresa e obviamente quando isso se reflete em awards e bônus.
E difícil mensurar com números de commit, pois recentemente trabalhei em projetos importantes, desempenhando um papel significativo e sem escrever quase nenhuma linha de código, só atuando na camada de liderança e decisões
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?
Na Red Hat temos um framework de decisões chamado open-decision-framework, resumindo, qualquer pessoa dentro da organização pode influenciar ou propor seguindo um sistema inclusivo e abrangente, não é preciso ter um título específico ou nível dentro da hierarquia, desde que faça sentido dentro dos objetivos estratégicos da empresa claro.
Mas posso dar um exemplo, recentemente comecei a trabalhar em um novo componente de gestão de Feature-Flags para a plataforma Ansible que envolve 8 projetos, eu trabalhei fazendo System Design da arquitetura e eu mesmo decidi a abordagem e componentes, escolhi qual tecnologia de caching usar entre outras coisas, claro que tomei essas decisões de forma responsável e conforme as capacidades que já temos dentro da organização, esse processo se deu na prática com muita pesquisa, conversas diariamente com outros membros dos times envolvidos e então eu propus um ADR (Architecture Decision Record), um documento, com a intenção de registrar uma decisão significativa de arquitetura, uma vez submetida essa proposta passou por uma bateria de revisões envolvendo times especializados em desempenho, segurança, etc. até que após alguns ajustes foi aprovado e é um dos epics que tenho pendurado no meu Jira, onde eu vou atuar como líder da feature, mas vou envolver outras pessoas desenvolvedoras no processo.
Eu não tomei a decisão sozinho, mas segui um processo que permitiu que minha decisão fosse em boa parte considerada até o final da aprovação do projeto.
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?
Definitivamente a comunicação é a parte essencial, saber escrever razoavelmente bem, em inglês, saber a entonação a usar em conversas, saber como conduzir uma reunião.
Também posso mencionar a skill de organização, para mim está sendo um dos principais desafios, pois como programador sempre fui um pouco “desligado” e hiper focado em código, mas quando precisamos atuar em camada de liderança envolvendo diversos times, fuso horário e culturas precisamos acima de tudo ser organizados para facilitar a comunicação, não dá mais para esquecer de enviar aquela mensagem importante, de fazer o release de um pacote essencial, de marcar a reunião, de anotar os itens de ação após uma reunião, etc.
Outra coisa que eu tenho trabalhado e que considero essencial é o desapego individual, passar a analisar os problemas com uma visão mais ampla, não é só o seu time, é a companhia inteira e às vezes até a comunidade ou industria inteira que pode ser afetada por uma decisão, não dá para se apegar a opiniões, gostos, práticas, stacks, linguagens, etc., é preciso desapegar e nortear o seu trabalho conforme os objetivos estratégicos da empresa e da comunidade.
Você dedica tempo para mentorar as demais pessoas dos times?
Sim, desde que entrei na empresa como Senior eu sempre estou envolvido em alguma mentoria com iniciantes ou estagiários que começam na empresa, além disso, participo bastante das iniciativas educacionais dentro e fora da empresa e acredito que o processo de code review pode funcionar também como mentoria e eu sou bastante detalhista em meus code reviews.
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?
Foi uma progressão do conjunto das minhas contribuições, como trabalho com open-source e toda a empresa está baseada em open-source é comum que nosso trabalho tenha impacto global, mas o que me levou a promoção foi analisar as estratégias da empresa, alinhar minhas atividades com essas estratégias e me envolver em projetos de grande impacto tanto para a comunidade, como a biblioteca Python que citei e é usada em milhares de projetos mas também o resultado obtido por pessoas que passaram por minha mentoria e o feedback de clientes da empresa a respeito de features que ajudei a desenvolver, vale citar também que o comportamento pró-ativo é uma das coisas que te leva para um nível maior de confiança em seu time, assumir desafios, mesmos aqueles desafios chatos que ninguém quer, mas que causam um grande impacto no time ou projeto é algo bem-visto.
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?
Em 2010 eu tive a experiência de me tornar gerente de um time de desenvolvimento e foram os piores 6 meses da minha carreira, eu admiro muito o papel de um bom gerente, um gerente líder, e depois dessa experiência eu entendi o que é uma tarefa muito difícil em níveis que fogem um pouco a minha compreensão, deixo aqui minha admiração por todos os bons e boas gerentes, mas descobri que não é para mim, e como eu funciono muito melhor quando meus objetivos estão baseados em plataformas mais técnicas voltei a ser Senior Developer e procurei me especializar em algumas tecnologias visando manter minha empregabilidade, relevância e motivação.
A minha dica é procurar primeiro a motivação, pois ela é o combustível para continuarmos trabalhando, ela pode vir de diversos fatores juntos ou isolados, pode ser realização pessoal, gosto por uma atividade ou simplesmente financeira, ou status, não tem problema qual a fonte da motivação desde que ela seja constante.
A minha motivação é gosto pela atividade, eu realmente gosto de programar e discutir temas técnicos, explorar novas linguagens e tecnologias, dedicar horas, dias, meses implementando ou só estudando esses temas, como não sou ligado em games ou cultura pop costumo dizer que programação é o meu entretenimento, no trabalho uso Python para ganhar dinheiro, no tempo livre estudo Haskell ou Rust, só por diversão.
Uma vez que tenha a motivação bem estabelecida, eu aconselho ter um plano, pois “a potência não é nada sem o controle”, tenha um roadmap de carreira, uma pessoa mentora, uma posição, empresa ou vaga que almeja ocupar e se organize para ir atrás disso.
E por fim, uma sugestão mais pessoal, planeje sua carreira estrategicamente, eu quando desisti de ser gerente conheci a carreira em Y e depois a carreira em T, investi na carreira em T onde formei uma base central extensa e sólida e nas 2 hastes coloquei conhecimentos generalistas superficiais, consigo hoje atuar em vários ambientes, pois não sou apenas alguém especialista em back-end ou Python, tenho alguma vivência em outros ambientes como vendas, ensino, front-end, segurança, devops, testes, etc. A diversidade ajuda a se comunicar e a base sólida te torna um ponto de confiança.
Agora estou adaptando a carreira em T, costumo brincar que até agora era a carreira em “tesão” e estamos caminhando para a carreira em “tesinho”, mas para usar um nome melhor chamei de “Seesaw Carrer”™ (carreira em gangorra), eu acredito que com a recente adição de assistentes de IA em nossa vida a base do T vai achatar, se antes a base tinha pelo menos 10 conhecimentos sólidos (O.S, Linux, Redes, Data bases, uma linguagem, um framework, abordagens, padrões, protocolos etc) e as hastes do T continham dezenas de conhecimentos superficiais (mais linguagens, mais frameworks, vendored services, ferramentas) na nova carreira gangorra a base vai ficar menor, o conhecimento que vai formar a base será o fundamental apenas, boa base de lógica computacional, cloud computing, APIs e algumas soft skills e, ao mesmo tempo, as hastes do T vão ficar mais longas e teremos que adicionar muito mais conhecimento superficial em nossa bagagem, eu diria que o profissional do futuro terá a base sólida e mais centenas de conhecimentos superficiais para interagir com as ferramentas, não dá mais para ser especialista em uma só linguagem, tem que colocar superficialmente várias na bagagem, o mesmo com frameworks e ferramentas, é claro que o papel do especialista, autoridade nos assuntos vai continuar sendo importante, mas em menor escala, a grande massa de trabalho será para generalistas.
Mas isso sou eu praticando futurismo, não me leve tão a sério!
Você lembra de algum conselho ou dica que recebeu quando entrou nesta posição e que foi importante para você?
Sim, um amigo me disse, faça contatos, seja gentil com as pessoas, participe de iniciativas colaborando de verdade sem esperar retorno imediato, você não tem ideia do que isso vai te trazer no longo prazo, e de fato todo tipo de participação e compartilhamento de conhecimento e novo contato que fiz na carreira teve um valor difícil de medir.
Quais fontes você usa para se especializar? Blogs, livros, canais do Youtube.
Não sou um ávido leitor, eu gosto muito de livros, leio bastante, mas de uma forma diferente, acho que tenho algum deficit de atenção e não consigo ler um livro inteiro, portanto tenho uma coleção de livros que fico revisitando de tempos em tempos, buscando referência, problemas específicos ou coisas que estou mais motivado a ler.
Eu tenho uma metodologia meio caótica para o meu aprendizado, apesar de eu ser professor e me dedicar muito a ter uma boa didática, eu mesmo não consigo aprender de forma organizada, então eu acabo “batendo cabeça”, tentativa e erro, assisto muitos vídeos, leio textos parciais e uma hora absorvo o conhecimento, não recomendo isso a ninguém, pois consome tempo e energia, mas é o que funciona para mim.
Eu dei uma filtrada nas fontes de conteúdo que consumo e hoje tenho uma seleção de canais do YouTube que acompanho, alguns blogs que leio regularmente e sempre estou de olho no Reddit e HackerNews, além é claro da bolha dev do twitter/Mastodon que apesar das tretas sempre tem conteúdo interessante.
Blogs/Newsletters
Livros
Fluent Python
Rust for Rustaceans
Canais
Onde as pessoas podem te encontrar? Site, Linkedin, Twitter, etc.
@rochacbruno em todos os lugares, sou mais ativo no Twitter, Bolha.us e Youtube.
Honrado de participar dessa entrevista, obrigado pelo convite