Antes de escrever a primeira linha de código pensando em produção, eu já sabia escutar. Não é força de expressão: durante anos, minha rotina foi ouvir gente frustrada com um sistema travado, um financeiro que não fechava ou uma rede que caía na hora errada. Hoje, como Desenvolvedor Júnior, percebo que boa parte da minha atenção a detalhes, aos logs, aos critérios de aceite e, principalmente, ao usuário do outro lado da tela, vem exatamente dali.
Esse texto é sobre essa trajetória — e sobre como o suporte, muitas vezes tratado como "porta de entrada menor" na carreira de tecnologia, na verdade me deu ferramentas que uso todos os dias como dev.
O início: vendendo tecnologia sem saber que era tecnologia
Minha história em TI não começou com programação. Começou aos 18 anos, na Two Side Connection, uma startup fundada por um amigo e mentor, Pedro Lara. Eu fui o primeiro contratado e, por consequência, o "faz tudo" da empresa.
A plataforma que vendíamos era voltada para escritórios de arquitetura, unificando orçamento, fornecedores e relacionamento com clientes em um só lugar. Comecei vendendo, mas rapidamente a realidade de startup me puxou para outros papéis: implantação do sistema nos clientes, gestão de uma equipe de suporte e participação em reuniões de vendas e parcerias.
Foi ali, no meio do caos organizado de uma empresa em crescimento, que a tecnologia despertou meu interesse de verdade. Quando a Two Side foi vendida, tive que decidir o que fazer da vida. Vendas não era o caminho. Comecei a estudar programação.
Escolpi Informática: minha primeira base técnica de verdade
A porta de entrada oficial no mercado de tecnologia foi uma vaga de Suporte Técnico na Escolpi Informática, empresa que desenvolvia e vendia sistemas de PDV, controle de estoque e financeiro para supermercados e pequenos negócios.
Foi lá que tive meu primeiro contato sério com consultas SQL, manutenção de hardware e suporte a sistemas em Java. E foi lá também que criei algo que hoje reconheço como meu primeiro "produto interno": uma Wiki de base de conhecimento, onde toda a equipe podia registrar e consultar soluções para problemas recorrentes do sistema.
Sem saber, eu já estava documentando processos e pensando em escalabilidade de conhecimento — só que a "stack" ainda era outra.
A furada que valeu a pena: Flix Promotora
Nem toda experiência precisa ser um case de sucesso para ensinar algo. Meu estágio na Flix Promotora, uma empresa de call center, foi curto e, sinceramente, não recomendo nem o produto nem o modelo de trabalho de lá. Minha função era manutenção de hardware, sem muito espaço para crescer.
Mas foi lá que conheci meu gestor, Adriano, que depois me ajudou a conseguir uma vaga no Colégio São José. Às vezes a experiência ruim não é sobre o que você aprende tecnicamente, mas sobre quem você conhece no caminho.
Colégio São José: infraestrutura, boas práticas e os profissionais que me inspiraram
No Colégio São José Escolápias, atuando como Analista de TI, tive a sorte de trabalhar ao lado de dois profissionais que, apesar de mais jovens que eu, tinham uma visão de tecnologia muito acima da média: Rafael e João.
Em seis meses, Rafael transformou completamente a forma como o colégio lidava com tecnologia: segurança, boas práticas de TI e integração de sistemas com o TOTVS para áreas críticas como matrícula, financeiro, contábil e RH. Eu tive o privilégio de participar desse processo — padronizando os computadores das salas de aula, implementando TVs para apoiar os professores nas aulas e melhorando toda a rede do colégio.
João, por sua vez, trabalhava a implementação gradativa de GPOs, controlando o acesso e a informação que chegava aos computadores da sala de informática.
Foi um período de aprendizado técnico real, mas também de referência profissional: ver dois jovens conduzindo uma transformação de infraestrutura inteira com tanta competência me mostrou o padrão que eu queria alcançar.
South Tecnologia: de analista de infraestrutura a criador de soluções
A relação construída no Colégio São José me abriu a porta para a South Tecnologia, como Analista de Infraestrutura, ao lado de Braulio e Matheus. Ali, prestávamos suporte terceirizado de infraestrutura para diversas empresas do grupo: Premium Clube, Plamev Pet, Meep, Tá Rastreado, Pronto Assistência, Essential — entre outras.
Com tantas empresas para atender, via chat e presencialmente, a equipe cresceu rápido. E foi esse crescimento que me fez enxergar oportunidades de melhoria — não pedidas, mas necessárias.
O bot de chamados. Como usávamos o Discord como canal principal, tive a ideia de transformá-lo em interface de abertura de chamados. A pessoa enviava um resumo com empresa, solicitante, descrição do problema e como foi resolvido. O bot, integrado à IA do Gemini, devolvia o chamado já formatado, pronto para colar direto no GLPI. Um problema operacional resolvido com uma ideia simples de automação.
O agente RAG para os POPs. Com o crescimento da equipe, o SLA começou a subir. Por fazer parte do time desde o início, eu era constantemente procurado por colegas para tirar dúvidas sobre processos já documentados — e tínhamos cerca de 90 POPs, muitos deles cheios de detalhes que nem eu mesmo conhecia de cor. A solução foi criar um agente RAG treinado com essa base de conhecimento. Bastava mandar uma mensagem no Discord para receber a resposta certa, reduzindo drasticamente o tempo de atendimento.
Foi esse projeto — nascido de uma dor real de suporte — que me abriu a oportunidade de me tornar desenvolvedor na South Tecnologia. Comecei em projetos da Plamev, depois atuei como front-end no Tá Rastreado e no AEasy, um produto voltado para associações.
O que o suporte me ensinou sobre ser dev
Se tem um ponto central nessa trajetória toda, é este: atuar em suporte me formou como desenvolvedor antes mesmo de eu escrever código profissionalmente.
Alguns motivos:
- Escuta ativa das dores do usuário. Suporte é, o tempo todo, ouvir o que não está funcionando na visão de quem usa. Isso me deu uma visão de produto que muitos devs só desenvolvem depois de anos — a de pensar pelo lado de quem vai usar o que estou construindo.
- Documentação como hábito, não como tarefa extra. Registrar chamados com o máximo de contexto possível, para poder escalonar quando necessário, me ensinou a valorizar informação clara e completa — algo que hoje aplico em issues, PRs e specs.
- Atenção a logs e erros. Trabalho repetitivo em suporte parece cansativo, mas treina um olho fino para padrões, causas raiz e sintomas — exatamente o que se precisa para debugar bem.
- Visão resolutiva. Suporte não aceita "não sei", porque alguém do outro lado está travado. Essa urgência saudável virou parte de como encaro bugs e bloqueios hoje. No fim, cada chamado atendido, cada POP escrito, cada usuário ouvido foi, sem que eu percebesse na hora, um treino silencioso para o tipo de desenvolvedor que eu queria ser: alguém atento, resolutivo e que nunca perde de vista quem está do outro lado do sistema.
Você também veio de suporte ou infraestrutura para o desenvolvimento? Como essa experiência mudou a forma como você programa hoje? Bora trocar ideia nos comentários.
Top comments (0)