sobre
comecei a programar em 2017, aos dezesseis anos, tentando entender como sistemas quebram. demorei a perceber que entender como quebrar significava primeiro entender como construir.
desde então o trabalho convergiu para uma classe de problema: backends onde errar sai caro. bancos, asset management, seguros e infraestrutura de pagamentos.
como eu trabalho
arquitetura é sobre trade-offs
não sobre frameworks nem sobre organização de pastas. a discussão que importa é o que você está disposto a perder, e por quê.
medir antes de otimizar
e dizer como foi medido. um número sem metodologia não é evidência, é anedota. às vezes a medição honesta mostra que a mudança não fez diferença, e isso também é um resultado.
modelar o domínio primeiro
o banco de dados é uma decisão que vem depois. um core estável e limpo, independente das ferramentas ao redor, é o que permite trocar as ferramentas mais tarde.
tornar a complexidade invisível
sem fingir que ela não existe. a simplicidade que o usuário vê é construída de propósito, e alguém precisa sustentar o que está por baixo.
ofício
eu gosto da ideia de artesanato de software, mas com cuidado. ela descreve bem o modo de trabalhar: atenção ao detalhe, responsabilidade pelo que foi entregue, e a disposição de refazer o que ficou errado.
o que ela não descreve é a parte que mais importa em sistemas críticos, que é a disciplina de engenharia. corretude, tolerância a falhas e reprodutibilidade não vêm de capricho, vêm de método.
sequence
a sequence é a minha prática independente de engenharia. é por meio dela que eu presto serviços, assumo projetos e construo meus próprios sistemas, com foco em backend, infraestrutura financeira e integrações. quando o trabalho é meu, é ali que ele acontece.
contato
disponível para vagas sênior e staff em backend. remoto, aberto a realocação.