Como uma Crítica Construtiva Mudou Minha Forma de Programar
Como uma Crítica Construtiva Mudou Minha Forma de Programar
"Às vezes, a chave para evoluir como desenvolvedor está num simples feedback."
A Virada de Chave
Tudo começou com um feedback que recebi de meus gestores em uma das avaliações de desempenho. O ponto central era:
"Você é ansioso e, com frequência, entrega soluções de produto — não necessariamente de engenharia."
Na hora, confesso que fiquei desconfortável. Eu sempre fui extremamente comprometido com prazos e entregas. Ver isso como algo negativo me incomodou. Mas depois, digerindo com calma, percebi que havia verdade e valor naquelas palavras.
O que significa 'soluções de produto'?
Era como se, no afã de entregar rapidamente uma funcionalidade, eu me esquecesse de pensar como engenheiro. Escrevia código funcional, mas não necessariamente sustentável, legível ou com a devida atenção a padrões e boas práticas. Com isso eu criava um débito técnico que, mais cedo ou mais tarde, iria cobrar seu preço. E o pior: dificultava a vida de quem viria a dar manutenção no código depois de mim.
A Transformação
A partir desse feedback, comecei a refletir sobre minha abordagem ao desenvolvimento. Percebi que precisava mudar minha mentalidade de "entregar rápido" para "entregar bem". Isso não significava deixar de ser ágil, mas sim incorporar uma visão mais holística do produto e do código.
O que eu aprendi
- Entender o contexto: Antes de começar a codar, é essencial entender o problema que estou resolvendo e como isso se encaixa no produto como um todo.
- Pensar na manutenção: Escrever código que seja fácil de ler e manter, não apenas para mim, mas para toda a equipe.
- Refatoração é parte do processo: Não ter medo de voltar e melhorar o que já foi feito. O código nunca está "pronto" — sempre há espaço para melhorias.
- Feedback contínuo: Buscar e aceitar críticas construtivas de colegas. Elas são essenciais para o crescimento.
A ansiedade como inimiga silenciosa
Esse comportamento vinha de um padrão pessoal: ansiedade. A ânsia de entregar, de provar valor, de mostrar serviço. Eu via o “Done” como fim da linha. Mas “Done” para quem? Para o usuário ou para o time de engenharia também?
Aprendi que um código "entregue" que dificulta futuras manutenções ou não conversa com o resto do sistema é um débito técnico disfarçado.
O que mudou na prática
Desde então, passei a:
- Me perguntar: "Essa solução é boa para o produto e para a engenharia?"
- Criar PRs menores e mais bem pensadas
- Escrever código como se outra pessoa fosse dar manutenção (porque vai!)
- Estudar padrões arquiteturais e refatoração com mais frequência
- Fazer code reviews com mais empatia e profundidade
Não deixei de ser ansioso, mas...
Hoje, canalizo essa ansiedade para criar soluções melhores, e não apenas rápidas. Ainda me pego acelerado às vezes, mas agora consigo parar, respirar e pensar: "Como um bom engenheiro resolveria isso?"
Conclusão
Nem todo feedback é fácil de ouvir. Mas alguns são transformadores.
Agradeço a quem teve coragem e cuidado de me dar esse toque. Porque ele mudou minha jornada como dev — para sempre.
🧠 E você? Já recebeu um feedback que mudou seu jeito de programar? Compartilha comigo!