Três décadas migrando entre tecnologias: suporte, software, eletrônica e gestão de projetos

Quando olho para minha trajetória profissional, percebo que ela não foi construída em uma linha reta. Foi mais parecida com uma rede cheia de caminhos, desvios, protocolos, linguagens, servidores, circuitos, ferramentas de gestão, metodologias e recomeços. Ao longo de mais de três décadas, transitei entre manutenção de computadores, redes, desenvolvimento de software, suporte remoto, Linux, eletrônica, microcontroladores, ensino, pesquisa aplicada, infraestrutura e, mais recentemente, Inteligência Generativa aplicada à programação e IoT.

Esse percurso me trouxe uma bagagem grande, mas também um conflito permanente: diante de tantas tecnologias, paradigmas e formas diferentes de organizar o trabalho, às vezes a experiência acumulada ajuda, mas às vezes também confunde. Em software, principalmente, o campo evolui tão rápido que aquilo que ontem era moderno hoje parece legado, e aquilo que hoje parece promissor talvez precise ser revisto amanhã. Viver esse movimento por décadas exige mais do que aprender ferramentas; exige coragem para reaprender, desapegar e reorganizar a própria forma de pensar.

Do BASIC ao Clipper: quando comecei a me sentir desenvolvedor

No início da minha carreira, por volta dos 18 anos, eu já programava em BASIC. Era uma linguagem simples, direta e muito importante para quem estava começando. Mas confesso que foi quando conheci a linguagem Clipper que comecei a me sentir, de fato, um desenvolvedor. O Clipper me deu uma sensação diferente: a de construir sistemas com lógica de negócio real, com telas, arquivos, cadastros, consultas e processos usados por pessoas no dia a dia.

Depois veio o contato com DataFlex, linguagem com a qual trabalhei de forma mais profissional. Também tive um leve contato com COBOL, mas não cheguei a programar profissionalmente com ele. Na empresa em que eu trabalhava com DataFlex, minha responsabilidade era muito ligada ao suporte remoto. Isso é curioso quando lembramos que ainda estávamos em uma época anterior à popularização da internet no Brasil. Mesmo assim, já existiam modems para conexão remota via terminal VT100, e usávamos sistemas Unix, como SCO Unix ou Xenix.

Naquele período, suporte remoto não era abrir uma chamada de vídeo, compartilhar tela ou acessar via navegador. Era lidar com conexão discada, terminais de texto, comandos, limitações de velocidade e muita atenção. O ambiente era menos amigável, mas obrigava o profissional a entender melhor o sistema, a rede, o servidor e o comportamento da aplicação.

A chegada do Linux e a formação de uma mentalidade de infraestrutura

Em 1996, o Linux chegou à minha máquina. Esse foi um divisor de águas. Passei a migrar servidores Unix e Xenix para Linux, e isso abriu um novo campo de aprendizado. O Linux não era apenas um sistema operacional alternativo; ele representava uma nova cultura técnica, baseada em liberdade, comunidade, documentação, experimentação e domínio do ambiente.

Com o Linux, aprendi Bash, Perl e cheguei a passar perto das primeiras versões do Python, embora naquela época eu não tenha me aprofundado nele. Também desenvolvi sites com PHP em sua segunda versão, se minha memória não falha. Era uma fase em que muita coisa ainda estava sendo descoberta. A web estava crescendo, os servidores estavam mudando, e as linguagens de script começavam a ganhar espaço.

Naquele tempo, pelo menos no ambiente em que eu atuava, não havia uma adoção ampla e formal de metodologias de desenvolvimento como vemos hoje. Cada empresa tinha seu próprio jeito de conduzir os projetos. Algumas eram mais organizadas, outras dependiam muito da experiência dos programadores e dos analistas. O desenvolvimento era frequentemente guiado por urgência, necessidade do cliente e conhecimento prático acumulado.

A faculdade e a descoberta da pesquisa tecnológica

Em 2003, entrei para a faculdade. Até então, eu nunca havia me preocupado muito com estudos acadêmicos. Como atuava com manutenção de computadores e redes, o cliente queria saber, acima de tudo, se eu resolveria o problema do computador, do servidor ou da rede dele. O valor estava na entrega prática.

Mas, na faculdade de Projeto e Implementação de Redes de Computadores, descobri uma paixão que já existia em mim, mas ainda não estava plenamente organizada: a pesquisa de soluções tecnológicas. Ali comecei a perceber que tecnologia não era apenas resolver problemas imediatos. Era também investigar, modelar, comparar abordagens, propor soluções e compreender fundamentos.

