Augusto Pascutti

Engenheiro Principal na Kobold

Esta semana tenho o prazer de apresentar a entrevista de uma pessoa que é uma das minhas referências técnicas, e um dos meus amigos mais antigos. Ele me deu uma bela garrafa de whisky quando minha filha nasceu :) Com vocês, Augusto Pascutti.

Conte um pouco sobre sua posição atual. Qual é o seu título e que tipo de trabalho você faz geralmente?

Hoje estou Engenheiro Principal na Kobold, uma gestora de fundos digital. Gosto de pensar que, apesar de achar uma generalização falha, minha responsabilidade seja postergar decisões. No dia-a-dia ela se apresenta de formas diferentes, dependendo do grupo de pessoas com quem me relaciono.

Com a parte estratégica da empresa, Diretores, Conselho etc., minha atenção está na capacidade arquitetural existente e o que ela pode oferecer. Quais problemas iremos sofrer no futuro? Às vezes essas conversas ajudam a definir um público alvo diferente para as primeiras iterações de produto, declaram falta de capacidade ou sugerem um custo de implementação.

No âmbito tático, com time de Produto e líderes técnicos, ajudo a priorizar as iniciativas. Contribuo identificando oportunidades de resolver mais problemas com a mesma quantidade de esforço, faço isso através de provocações em cerimônias e manutenção do backlog.

Com o time de desenvolvimento, garanto que todos entendam quais mudanças arquiteturais estamos fazendo e para onde estamos indo. Amplificando o trabalho de todos através da coesão de esforços. Isso ocorre em revisões de código, planejamento de ciclos de desenvolvimento, análise e refinamento de estórias e conversas mais informais.

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?

O maior impacto que posso produzir é manter as expectativas de desenvolvimento e produto alinhadas. Para os desenvolvedores isso significa clareza de quanto tempo eles têm para trabalhar em uma solução. Com o time de produto antecipo onde precisaremos de mais esforço, às vezes são métricas de performance que irão mudar, às vezes são mais bugs ou defeitos que irão aparecer.

O que mais mudou com minha experiência foi minha definição de “boa solução”. Enquanto desenvolvedor, me preocupava mais com a qualidade técnica do que com a performance do produto. Hoje busco o equilíbrio entre as duas coisas. Esse equilíbrio vem, principalmente, da distinção entre uma PoC (Proof of Concept), um MVP (Minimum Viable Product) e um produto maduro.

Uma PoC pode, por exemplo, ser um e-mail ou relatório em CSV para ser importado no Excel. Qualquer solução, desde que ela possa ser medida e gerar aprendizado, é válida. O que ocorre, pela minha experiência, é que se gasta muito esforço muito cedo, em uma solução que ninguém sabe se vai funcionar. Isso frustra todo o time. O time de produto perde o controle das prioridades e o de desenvolvimento isola uma parte da base de código e chama de “legado”.

Tento evitar frustrações através de uma arquitetura que seja aderente ao time. Impedindo que PoCs e MVPs a definam, seja porque sobreviveram tempo demais ou porque a experiência de trabalhar com código antigo seja ruim demais.

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?

80% do meu tempo é dedicado à liderança. Ao contrário do que eu esperava antes de estar nesta posição, essa liderança é mais sobre servir o time do que definir o que ele deve ou não fazer.

Meu foco está em garantir que o esforço do time esteja sendo bem empregado. Que ele tenha tempo para focar no próprio trabalho e que esse trabalho seja o menos repetitivo possível.

Como é um dia normal na sua rotina? Ou como é uma semana normal para você?  Quais são suas rotinas principais?

Gosto de manter as manhãs para mim e as tardes para o time. Uso as manhãs para organizar prioridades, delegar o que posso e acompanhar o que está acontecendo com a base de código. Nas tardes participo e organizo cerimônias recorrentes de controle do backlog,  priorização e arquitetura. Me comunico bastante com o time durante o Code-Review, discuto as soluções, refactors em andamento, oportunidades de melhoria e clareza.

Uma semana normal tem 20% de reuniões recorrentes e 30% de reuniões únicas e esporádicas. Um dia normal eu leio/respondo/envio e-mails, zero notificações do GitHub, dou um “git log” depois de um “git fetch” em todos os repositórios e me preparo para todas as reuniões do dia.

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?

Se ninguém se preocupa com a arquitetura, não porque ela não é importante mas porque ela não é um problema, julgo que estou fazendo um bom trabalho. Se ninguém usa o termo “legado” para nada, significa que a arquitetura está sob controle. Se pessoas não desenvolvedoras se preocupam com “código legado” e/ou “débito técnico”, falhei miseravelmente.

Sucesso é ter um time confortável e produzindo impacto. Me conforta, porém, associar a opinião do time à métricas. Minha visão sobre o Git, por exemplo, é de que ele é uma ferramenta de comunicação, e como tal oferece várias oportunidades de observação. Ter mais adições que subtrações de código, num longo período de tempo, pode significar ausência de refactors. Com Git dá para saber se existem silos de informação, se o tamanho (complexidade) dos commits está aumentando ou diminuindo, quais partes do código concentram muita responsabilidade etc. Além do Git, gosto também de métricas de produtividade do time. O time se ofende mais com incerteza ou com defeitos? Existe correlação entre eles?

