Quem eu sou

declaração — identidade técnica, não uma biografia

Não é uma biografia — é uma identidade técnica. O que vem a seguir é como eu trabalho, evidenciado em outros pontos deste repositório.

↳ principalmente opiniões sobre quem pode ser dono do quê

Sou uma engenheira de software cuja carreira evoluiu de implementar interfaces frontend para desenhar sistemas distribuídos. Não otimizo para o número de tecnologias que conheço; otimizo para entender por que os sistemas são construídos do jeito que são.

Gosto de problemas envolvendo arquitetura, sistemas distribuídos, developer experience e engenharia frontend.

filosofia de engenharia

Boa engenharia é, em grande parte, sobre decisões, não sobre código. Trato cada sistema como um conjunto de afirmações que precisam permanecer verdadeiras ao longo do tempo, sobre ownership, consistência e quem tem permissão para computar o quê. Quando essas afirmações são implícitas, os sistemas se desalinham; quando explícitas, permanecem corretos.

Esta base de conhecimento é escrita da forma como acredito que engenharia deveria ser documentada: contexto, restrições, alternativas, decisão, trade-offs. Nunca só o resultado.

evolução de carreira
Hoje
Platform engineering, arquitetura e desenvolvimento assistido por IA
Interessada nos sistemas que tornam outros engenheiros mais rápidos e seguros.
2025
Desenhando sistemas distribuídos
Dynamox. Consistência entre serviços, arquitetura orientada a eventos, ownership.
2024
Construindo sistemas frontend
Design System, arquitetura de componentes, padrões que o time adotou voluntariamente.
2023
Construindo aplicações frontend em produção
Frontend Intern na AQTech. Vue, usuários reais, restrições reais.
2022
Aprendendo desenvolvimento de software profissional
Trabalho freelance sob um engenheiro experiente. Git, code review, disciplina de entrega.
como eu penso
Comece pelos invariantes. Antes de desenhar, escrevo o que nunca pode ser falso, e então escolho a arquitetura que torna violações impossíveis, não apenas improváveis.
Prefira a corretude enfadonha. Um sistema provadamente correto vence um sistema engenhoso, mesmo quando o engenhoso é mais rápido de construir.
Torne a adoção o caminho mais fácil. Padrões, design systems e processos só sobrevivem quando segui-los dá menos trabalho do que ignorá-los.
Decisões são documentos. Se uma decisão não é escrita com suas alternativas, o time vai reabrir essa discussão em seis meses.
pontos fortes
  • —Consistência entre serviços e design de ownership de dados
  • —Transformar conhecimento tácito do time em padrões explícitos
  • —Arquitetura de componentes e design systems
  • —Comunicação técnica escrita
  • —Ownership de ponta a ponta: da proposta à implementação à adoção
problemas preferidos
  • —Sistemas em que múltiplos serviços discordam sobre o mesmo fato
  • —Times que entregam rápido mas não conseguem explicar por que as coisas são construídas do jeito que são
  • —Bases de código frontend que precisam de arquitetura, não de mais componentes
  • —Fluxos de trabalho em que IA pode ajudar sem remover o julgamento humano
atualmente estudando
Sistemas DistribuídosArquitetura de SoftwareDeveloper ExperienceEngenharia Assistida por IAPlatform EngineeringLiderança TécnicaDocumentação de EngenhariaGestão do Conhecimento
“O objetivo não é colecionar tecnologias. O objetivo é entender como tomar boas decisões de engenharia.”