Desenvolvedor backend em formação, focado no ecossistema TypeScript/Node.js, graduando em Engenharia de Computação pela UNIVESP e instrutor de TI. Meu interesse não está em acumular frameworks, e sim em entender por que um sistema é organizado de determinada forma, quais problemas essa organização resolve e o que ela custa em troca. A maior parte do que sei veio de construir: pegar um problema real, modelar, errar, refatorar e voltar ao fundamento que estava faltando.
Trabalho principalmente com TypeScript e Node.js, usando NestJS e Express.js, com PostgreSQL como banco relacional. Uso Java com Spring Boot como segunda stack menos por necessidade e mais porque comparar duas abordagens de framework deixa claro quais decisões são do ecossistema e quais são de arquitetura de verdade. Python e Flask aparecem em projetos pontuais, e Docker, Git, GitHub e Linux fazem parte do dia a dia.
Esse trabalho caminha junto com o estudo de APIs REST, princípios de orientação a objetos e, cada vez mais, arquitetura de aplicações, Domain-Driven Design e sistemas distribuídos. Não trato esses temas como itens soltos de currículo: são ferramentas para responder à mesma pergunta, que é como estruturar um sistema que alguém inclusive eu mesmo, seis meses depois consiga entender e evoluir sem reescrever tudo.
Essa é a parte que mais me interessa no desenvolvimento de software e onde estou investindo mais tempo de estudo, não como alguém que já domina o assunto, mas como alguém construindo esse repertório através de projetos práticos.
Na prática, isso significa me preocupar com separação de responsabilidades entre domínio, aplicação, infraestrutura e apresentação, com modularidade e com os contratos e abstrações que definem a fronteira entre as partes de um sistema, e com organizar código por domínio em vez de por tipo técnico de arquivo. Acoplamento e coesão me interessam como critérios reais de decisão, não como definição decorada, e encaro testabilidade como consequência de um bom design, não como etapa extra no fim do trabalho.
Também venho aprendendo a tratar trade-offs com mais honestidade. Boa parte do valor de estudar Clean Architecture, Arquitetura Hexagonal e DDD está justamente em reconhecer quando uma solução simples é a certa e quando adicionar camadas de fato resolve um problema porque a alternativa é complexidade que só parece profissional. Penso em sistemas como algo que vai mudar, não como algo que "termina", e isso muda o que considero uma boa decisão de design.
Além do backend, tenho curiosidade genuína por programação de baixo nível e por entender o que acontece abaixo das abstrações que uso normalmente. C, Rust, Assembly e arquitetura de computadores são espaço de exploração pessoal, não a direção principal da minha carreira mas influenciam bastante como penso sobre o que está acontecendo por baixo do código que escrevo no dia a dia.
Graduando em Engenharia de Computação pela UNIVESP e instrutor de TI, o que me obriga a explicar conceitos de forma clara com frequência inclusive para mim mesmo, quando estou estudando algo novo. Não encaro essa trajetória como um currículo fechado: o que sei hoje sobre backend e arquitetura vem principalmente dos projetos acima, de tentar, quebrar e refazer.