Nesse período, colaborei com dois trabalhos de mestrado de professores. Um deles envolvia redes SDH/WDM, contexto no qual desenvolvi um simulador em Java 1.4 para demonstrar o processo de diagnóstico de falhas nesse tipo de rede. O outro envolvia o uso de agentes móveis, especificamente Aglets, para diagnóstico de redes. Também atuei no desenvolvimento de um software para compilar descritores SNMP voltados a interfaces de administração.

Essas experiências foram muito importantes porque aproximaram minha prática profissional de uma visão mais acadêmica. Eu comecei a perceber que um sistema não é apenas código. Ele é também modelo, arquitetura, protocolo, processo, fluxo de decisão, análise de falha e representação formal de um problema.

PMBOK, RUP, UML e o encontro com os métodos ágeis

Durante a faculdade, estudei bastante PMBOK, RUP, UML e acompanhei o amadurecimento dos métodos ágeis. Naquele momento, o universo da gestão de projetos e da engenharia de software começou a fazer muito sentido para mim. Eu já tinha vivido o desenvolvimento na prática, muitas vezes de forma empírica, e agora encontrava modelos, diagramas, processos e métodos que tentavam organizar aquilo que eu já havia experimentado no cotidiano.

O RUP me trouxe uma visão mais estruturada do desenvolvimento. A UML me encantou pela capacidade de representar ideias, entidades, relacionamentos, casos de uso e arquiteturas sem depender imediatamente do código. Os métodos ágeis, por outro lado, me atraíram pela ideia de adaptação, colaboração e entrega incremental.

Uma prática ágil que sempre me chamou atenção foi a programação em pares. Dois programadores trabalhando juntos no mesmo código não apenas escrevem software; eles negociam entendimento, revisam decisões em tempo real e constroem uma solução de consenso. Para mim, essa ideia é muito poderosa, porque reduz o isolamento intelectual do programador e aumenta a qualidade da decisão técnica.

Também desenvolvi uma visão muito própria sobre coragem no desenvolvimento. Às vezes, o melhor caminho não é insistir durante dias em um bug ou em uma estrutura ruim. Às vezes, a decisão mais madura é apagar tudo e começar de novo. Isso pode parecer radical, mas em muitos casos é mais produtivo reconstruir uma solução com clareza do que remendar indefinidamente algo que nasceu confuso.

Nesse período também aprendi ferramentas e técnicas de gestão de projetos, como MS Project, DotProject, Rose, Diagramas de Gantt, PERT e CPM. Estudei conceitos como valor agregado, planejamento, estimativa, dependência entre atividades e acompanhamento de execução. Tudo isso ampliou minha percepção de que software não é apenas programação: é também gestão de incerteza.

Projetos maiores, redes, servidores e sistemas distribuídos

Ao longo da carreira, cheguei a trabalhar com projetos de maior porte, incluindo ambientes com 16 servidores Linux e um Windows Server com SQL Server, que servia como proxy para um Oracle em uma operação de venda de créditos de telefonia celular. Isso aconteceu em uma época anterior aos smartphones, quando o resistente Nokia era usado como ponto de venda por meio de WAP.

Esse tipo de projeto ensinava muito. Era preciso pensar em servidor, banco de dados, disponibilidade, integração, segurança, rede, operação e suporte. Não havia a facilidade das nuvens modernas, dos serviços gerenciados e dos painéis intuitivos. Muita coisa dependia de conhecimento direto do sistema operacional, dos serviços, das conexões e dos logs.

Também trabalhei como consultor em ambientes Moodle e Teleduc, o que me aproximou do universo educacional mediado por tecnologia. Depois passei a trabalhar por conta própria com redes, abri uma loja de manutenção e continuei prestando serviços técnicos. Mas uma das fases que mais me realizou foi quando comecei a dar aulas sobre Arduino.

Arduino, microcontroladores e o reencontro com a eletrônica

Programar microcontroladores despertou em mim uma paixão especial. Havia algo muito poderoso em escrever um código e ver aquilo movimentar um pino, acender um LED, ler um sensor, controlar um motor ou interagir com o mundo físico. Diferente do software puramente abstrato, os sistemas embarcados nos obrigam a respeitar tempo, energia, ruído, tensão, corrente, memória, interrupções e limitações reais do hardware.

Na família Arduino, cheguei a usar modelos como Arduino Due e Maple, que eram alguns dos mais poderosos na época em seus respectivos contextos. Ensinar Arduino também me trouxe uma grande satisfação, porque permitia mostrar a outras pessoas que eletrônica e programação não precisavam ser mundos separados. Pelo contrário: quando se encontram, abrem portas para automação, robótica, instrumentação, IoT e aprendizado prático.