Apesar de valorizar métricas, como disse, eu valorizo mais o conforto do time. Cada time é um time, por isso “sucesso” pode significar coisas diferentes. Na EasyTaxi, me orgulho de, num time de 80 pessoas, atendendo 300k req/sec, todo mundo poder fazer vários deploys num dia, a qualquer hora, e ninguém precisar estar de plantão. Hoje, na Kobold, gosto do fato de todo desenvolvedor contribuir com regras de negócio. São times diferentes, em contextos diferentes, com necessidades diferentes. Se estivermos todos confortáveis, entregando valor de negócio e melhorando continuamente, o sucesso é inevitável.

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?

É minha maior responsabilidade. Guio, organizo e registro as discussões necessárias mas, mais do que guiar e contribuir com decisões técnicas e arquiteturais, eu procuro garantir que todo mundo entenda e se comprometa plenamente com as decisões do time.

Como desenvolvedor, já implementei soluções técnicas ótimas mas que ninguém expandia ou utilizava. Aprendi que uma solução medíocre, que todo mundo entenda e utilize, é melhor do que uma que todo mundo evita por causa da complexidade. Em uma cultura de melhoria contínua, é muito provável que soluções medíocres sejam melhoradas até que se tornem ótimas. Enquanto soluções ótimas, que são úteis só para alguns poucos, não costumam entregar tanto valor. A arquitetura para mim, hoje, é mais sobre aprendizado e comprometimento do que uma sopa de letrinhas.

Isso não significa que minha experiência influencia pouco na arquitetura e tomada de decisões. Minha opinião costuma ter mais importância do que eu gostaria, mas eu só exercito minha influência quando sei que alguma solução irá alienar uma parte do time. Meu trabalho está muito mais para um carteiro e mediador do que para um arquiteto em um palácio de prata.

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?

Quem desenvolve um produto são as pessoas, não tecnologias. Saber se comunicar se torna cada vez mais importante à medida que sua experiência aumenta. Na minha posição atual ela é essencial, praticamente todas as minhas falhas profissionais têm origem em um problema meu de comunicação.

Maturidade emocional é essencial também. É fácil confundir uma crítica, ou problema, de algo que você fez como um ataque pessoal. A parte boa de trabalhar com código, uma ciência, é que opiniões são irrelevantes. A parte ruim é esquecer que isso tudo envolve pessoas.

Você dedica tempo para mentorar as demais pessoas dos times?

Sim. Mas isso raramente ocorre em conversas formais, recorrentes e cumprindo um roteiro. É bem mais comum eu apresentar um conceito durante um Code-Review, e dessas apresentações surgirem outras PRs e conversas.

Minha preocupação está mais voltada a criar e manter um ambiente onde todos estejam confortáveis para criticar e serem criticados. Um local onde o erro é uma oportunidade de aprendizado, e pedidos de ajuda são cotidianos. Uma arquitetura excelente é consequência da colaboração do time, reflexo do aprendizado dos esforços desprendidos. Não de um desenho, nem da ideia de um grupo limitado de pessoas. Uma casa em ordem só existe se todo mundo que mora nela colabora com a manutenção dela.

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?

Sinto que foi uma progressão. Tive muita sorte na minha carreira, fui exposto ao Open Source e a grupos de usuários muito cedo. Essa troca e exposição de experiências foi essencial para o meu desenvolvimento técnico e profissional. 

Aprender a discutir de maneira abstrata, ter acesso a pessoas mais experientes que eu, ter referências reais, tudo isso fora das minhas experiências profissionais, me manteve bastante confortável em toda essa jornada.

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?

Minha escolha foi sempre pelo meu conforto, acho que isso foi e continua sendo bem importante. Eu sempre achei mais fácil escrever código do que interagir com pessoas, então ir para o âmbito técnico foi bem natural.

A dica que dou é a de não negligenciar as interações com as pessoas. Durante muito tempo eu achei que, se fosse a pessoa com mais conhecimento, os outros seriam obrigados a me consultar e seguir. Isso só me frustrou e estressou os demais, sem necessidade. Apesar de estar em uma posição extremamente técnica, a maior parte do meu conhecimento é expresso e utilizado por outras pessoas. O impacto que eu consigo gerar através delas é exponencialmente maior do que eu conseguiria gerar sozinho.

Sinto, porém, que devo compartilhar uma frustração com quem quer seguir o mesmo caminho. Existem mais posições de gestão, na Carreira em Y, do que técnicas. Minha opinião, hoje, é de que ainda é mais fácil ascender profissionalmente numa carreira de gestão. O cenário está mudando e mais vagas puramente técnicas têm aparecido, mas elas parecem existir em bem menos quantidade, e num grau de maturidade menor, do que as de gestão.

Que conselho você daria para alguém querendo chegar a essa posição?

