Sobre
Engenharia, produto, operação e ensino como partes da mesma prática.
Minha trajetória aproximou código de pessoas: usuários que dependem do sistema, áreas que atendem clientes, empresas que precisam operar e alunos que precisam entender por que uma decisão técnica existe.
O trabalho em produtos reais ensinou que uma decisão técnica raramente começa pela tecnologia. Ela começa pelo uso, pelo risco, pela manutenção e pelo impacto que uma mudança pode causar em quem depende do sistema.
Essa leitura aparece tanto em sistemas em produção quanto em produtos em validação: entender pessoas, problema, negócio e restrições vem antes de escolher uma implementação.
Atuar próximo de suporte, atendimento, produto e negócio torna a engenharia menos abstrata. Uma tela, uma API ou uma migração deixam de ser apenas tarefas técnicas e passam a carregar consequências para uso, venda, atendimento e evolução futura.
Por isso, busco decisões proporcionais: complexidade precisa justificar valor, e uma solução boa precisa continuar compreensível para quem vai mantê-la depois.
A docência reforça uma habilidade central para engenharia: explicar raciocínio. Quando uma decisão não pode ser explicada com clareza, provavelmente ela ainda não foi compreendida o suficiente.
Levar experiências de mercado para a sala de aula também ajuda a transformar conceitos em situações concretas, aproximando formação técnica e prática profissional.
Modernização gradual no Kero Ótica em vez de tratar a troca de stack como objetivo isolado.
Docência, documentação técnica e explicação de decisões para públicos técnicos e não técnicos.
Stack aparece como apoio aos problemas resolvidos, não como argumento principal do portfólio.
Se a conversa envolve decisões com consequências reais, sistemas em evolução ou comunicação técnica, faz sentido começar por aqui.
Costumo responder em até um dia útil.