Depois disso, dei uma pausa de cerca de dez anos nos trabalhos, e esse intervalo me fez perder um pouco o curso da história e da adaptação tecnológica. Em uma área que muda rapidamente, uma pausa longa tem impacto. Ferramentas mudam, linguagens amadurecem, práticas se consolidam, outras desaparecem, e o profissional precisa reencontrar o ritmo.

Mesmo nesse intervalo, em determinado momento resolvi aprender sobre síntese de hardware e acabei desenvolvendo um core RISC-V básico, com operações mínimas de soma e subtração. Foi uma experiência pequena, mas simbolicamente importante. Ela me colocou diante de uma camada ainda mais profunda da computação: não apenas programar o processador, mas tentar compreender como um processador pode ser descrito.

O retorno à eletrônica e o livro sobre fontes chaveadas

Em 2023, retomei com mais força a eletrônica, que sempre foi uma das minhas paixões. Cheguei a criar um canal para conversar com pessoas interessadas no assunto. Brincamos muito com simulações usando SPICE, analisamos circuitos com amplificadores operacionais, que considero fascinantes, e comecei duas especializações técnicas: uma em manutenção de amplificadores de potência e outra em fontes chaveadas.

Foi nesse processo que percebi uma lacuna importante em português: faltava um livro sobre fontes chaveadas que explicasse, de forma didática, como elas funcionam. Não apenas um material com fórmulas soltas ou esquemas prontos, mas um conteúdo que conduzisse o leitor pelos conceitos fundamentais necessários para entrar nesse universo.

Foi assim que escrevi um livro com mais de 500 páginas sobre fontes chaveadas, apresentando conceitos importantes para quem deseja compreender esse campo da eletrônica. Esse projeto foi muito significativo para mim porque uniu pesquisa, didática, experiência prática, eletrônica analógica, semicondutores, magnetismo, controle e conversão de energia.

O conflito de carregar muitas tecnologias no currículo

Diante de tantas tecnologias no currículo, às vezes eu mesmo me traio. Em alguns momentos, acabo confundindo qual ferramenta, linguagem, método ou abordagem usar. Isso acontece principalmente em software, porque a evolução é muito rápida e cada geração tecnológica traz consigo uma nova promessa.

Quem atravessou BASIC, Clipper, DataFlex, Unix, Xenix, Linux, Bash, Perl, PHP, Java, SNMP, UML, RUP, PMBOK, métodos ágeis, Arduino, microcontroladores, SPICE, RISC-V, IoT e agora Inteligência Generativa sabe que cada tecnologia carrega uma forma de pensar. Não é apenas sintaxe. Cada ambiente ensina uma visão de mundo.

O problema é que essas visões de mundo às vezes entram em conflito. Uma mentalidade mais estruturada, influenciada pelo RUP e pela UML, pode entrar em tensão com uma mentalidade ágil mais leve e incremental. Uma formação prática de suporte e manutenção pode entrar em conflito com uma abordagem acadêmica de pesquisa. Uma visão de infraestrutura pode disputar espaço com uma visão de produto. Uma visão de eletrônica pode exigir uma disciplina que o desenvolvimento web muitas vezes ignora.

Esse conflito, porém, também é uma riqueza. Ele me permite enxergar problemas por vários ângulos. Eu posso olhar para um sistema como desenvolvedor, como técnico de suporte, como administrador de redes, como pesquisador, como professor, como entusiasta da eletrônica, como autor e como alguém que já viu várias ondas tecnológicas nascerem, crescerem e serem substituídas.

A relação incompleta com os métodos ágeis

Por incrível que pareça, apesar de ter estudado métodos ágeis e acreditar bastante em seus princípios, nunca trabalhei em uma empresa que os utilizasse de forma consistente. Também nunca me foi demandada formalmente essa estratégia de gestão de projetos de software. Nos últimos anos, tenho trabalhado muito de forma avulsa, em projetos individuais ou consultorias pontuais.

Mesmo assim, uso Kanban para organizar meus projetos pessoais. Ele me ajuda a visualizar o fluxo de trabalho, separar tarefas, controlar andamento e evitar que ideias fiquem perdidas. Já tentei aplicar essa organização com outros programadores, mas nem sempre deu certo. Muitas vezes, por falta de formação mais ampla em engenharia de software, alguns profissionais sabem programar, mas não compreendem bem processo, documentação, arquitetura, planejamento e colaboração. Em alguns casos, o resultado foi frustrante, e acabei desistindo do projeto.