Aguardar o tempo necessário para enxergar as consequências das suas decisões. É bem comum, em tecnologia, o profissional ficar menos de 1 ano em uma empresa. É difícil produzir algum trabalho de impacto, em um time, em menos de 1 ano. Mais difícil ainda avaliar se o que você fez foi bom para o produto. Eu conheço muitos profissionais que confundem algo funcional com algo bom, aumento salarial com recompensa por um trabalho bem feito.

Falta, na grande maioria dos profissionais, avaliação crítica do próprio trabalho e do próprio conhecimento. Estão acostumados a obter conhecimento de segunda mão (blogs, palestras, cursos etc.) e a apreciar soluções mais novas em detrimento de estáveis. Produtos inteiros compostos de ideias obtidas de palestras, cursos ou frameworks novos, que negligenciam arquitetura, são muito comuns. Costumo ter um teste fácil para medir a qualidade da arquitetura do seu produto: E se todo ele fosse substituído pelo Excel?! Se um conjunto de planilhas for melhor que um software customizado, você tem um problema sério de arquitetura. Resultado, provável, de acreditar em uma bala de prata.

O melhor conselho, para todo profissional, é o treino. Temos vários produtos Open Source, que são utilizados mundialmente, abertos à contribuição. Se envolver com um projeto que você se identifique é mais fácil do que parece. É muito mais fácil, por exemplo, contribuir com o Wordpress, Debian, Firefox e impactar milhões de pessoas sem nenhuma experiência profissional do que gerar o mesmo impacto profissionalmente. Ter essas referências, de impacto gerado, são essenciais para o aprendizado técnico porque te oferecem conhecimento. Esse conhecimento será útil para discernir onde melhor investir seu tempo no futuro.

Quais fontes você usa para se especializar? Blogs, livros, canais do Youtube.

Prefiro ler. Gosto do pensamento bem sintetizado e estruturado, que posso consumir no meu tempo e da maneira que achar mais confortável. Não sei se é uma opinião ou não, mas julgo que seja mais fácil encontrar qualidade em livros. Um livro técnico, com opiniões ou muito repetitivo, geralmente é ruim. Não se pode dizer o mesmo sobre blogs e vídeos.

Com livros, procuro sempre ler os autores originais de conceitos importantes para nossa área. Prefiro, por exemplo, o livro do Gang of Four a um de Patterns em determinada linguagem. Primeiro por questão de vocabulário, depois porque conceitos abstratos são essenciais. Ler alguns livros mais de uma vez é útil também. Aprendi coisas diferentes lendo o mesmo livro em momentos diferentes da minha carreira.

Costumo acompanhar projetos também, especialmente as discussões. Além do conteúdo técnico ser muito rico, sei o que é uma boa discussão técnica, quais tipos de decisão existem, formas de governança etc. Acompanhar a evolução do código e resolução de bugs me ensinou muito também. Quando tenho contato com uma linguagem nova, por exemplo, sempre procuro me familiarizar com a comunidade dela e como ela está estruturada. Apesar de serem ecossistemas enormes, elas costumam ser movidos por poucas pessoas. Aprender a identificar essas pessoas facilita muito o acompanhar o que é importante.

Leio bastante documentos de especificação também. Sejam elas de linguagem, como as PEPs do Python e JSRs do Java, ou de padrões como as RFCs do IETF. São uma aula do que uma excelente solução técnica é e dos problemas que existem. Saber quais problemas existem, e como eles são resolvidos, é essencial para produzir uma boa arquitetura. Habilita sua arquitetura a consumir e se integrar com soluções existentes, dando velocidade e estabilidade.

Por último, mas não menos importante, leio bastante código. Quando comecei a trabalhar com C#, há 2 anos atrás, investi algumas horas entendendo como o AspNetCore implementa algumas coisas para aprender mais sobre a linguagem e ecossistema. Nos meus primeiros contatos com uma linguagem, sempre busco bons exemplos de código antes de sair escrevendo. Meu objetivo, nesses primeiros contatos, não é me aprofundar em conceitos que não conheço. Quero ter ideia do tamanho do horizonte todo, para conseguir organizar meus estudos e práticas futuras. Fica mais fácil, com isso, saber quais decisões arquiteturais estou seguro em postergar e quais preciso me aprofundar primeiro.

Prefiro a leitura por causa da abundância de informação de qualidade que existe. Quanto mais leio, mais fácil fica de identificar bons materiais. Como desenvolvedor, eu leio muito mais código do que escrevo. Ler, para mim, é natural.

Onde as pessoas podem te encontrar? Site, Linkedin, Twitter, etc. 

Eu costumo centralizar todas as iniciativas que abandono no https://about.me/augustohp. Se você quiser falar comigo, o Twitter é o lugar mais fácil. Tive várias ideias no GitHub, minhas mensagens de commit costumam ter explicação de muitas delas. 

Você pode me encontrar como `augustohp` ou “Augusto Pascutti” em todos os demais lugares, que eu quiser ser encontrado. Leia, code e, sobretudo, não entre em pânico.