Isso mostra algo importante: metodologia não funciona sozinha. Não adianta colocar um quadro Kanban, criar cartões ou falar em ágil se as pessoas não compartilham uma cultura mínima de colaboração, responsabilidade, revisão e melhoria contínua. Método sem maturidade vira ritual vazio.

Embarcatech, IoT e Inteligência Generativa

Recentemente, terminei o programa Embarcatech, da Softex com o IFCE, onde estudei o desenvolvimento de soluções embarcadas e IoT. Nesse contexto, fiquei responsável pela engenharia de prompt e pela infraestrutura interna de LLMs para atender requisições relacionadas a IoT.

Essa experiência foi muito interessante porque conectou várias partes da minha trajetória: sistemas embarcados, infraestrutura, software, pesquisa, automação e Inteligência Generativa. As LLMs trouxeram uma nova camada para o desenvolvimento. Elas não substituem o pensamento técnico, mas ampliam a capacidade de prototipar, documentar, revisar, investigar e acelerar tarefas quando usadas com critério.

Ainda assim, mesmo nesse ambiente, não foi usado um processo formal de desenvolvimento ágil na empresa em que trabalhei. Isso reforça uma percepção que carrego: no Brasil, muitas vezes falamos de metodologias, mas na prática muitos projetos ainda são conduzidos de maneira informal, dependendo da experiência individual e da pressão do momento.

Atualmente também estou cursando o Bacharelado em Engenharia de Software. Ainda não vi a disciplina de Metodologias Ágeis em profundidade, embora já tenhamos tido uma introdução rápida. Confesso que, às vezes, acabo misturando técnicas do UP com práticas ágeis, seja de forma intencional, seja por acidente. Mas talvez essa mistura também represente minha própria trajetória: uma tentativa constante de conciliar estrutura e adaptação.

Entre o processo e a liberdade de construir

Acredito que um dos grandes desafios de quem viveu várias fases da tecnologia é encontrar equilíbrio entre processo e liberdade. Processo demais pode engessar. Liberdade demais pode gerar caos. Um projeto precisa de visão, organização, responsabilidade e documentação, mas também precisa de espaço para descoberta, prototipagem e mudança de rota.

Talvez por isso eu tenha simpatia pelos métodos ágeis. Não porque eles sejam uma solução mágica, mas porque reconhecem que software é uma atividade humana, incerta e evolutiva. Requisitos mudam. Pessoas interpretam de formas diferentes. O cliente descobre o que quer à medida que vê o produto nascer. O programador entende melhor o problema enquanto codifica. A equipe amadurece enquanto erra, revisa e melhora.

Ao mesmo tempo, minha experiência com RUP, UML, PMBOK e infraestrutura me impede de romantizar a improvisação. Eu sei que sistemas precisam de arquitetura. Sei que projetos precisam de rastreabilidade. Sei que documentação tem valor. Sei que decisões técnicas ruins cobram juros. Sei que apagar e recomeçar às vezes é necessário, mas também sei que começar sem pensar pode gerar desperdício.

O que espero aprender daqui para frente

Ao chegar à DIO, espero ter mais contato com metodologias ágeis na prática, porque acredito muito nelas. Quero compreender melhor como aplicar esses conceitos em ambientes reais, com equipes reais, prazos reais, conflitos reais e limitações reais.

Minha trajetória me ensinou que tecnologia muda, mas alguns fundamentos permanecem. Precisamos entender o problema antes de escolher a ferramenta. Precisamos comunicar melhor nossas ideias. Precisamos documentar o suficiente para que outros continuem o trabalho. Precisamos testar, revisar e melhorar. Precisamos ter humildade para aprender com os mais novos e também maturidade para não descartar o que já foi aprendido no passado.

Depois de três décadas migrando entre tecnologias, talvez a principal conclusão seja esta: ser desenvolvedor não é dominar uma linguagem específica. É desenvolver a capacidade de aprender continuamente, adaptar-se com senso crítico, construir soluções úteis e reconhecer que cada nova tecnologia é apenas mais uma etapa de uma jornada muito maior.

No meu caso, essa jornada começou com BASIC, ganhou corpo com Clipper e DataFlex, passou por Unix, Linux, redes, Java, SNMP, UML, Arduino, eletrônica, fontes chaveadas, IoT e Inteligência Generativa. E, mesmo depois de tudo isso, continuo aprendendo. Talvez esse seja o verdadeiro conflito — e também a verdadeira beleza — de atravessar décadas em tecnologia: nunca estamos completamente prontos, mas estamos sempre em construção.