Dos 5 Minutos de uma Fita Cassete a 40 Anos de Código

Introdução

Eu tinha 15 anos quando comecei a programar. Hoje tenho 55. São 40 anos desenvolvendo software.

Quando alguém me pede para contar essa história, a minha memória não vai primeiro para uma linguagem de programação ou para um algoritmo. Ela vai para um som: um chiado agudo, quase ensurdecedor, vindo de um gravador de fita cassete ligado a um pequeno computador chamado TK 85. Para quem começou a programar na era da fibra ótica e dos SSDs, é algo difícil de imaginar, mas o nosso ritual de programação era medido em paciência e áudio.

Naquela época, um programa simples, que desenhava um gráfico básico no monitor, não carregava instantaneamente. Ele precisava ser gravado numa fita cassete comum, e o processo de carregar esse programa de volta para a memória do computador levava quase cinco minutos. Cinco minutos de um barulho infernal, onde qualquer pequena falha na fita significava começar tudo do zero. A programação, para mim, nasceu desse ritual: da paciência de esperar o chiado terminar para, talvez, ver alguma coisa acontecer no monitor.

Esta história não é apenas a minha jornada; é a jornada de uma era. É sobre ter visto a computação pessoal nascer no Brasil, não como consumidor, mas como alguém que estava lá a tentar construir alguma coisa com as ferramentas mais rudimentares que existiam.

Nas décadas seguintes, eu passaria do BASIC do TK 85 para o Pascal estruturado da universidade; encontraria no C a "programação robusta" que definiria a minha carreira; mergulharia num sistema operacional de tempo real chamado QNX, enquanto o mundo usava DOS; dominaria o Clipper porque o mercado assim o exigia; e, finalmente, encontraria no C++Builder a ferramenta que me acompanharia por décadas, permitindo-me construir as aplicações mais complexas que idealizei.

Mas esta não é uma história sobre linguagens. É uma história sobre resolver problemas quando não existia um "Google" para procurar a resposta, quando não havia bibliotecas prontas e quando a função do "programador" incluía tudo: desde desenhar telas em papel milimetrado e criar os seus próprios métodos de ordenação, até entender de eletrônica para soldar cabos de comunicação serial e analisar bytes crus num disco rígido para descobrir uma falha no boot do sistema operacional.

É uma história sobre o que significava ser um "escovador de bits", alguém que precisava contar cada byte de dados porque o espaço era o recurso mais precioso que tínhamos. Esta é a minha memória de 40 anos a construir software do zero.

Capítulo 1: O Despertar do Bit (Anos 80)

A minha história com a tecnologia não começou por causa de videogames ou por ter um computador em casa, algo raríssimo na época. Começou em 1984, num colégio em Cachoeira do Sul, por causa de um professor de física, chamado Liberato Mór.

O professor Liberato era um visionário para a época e decidiu criar o Clube da Informática no Colégio Barão do Rio Branco. Oficialmente, o clube era destinado apenas aos alunos do segundo e terceiro anos, e eu estava apenas no primeiro. Mas a ideia de poder mexer naquelas máquinas novas, os TK 85, era algo que me fascinava. Eu não aceitei ficar de fora. Fui tão insistente, pedi tanto, que o professor Liberato, talvez por cansaço ou por ver alguma curiosidade genuína ali, acabou por me deixar participar. Mal sabia eu que essa "pequena vitória" definiria o resto da minha vida.

O primeiro grande choque no clube de informática não foi à lógica de programação; foi à realidade física da máquina. Nós não tínhamos discos rígidos nem disquetes. O nosso meio de armazenamento era a fita cassete.

O processo era tudo menos elegante. Tínhamos um gravador de fita cassete comum, e ele era ligado ao TK 85 por um simples fio. O programa era literalmente um som, um áudio agudo e ensurdecedor que era transmitido por esse fio. Era um barulho tão infernal que tínhamos de baixar o volume do gravador para não incomodar toda a gente à volta. Quem viveu a era das ligações por fax-modem nos anos 90 consegue ter uma ideia muito próxima do que era aquele som.

A paciência era o requisito principal. Como mencionei carregar um programa simples demorava cerca de cinco minutos. Cinco minutos de tensão absoluta, a ouvir aquele chiado, a rezar para que a leitura não falhasse no meio, o que acontecia com frequência, obrigando a rebobinar a fita e a começar tudo de novo.

A minha motivação inicial não era criar jogos. Eu olhava para aquilo e queria resolver problemas práticos. O primeiro desafio que me impus foi criar algo útil para o próprio colégio. Que foi apresentado em uma feira de ciências da escola. Decidi fazer um sistema para informar a "quantidade de alunos por turma" e também informar em qual turma estudava tal aluno.

O desafio era imenso, porque um TK 85 com BASIC não tinha absolutamente nenhum conceito de "base de dados". Se eu quisesse que o computador soubesse o nome de um aluno, eu tinha de escrever esse nome diretamente dentro do código.

O resultado foi uma aplicação dividida em duas partes. A primeira parte era visual: ela conseguia desenhar um gráfico básico no monitor que mostrava quantos alunos existiam em cada turma do colégio. A segunda parte era interativa: o utilizador podia escrever um nome, e o programa respondia quantas pessoas com aquele nome exato estavam registadas e em que turmas elas se encontravam.

Por baixo dos panos, aquilo era uma maratona de código. Para fazer o sistema de consulta funcionar, eu tive de carregar todos os nomes dos alunos diretamente no programa. A "lógica de pesquisa" era apenas uma sequência gigante de comandos IF e ELSE que verificavam o que o utilizador tinha digitado contra o que eu tinha escrito no código. Era um sistema de consulta "hard-code". Era rudimentar, pesado e completamente manual, mas funcionava. Ali, aos 15 anos, a olhar para aquele gráfico no monitor(que era uma tv preto e branco) depois de cinco minutos de chiado, eu percebi que era aquilo que eu queria fazer: dar ordens a uma máquina e fazê-la organizar informação.

Capítulo 2: A Fundação Robusta (Faculdade, Início dos 90)

A faculdade representou o primeiro grande salto conceptual da minha carreira. Eu vinha do mundo do BASIC no TK 85, onde tudo era no automático. O nosso código era organizado por números de linha, que pulávamos de 10 em 10 para poder inserir comandos no meio depois, e para executar, bastava dar o comando "RUN".

Primeiro entrei na Unisinos e depois na PUC. E foi na PUC que tive o primeiro choque: o Pascal, que aprendemos num ambiente chamado Music, rodando em terminais conectados a um mainframe. A mudança foi total. De repente, não existiam mais números de linha. Antes de usar uma variável, eu precisava "declarar" o seu tipo. O código precisava de uma estrutura formal. Mas a maior mudança de paradigma foi descobrir o conceito de "compilação". A ideia de que o meu código-fonte precisava passar por um processo, ser traduzido para outra coisa antes de poder ser executado, era uma novidade completa para mim.

O Pascal foi importante, mas foi na linguagem C que eu encontrei o que chamei na época de "programação robusta". Foi com o C que eu realmente vi o processo completo de desenvolvimento.

O ambiente era o Turbo C, rodando nos PC-XT da faculdade. Aqui, a realidade da infraestrutura era tão importante quanto à linguagem. Hoje, ligamos um computador e o sistema operacional está lá. Naquela época, o sistema operacional, o DOS 3.0, tinha de ser carregado por um disquete de 5.1/4 polegadas. O ritual era manual: inseríamos o disquete do DOS, ligávamos a máquina, esperávamos o sistema carregar. Depois, retirávamos o disquete do DOS e inseríamos o disquete do Turbo C para, só então, começar a programar. Os discos rígidos das máquinas do laboratório eram usados apenas para guardar dados; os programas, nós carregávamos via disquete.

Foi uma mudança imensa. Pela primeira vez, eu não estava num terminal ligado a um mainframe (como o Music), mas sim a controlar todo o processo na máquina local, desde o sistema operacional até ao compilador.

O primeiro programa que fiz em C não foi para nenhuma disciplina da faculdade; foi uma pegadinha para os meus colegas. Eu usei o C para criar um programa que simulava perfeitamente o monitor preto inicial do DOS. Eu executava o programa e saía de perto. Quando um colega chegava e sentava naquela máquina, ele via o prompt normal e começava a digitar. Assim que ele pressionava qualquer tecla, o meu programa tomava conta, limpava o monitor e começava a exibir mensagens aterradoras, dizendo que estava a formatar o disquete e o disco rígido, e que o nome dele ia ficar gravado como o responsável. Eu ficava de longe a assistindo o pânico.

Como eu ainda não tinha computador em casa, o laboratório era onde eu passava horas e horas. A nossa vida estava armazenada em pilhas de disquetes de 5.1/4. Tínhamos um disquete para o WordStar, que usávamos para os trabalhos escritos, e disquetes separados para os nossos códigos de Turbo Pascal ou Turbo C.

Foi nessa altura que aprendi da forma mais difícil uma das lições mais importantes da nossa área: o valor do backup. Aqueles disquetes eram frágeis. Perdi a conta de quantas vezes um disquete simplesmente estragava, corrompia, e eu perdia horas, às vezes dias de trabalho. Foi um desespero que me levou a descobrir ferramentas como o PC-TOOLS e o MACE-TOOLS, que eram utilitários que conseguiam recuperar arquivos apagados ou até salvar dados de setores defeituosos dos disquetes. Foi ali que o conceito de fazer cópias de segurança deixou de ser teoria e passou a ser sobrevivência.

Nessa época, as interfaces que construíamos eram todas em modo texto. Os menus eram numéricos: "Digite 1 para Cadastro, 2 para Relatórios", e por aí vai. Quando precisávamos desenhar uma tela de cadastro, o processo começava fora do computador: eu desenhava a tela a lápis, num papel, para visualizar onde cada campo ficaria, e depois tentava replicar aquilo no código.

A universidade não nos dava bibliotecas de interface; isso custava dinheiro. Se precisávamos de algo, tínhamos de construir nós mesmos. Foi aí que comecei a criar a minha própria biblioteca (lib) pessoal com as funções que eu mais usava. Precisava ordenar dados? Não havia uma função pronta. Era o bom e velho método "bolha" (bubble sort), implementado tudo na mão.

Os nossos monitores eram pretos, e nós fazíamos o fundo dos campos de texto ficar branco. O cursor ficava ali piscando, e a tecla ‘Enter’ era o que mudava o cursor de um campo para o outro. Isso, para nós, era o padrão.

Até que um dia, chegou ao laboratório um computador 286 com um monitor CGA Monocromático Laranja. Foi uma revolução. A primeira vez que saímos do monitor preto. Aquele computador era tão avançado comparado aos XTs que se formavam filas de alunos para usá-lo. Era preciso agendar hora para conseguir sentar-se em frente àquele monitor laranja. Estávamos no início dos anos 90, e a revolução gráfica estava apenas a dar os seus primeiros sinais.

Capítulo 3: O Pioneiro do QNX (A Vida Profissional)

Enquanto a faculdade me dava à base teórica, a minha necessidade de independência financeira (eu tinha cerca de 20 anos e queria ter o meu próprio dinheiro sem depender totalmente da família) levou-me ao mercado de trabalho. Consegui um estágio na ProSoft, uma empresa que estava a desenvolver uma aplicação complexa para a área médica, para alguns clientes de clinicas médicas e laboratórios, dentre eles a Serdil Radiologia, onde era a sede da ProSoft no terceiro andar.

Foi ali que conheci o sistema operacional que definiria a minha carreira naquela década: o QNX.

O QNX era um universo à parte. Enquanto o mercado de pequenas empresas estava focado no DOS (e mais tarde no Windows 95), o QNX era um sistema operacional multitarefa robusto, usado para automação e ambientes de alta performance. A ProSoft estava a usar o C QNX, e a minha função inicial era dar continuidade a essa aplicação e começar a migração para uma versão mais nova e robusta, o C 86.

A grande vantagem do QNX, e o motivo pelo qual o cliente o escolhia, não era apenas a velocidade do sistema em si; era uma lógica de negócio e infraestrutura irrefutável. Num ambiente DOS com Rede Novell na época, cada funcionário precisava de um computador completo, que era uma máquina cara. Com o QNX, bastava um servidor robusto e vários "terminais burros" ligados a ele e estaria tudo pronto. Fazendo uma comparação com valores de hoje, seria como escolher entre comprar vários PCs de R$ 3000,00 ou vários terminais de R$ 300,00 cada. Para o cliente, a economia era colossal e a performance, por ser tudo em modo texto via terminal, era muito superior.

No entanto, o QNX era um sistema "cru". Ele não vinha com os utilitários básicos a que estamos habituados hoje. Lembro-me vividamente dos clientes da ProSoft, a reclamarem que o sistema era avançado, mas "nem calculadora tinha". Foi um pedido tão básico e recorrente que a primeira aplicação que desenvolvi profissionalmente foi exatamente essa: uma calculadora. Um utilitário simples, feito do zero, só para suprir aquela necessidade básica. (Guardo esse código-fonte até hoje.)

O meu segundo projeto na empresa nasceu da minha própria curiosidade. Percebi que o QNX tinha uma série de comandos de comunicação entre os terminais, algo que a equipe nunca tinha tido tempo de explorar. Debrucei-me sobre o manual do C 86 e os comandos do QNX e comecei a escrever um sistema de chat interno, permitindo que os terminais burros conversassem entre si em tempo real. Foi um sucesso imediato na empresa.

Enquanto eu mergulhava no mundo corporativo do QNX, a minha vida na faculdade continuava em paralelo. Estávamos agora em 1992, e os disquetes de 5 1/4 estavam a dar lugar aos mais práticos (e resistentes) de 3 1/2. O Turbo C também estava a ser substituído, e começámos a usar o Borland C.

Foi com o Borland C que fiz o meu primeiro programa em modo gráfico, um projeto em grupo para a faculdade(eu, Eduardo Magalhaes e o Eraldo Junior). Decidimos fazer um jogo da memória. Para lhe dar um toque especial, decidimos que o jogo teria música. Como éramos colorados, a capa das cartas do jogo era o símbolo do Internacional. E, enquanto a pessoa jogava, o computador tocava o hino do Inter.

Fazer a música tocar foi um desafio à parte. Não havia MP3, nem WAV. Apenas um comando em C chamado sound, que emitia um bipe numa frequência específica. O meu colega de grupo, Eduardo Magalhães, sentou-se com o violão ao meu lado e ao lado do computador. Ele tocava uma nota do hino, e nós ficávamos a testar valores no comando sound até achar a frequência exata daquela nota. Repetimos o processo para o hino inteiro.

Desenvolvemos o jogo no 286 que ele tinha em casa, já com um monitor EGA, e guardávamos os recordes num simples arquivo de texto. O nosso melhor tempo era de 30 segundos. Fomos então apresentar o trabalho na faculdade. O laboratório já tinha um 386 SX, uma máquina muito, mas muito mais rápida que o nosso 286.

Foi a primeira vez que vi, na prática, o impacto brutal da velocidade do processador. O professor foi testar o jogo durante a apresentação e aniquilou o nosso recorde, cravando 10 segundos. Na altura, ficámos frustrados; demorou um pouco para a ficha cair e entendermos o óbvio: a lógica do jogo corria muito mais rápida numa máquina mais potente.

Foi também nessa altura, na casa de outro colega, que vi o Windows 3.1 pela primeira vez. Foi um choque visual. Eu nunca tinha visto tantas cores num computador. Para ser honesto, no início nem sabíamos direito o que fazer com aquilo. Usávamos o Paintbrush para desenhar e o editor Writer. Mas vimos à impressão sair do modo texto para o modo gráfico, com letras mais bonitas, e usámos o "mouse" pela primeira vez. Era uma revolução.

O tempo passou. Em 1993, a ProSoft decidiu desistir da área médica e passou-me os clientes. Saí da empresa, atuei um tempo por conta própria e, em 1994, fundei a minha própria empresa, a CompCet, para dar continuidade ao desenvolvimento em QNX.

Em 1995, já com a CompCet, um colega indicou-me um projeto para um cliente na área agropecuária. Eles precisavam de um sistema completo, desde controle de estoque até notas fiscais. E isso incluía o uso de impressoras fiscais, que estava começando a ser obrigatório. Aqui, enfrentámos um grande problema: no Rio Grande do Sul, as impressoras fiscais existiam, mas todo o desenvolvimento de drivers era feito em São Paulo. As software houses locais não acessavem diretamente com a impressora; elas apenas usavam os drivers que vinham de SP para se comunicarem com o equipemento.

Eu não me conformei com isso. Pensei: "O QNX é um sistema para automação. Eu domino a comunicação serial RS-232. Eu não preciso de um driver intermediário; eu preciso do protocolo".

Peguei no telefone fixo, sim na época estava começando os celulares e não eram todos que tinham, pois conseguir uma linha celular era muito difícil, era uma disputa imensa, e passei horas a falar com os técnicos que fabricavam a impressora, uma Sigtron, em São Paulo. Pedi-lhes o padrão de comunicação, os comandos que eu precisava enviar pela porta serial. A resposta do outro lado da linha foi de ceticismo total. Eles disseram-me que "jamais funcionaria", que eu precisaria obrigatoriamente do driver deles para conseguir a comunicação.

Ignorei o aviso. Com o manual de comandos que consegui deles, usei o QNX e o C 86 para enviar os comandos diretamente para a porta RS-232. E funcionou. Conseguimos a comunicação direta, sem qualquer driver. Tenho a convicção absoluta de que fomos os primeiros desenvolvedores no Rio Grande do Sul a comunicar diretamente com uma impressora fiscal, de forma nativa.

O Arquiteto (Dominando o C-Tree e o Mercado)

Ter a minha própria empresa (a CompCet) a rodar em QNX significava que eu não era apenas o programador; eu era o responsável por tudo, incluindo a eficiência da base de dados. Na altura, usávamos uma base de dados chamada C-Tree. O C-Tree era muito bom para a época, mas não era relacional.

Na prática, isto significava que era apenas um sistema de arquivos POSIX, que gravava arquivos “.dat” puros usando comandos “write” e “read” do C. Quando o C-Tree foi criado, o padrão da indústria, quando se fazia algo como um pedido (que tem um cabeçalho e vários itens), era gravar tudo numa tabela única, repetindo os dados do cabeçalho para cada item. A duplicação de dados era absurda.

Antes de entrar na ProSoft, eu já achava um absurdo esse tipo de gravação que alguns ainda faziam e via um desperdício imenso de espaço em disco (que era caríssimo) e de performance. Quando cheguei na Prosoft, já existiam alguns comandos que feitos pelos donos, para o C-Tree comportar-se como uma base de dados quase relacional. Como tínhamos acesso aos fontes, comecei a estudar o seu funcionamento e melhorei bastante a solução, principalmente depois que já estava na minha empresa.

Não modifiquei o núcleo da base de dados, mas criei uma camada de funções em C por cima dela. Em vez de ler a base de dados diretamente, a minha aplicação agora chamava uma função escrita em C para fazer todo o processo. Tipo um hibernate, do Java de hoje em dia. Não havia SQL, não havia joins automáticos; era tudo feito "na mão", na lógica do C. Estávamos a engatinhar para um modelo relacional, e isso deu-nos uma vantagem competitiva gigante. As nossas aplicações ficaram mais rápidas e principalmente mais fáceis de dar manutenção, o que nos dava uma vantagem sobre os concorrentes no tempo de resposta para resolver algum incidente por causa da base de dados, e olha que naquela época, tínhamos muitos incidentes por arquivos corrompidos, índices corrompidos e etc.

Claro que usar o QNX era um desafio diário. O maior problema era a gestão de falhas. Quando faltava luz (algo comum) ou a máquina era desligada no momento exato em que a aplicação estava a gravar um registro ou o próprio S.O. estava fazendo alguma atividade de I/O, algum arquivo corrompia, e quase sempre eram os arquivos da aplicação devido a quantidade de acessos, e o arquivo ficava com o status "busy". Quando isto acontecia, o sistema inteiro parava. A solução era manual: tínhamos de acessar o servidor e dar comando específico (chattr nome_do_arquivo s=-b) para alterar o status do arquivo.

Isto acontecia com tanta frequência nos clientes que me cansei de receber chamadas para resolver o mesmo problema. Então, criei um comando automático que, na inicialização do QNX, que verificava todos os arquivos de dados; se encontrasse algum marcado como "busy", ele próprio aplicava a correção antes que o utilizador sequer percebesse o problema, bastava reiniciar a máquina, ou seja, a velha solução usada até hoje por alguns.

O outro pesadelo era a reindexação. Era um processo dolorosamente lento; muitas vezes, tínhamos de deixar a reindexação acontecendo à noite inteira no cliente. E tínhamos de ficar acompanhando, porque várias vezes a reindexação simplesmente parava a meio do processo, e daí, só tinha um jeito: começar tudo de novo. A aplicação simplesmente não rodava se o índice não estivesse 100% íntegro.

Como o C-Tree era sequencial e o QNX era multitarefa, a fragmentação dos arquivos no disco rígido era absurda. Para manter a performance, tínhamos de desfragmentar os arquivos de dados constantemente. O processo era um ritual complexo: renomeávamos o arquivo de dados e o índice, depois copiar o arquivo de dados para o nome original e reindexar. E o detalhe mais importante: não podíamos apagar o arquivo antigo imediatamente, senão o sistema operacional começava a usar aqueles blocos de disco livres e fragmentava o arquivo novo outra vez.

Enquanto eu domava a base de dados, outra coisa me incomodava profundamente: as interfaces da aplicação. Primeiro, tínhamos os menus numéricos (1 faz isto, 2 faz aquilo). Depois, evoluímos para os menus suspensos no topo da aplicação. Eu achava aquilo um desperdício de teclas inacreditável. O usuário tinha de pressionar 'Alt' para chegar ao menu, depois usar as setas para a direita e esquerda para navegar(Clientes, Fornecedores, ...), e depois para cima e para baixo para achar o item, como "Novo Registro, Altera Registro, Apaga Registro...”.

Decidi mudar um pouco essa lógica, para criar um padrão de interface muito mais rápido. Abandonei os menus complexos. Criei um atalho: pressionar a tecla F8 abria um menu vertical simples, apenas com as entidades principais: Clientes, Fornecedores, Configurações, etc. . E abreviei todo o processo de CRUD (Cadastrar, Alterar, Apagar). No meu padrão, a tela de cadastro era inteligente. Se o utilizador digitasse "0" (zero) no campo de código e desse Enter, a aplicação já sabia que era um registro novo. Se digitasse "-1", a aplicação abria automaticamente que era um menu de consulta. Se carregasse um código existente, colocava na tela para alteração. No final, bastava pressionar F1 para salvar, e a própria aplicação saberia se devia fazer um "INSERT" (se era novo) ou um "UPDATE" (se era uma alteração). Para os meus clientes, isto foi um avanço enorme e uma grande economia de tempo e digitação.

Essa busca por otimização levou-me à descoberta seguinte. Depois de fazer dezenas de telas de cadastro (Clientes, Produtos, Fornecedores) em vários sistemas diferente que eu desenvolvi, eu percebi que estava a reescrever o mesmo código repetidamente, mudando o nome das variáveis apenas. As telas eram basicamente iguais; o "esqueleto" era o mesmo, só mudavam os nomes dos campos e, obviamente, os dados.

Foi aí, quando identifiquei o padrão, me veio uma ideia e criei o meu primeiro "gerador de programas", o que hoje o mercado chama de "low-code". Eu fiz uma ferramenta, em C86 no QNX, onde eu apenas precisava fazer uma coisa: definir o nome e os dados da tabela (o nome do campo, o tipo, o tamanho). Só isso. A minha aplicação lia essa definição e gerava todo o sistema para mim: as telas de cadastro, as consultas, e até relatórios básicos.

O impacto na minha empresa foi revolucionário. O que antes me levava semanas de programação manual, eu passei a fazer em dias, ou às vezes em horas. A ferramenta gerava uns 80% da aplicação; os outros 20% eram as personalizações para o cliente. (Mais tarde, acabei por replicar esta ideia e fiz geradores também para Clipper, Flagship e C++Builder).

Voltando um pouco no tempo, foi antes dessa época, no último ano da faculdade, que aprendi uma lição fundamental sobre arrogância. Eu achei que tinha descoberto o grande trunfo: uma maneira de acabar com as cópias piratas de disquetes. Criei um método num disquete de 5 1/4 e tentei copiá-lo de todas as maneiras que conhecia. Não consegui.

Num momento de extrema euforia, sentindo-me um génio, virei-me para um colega meu, o Fausto, e disse que daria 100 dólares (cem dólares!) a quem conseguisse copiar aquele disquete. O que eu não sabia era que o Fausto atuava numa empresa, e o chefe dele levou o desafio para o lado pessoal. O chefe dele tinha um programa que eu nem sabia que existia, que fazia uma "cópia física", bit a bit, ignorando a lógica do sistema de arquivos que eu tinha inventado.

Na semana seguinte, o Fausto voltou à minha casa. Não para dizer que tinha falhado, mas para buscar os 100 dólares. Eu fiquei louco. Fiquei com uma vergonha absurda, principalmente porque eu não tinha os 100 dólares para pagar. Eu pedi ao Fausto: "Cara, por favor, inventa lá que tu ouviste mal, diz que eram 10 dólares". O Fausto, que era um grande amigo, aceitou. Dei os 10 dólares pra ele. Ele levou-os para o chefe, que, ao aceitar, mandou-me um recado: disse que eu era um "cambão de 90 dólares". A vergonha que senti foi imensa. Eu achei que tinha descoberto a solução mágica, mas na verdade, eu apenas não tinha conhecimento suficiente do universo da informática. Naquele dia eu aprendi, e nunca mais esqueci: “haverá sempre alguém saberá mais do que tu”. Sempre.

Capítulo 5: O Pragmatismo (Clipper, Dados e Visão)

O QNX era robusto, rápido e economicamente imbatível para empresas de médio porte, como vários laboratórios e clínicas que tínhamos como cliente. No entanto, à medida que a CompCet tentava crescer, começámos a abordar clientes mais pequenos: lojas de calçados, restaurantes, bares, pequenas clínicas, vídeo-locadoras, entre outros ramos. Para estes negócios, o cenário era outro. Eles não tinham a estrutura (nem a necessidade) de um servidor dedicado e terminais. Eles tinham um ou dois computadores independentes, geralmente com DOS ou o recém-chegado Windows 95. Para eles, uma solução QNX não tinha sentido.

O mercado pequeno "falava" uma língua, e essa língua era o Clipper. Por pura necessidade de negócio, tive de me adaptar. O Clipper pareceu-me muito mais fácil do que o C, mas tinha uma desvantagem: em C, ao longo dos anos, eu já tinha construído a minha vasta biblioteca de funções para tudo. No Clipper, tive de começar do zero. Com o tempo, fui criando a minha biblioteca em Clipper também, e acabámos por desenvolver dezenas de sistemas para todo o tipo de pequeno comércio.

Foi nessa fase que aprendi que a funcionalidade mais importante de um sistema novo não era o que ele fazia, mas sim o que ele fazia com os dados antigos. A concorrência era feroz; nós tirávamos clientes de outros fornecedores, e eles tiravam clientes nossos. Quase sempre, o ponto decisivo da negociação era a migração dos dados. O cliente perguntava: "E o meu cadastro de clientes? O meu estoque? O meu financeiro? Eu vou perder tudo?".

Se tu conseguisses garantir a transformação total dos dados antigos para o teu sistema novo, era quase certo que o cliente vinha contigo. Isso hes dava uma tranquilidade que valia mais do que qualquer funcionalidade nova. Por necessidade de negócio, tive de me tornar um especialista em transformação de dados.

O desafio era que cada sistema concorrente gravava os dados de uma forma diferente. Eu pegava em tudo: arquivos DBF, arquivos .DAT, e os piores de todos, arquivos estruturais. Estes eram arquivos onde o programador original tinha gravado as estruturas em formato nativo e não em formato texto.

Para ler aquilo, eu não tinha o "mapa" do arquivo. Tinha que descobrir "na mão", na tentativa e erro, byte a byte, tentando adivinhar o tamanho de cada campo. Se errasse um byte no offset, não conseguia ler mais nada.

Até os processos mais simples, como o faturamento médico para convénios, era um campo minado. Os arquivos que enviávamos eram TXT’s com formatos exatos, posicionais. Se um campo ficasse um byte a mais para a esquerda ou para a direita, o lote inteiro do faturamento era rejeitado e o cliente não recebia. Perdi as contas quantas vezes fui ao IPERGS a pedido de um cliente porque o arquivo de faturamento tinha dado errado.

Um pouco antes de eu começar a programar clipper, já recebia arquvos DBF para converter, e como eu não conhecia o dBase III ou IV na altura para ler os arquivos DBF de forma simples, e precisava de ler todo o tipo de estrutura, acabei por escrever o meu próprio programa em C para ler arquivos, o "descascador de arquivos". Era uma ferramenta que "lia qualquer coisa". Eu passava parâmetros: se era texto ou estrutural, o tamanho do offset inicial, o tamanho de cada campo que eu queria ler, e ele lia o arquivo e trazia-me os dados mastigados.

O projeto mais cabeludo que peguei foi um arquivo “.DAT” que eu simplesmente não conseguia ler. Não era texto linear e não era uma estrutura binária que eu conseguisse decifrar. Parecia estar tudo criptografado. Depois de muito quebrar a cabeça, de olhar para os dados binários horas a fio, eu descobri o método: a "criptografia" era simplesmente que tudo estava gravado ao contrário, ou seja, as palavras estavam invertidas. Assim que descobri isso, foi fácil inverter tudo e ler o arquivo.

Naquela época, convertíamos até planilhas Lotus 1-2-3 para importar dados. Não era como hoje, que convertemos um Excel para CSV e lemos como um texto simples, formatado com ponto e vírgula. Era um processo árduo. Essa habilidade de "arqueólogo de dados" não me deu reputação alguma; não havia internet, ninguém fora da minha empresa sabia o que eu fazia. O que ela me deu foi algo muito mais valioso: vantagem competitiva para fechar contratos e mais tempo livre para desenvolver outras coisas, enquanto os concorrentes talvez ainda estivessem presos no grande problema da migração de migração de dados.

Essa mesma filosofia de otimização foi aplicada nos laudos médicos da Serdil. Como mencionei, eu não criei o sistema de macros (os códigos B1, B2 que traziam blocos de texto); isso foi a ideia genial do pessoal da ProSoft lá por 88, 89 . Aquilo dava uma produtividade absurda, permitindo fazer um laudo em segundos, substituindo as máquinas de escrever.

A minha grande contribuição ali foi na arquitetura de armazenamento. O sistema original da ProSoft usava uma fórmula matemática complexa para distribuir os arquivos de laudo por uma árvore de diretórios, para contornar a limitação do sistema operacional (talvez 5000 arquivos por pasta, algo assim). Eu olhei para aquilo e simplifiquei tudo. Criei um sistema de armazenamento muito mais lógico: criei uma árvore de diretórios baseada no mês e no dia do atendimento (ex: .../10/25/). O laudo era um arquivo de texto puro, gravado nessa pasta com o número do atendimento. Era simples, direto e à prova de falhas. Essa filosofia de guardar o laudo pronto (como arquivo) em vez de no banco de dados foi tão boa que a carreguei comigo durante décadas, adaptando-a depois para gerar laudos no Word e OpenOffice a partir dos meus sistemas Clipper e C++Builder.

Essa época forçou-nos a ser "escovadores de bits". O espaço em disco era contado milimetricamente. Por isso, uma prática comum da indústria era guardar os anos com apenas dois dígitos (YY) em vez de quatro (YYYY), simplesmente para economizar dois bytes em cada registro de dados. Quando modelávamos uma base de dados, tudo era calculado no detalhe.

Como programador, eu vi o problema a aproximar-se muito antes de o público ouvir falar dele, estuou falando do famoso "Bug do Milénio". O problema era simples: o que aconteceria quando 1999 (99) virasse 2000 (00)? Para o computador, 00 é menor que 99, o que quebraria todos os cálculos de validade, idade e financeiros. Prevendo isto, já em 1997, três anos antes da virada, todas as minhas aplicações já estavam a ser convertidas para usar quatro dígitos no ano. Foi uma antecipação que nos salvou de muitos problemas, enquanto víamos muitas aplicações de concorrentes pararem de funcionar exatamente por causa disso.

A gestão de memória era outro terror. Nós colocávamos todas as travas possíveis nos campos. Se um campo de nome de produto tinha 50 caracteres, era para ter no máximo 50. Mas, de alguma forma que eu nunca compreendi, os usuários conseguiam colocar 51 ou 52 caracteres. Lembro-me de um sistema de controlo de estoque que, de repente, começou a calcular tudo errado. Nós revisámos os cálculos, fizemos testes à mão, debbugávamos o código, e nada. Os cálculos estavam certos. Depois de rever milhares de dados, descobrimos o problema: num cadastro, um nome de produto que devia ter 50 caracteres, tinha 51. Esse um byte a mais causava um estouro de memória que corrompia o cálculo de todo o estoque, um simples byte a mais na descrição do produto.

Mas a lição mais dura dessa época não foi técnica. Foi de negócio. Estávamos a ir para uma feira médica apresentar o nosso sistema QNX. Eu tive a "brilhante ideia" de fazer um sistema completo para consultórios em Clipper, muito bom, totalmente configurável, e distribuí-lo de graça. Fiquei três meses a programar aquela aplicação. Peguei num monte de disquetes e levei-os para a feira, para os médicos pegarem gratuitamente.

E o que aconteceu? Absolutamente nada. Mesmo estando ali, de graça, os médicos não pegavam nos disquetes. Foi o meu primeiro grande balde de água fria. Eu não entendia: o produto era bom, era completo e era grátis. Muito tempo depois, é óbvio que eu entendi. Eu não tinha nada do que era preciso: eu não tinha marketing, não tinha networking, não tinha equipe de vendas, não tinha relacionamento comercial. Eu achava que bastava ter um produto bom e o mundo viria até mim. Foi uma lição dolorosa, mas essencial.

Capítulo 6: O Inferno e a Glória do "Full-Stack Raiz"

Hoje, o mundo da tecnologia é dividido em especializações. Existe o pessoal da infraestrutura, o pessoal de redes, os DBAs, os developers front-end, os back-end. Naquela época, nada disso existia. Quando vendíamos uma solução, especialmente uma solução complexa como o QNX, nós éramos responsáveis por tudo.

Se o monitor queimava, o cliente ligava para nós. Se a impressora parava de funcionar, a chamada era para nós. Tínhamos de montar as máquinas, instalar o sistema operacional, configurar as bases de dados e, literalmente, fazer o cabeamento. O cliente comprava uma solução completa, e nós éramos essa solução. E foi nessa realidade que enfrentámos os nossos maiores desafios técnicos.

O QNX era um sistema operacional de 8 bits, multitarefa, mas tinha fragilidades. A sua maior fragilidade era catastrófica: como ele tinha muita concorrência de tarefas, se a luz faltasse ou se alguém desligasse a máquina de forma incorreta (o que acontecia constantemente), ele "perdia o boot". Simplesmente não inicializava mais.

O número de vezes que tive de ir a um cliente reinstalar o QNX porque ele tinha perdido o boot é incontável. O processo para corrigir isto era um trabalho tremendo. Não havia como "recuperar" o boot. Tínhamos de pegar num disco rígido novo, instalar o QNX do zero, e depois ligar o disco rígido antigo do cliente como slave para tentar copiar os dados. Isto exigia configurar fisicamente os jumpers dos discos (um como master, outro como slave), e claro, ninguém tinha os mapas dos jumpers dos diferentes modelos de HD. Era um pesadelo.

Depois de sofrer muito com isto, comecei a investigar a fundo. Eu usava comandos que analisavam todos os setores do disco rígido, e ficava a olhar para os bytes na tela, para tentar descobrir um padrão. Eu via que o QNX chegava a iniciar um pouco, chegava a iniciar o load, mas depois travava. Deduzi que tinha de ser alguma informação gravada no próprio HD que o impedia de continuar.

Foram muitas vezes olhando para aqueles setores. Até que um dia, eu descobri. O QNX perdia o boot inteiro porque, de alguma maneira, durante a falha de energia, ele invertia os dois primeiros bytes do HD. Só isso. Todos aqueles anos de sofrimento, reinstalações e configurações de jumpers... por causa de dois bytes invertidos.

Com essa descoberta, criei uma ferramenta, juntamente com um colega, o Ederson. Chamamos de "mapa.ces". Nada mais era mais do que um mapa dos primeiros 20 bytes do disco rígido. Cada vez que instalávamos o QNX numa máquina nova, corríamos a nossa ferramenta e ela gerava o arquivo mapa.ces, que guardávamos além de deixar em uma pasta no hd, obviamente levávamos uma cópia para nós. Quando o cliente ligava dizendo que o sistema não iniciava, nós íamos lá, inicializávamos a máquina com um disquete de boot, usávamos um editor de bytes para escrever os bytes corretos de volta no setor de boot (usando o nosso mapa.ces como guia) e o sistema voltava a iniciar. Essa pequena ferramenta foi absolutamente salvadora para nós.

A nossa realidade "full-stack" ia até ao nível do ferro de solda. Os terminais burros do QNX comunicavam com os servidores via RS-232, ou seja, comunicação serial. Éramos nós que instalávamos tudo, o que significava que éramos nós que fazíamos os cabos. Tínhamos de soldar, pino a pino, os conectores DB9 e DB25. E tínhamos de saber os mapas das ligações dos pinos de cor. Lembro-me até hoje do mapa para ligar um cabo DB25 com DB25: fazer uma ponte com solda entre os pinos 4 e 5. Depois outra ponte entre o 6, o 8 e o 20. Mesma coisa com o outro conector. O pino 7 (terra) ligava com o pino 7 do outro lado. E depois vinha a comunicação: o pino 2 deste lado conectava com o 3 do outro lado, e o pino 2 do outro lado conectava com o 3 deste lado . Havia mapas diferentes para DB9 com DB9, ou DB25 com DB9. Pouca gente sabia esse padrão de criar conectores, poucas mesmo, e os que sabiam não queriam fazer um trabalho pequeno como esse, então, por necessidade, tivemos que assumir isso também.

Eventualmente, os terminais burros davam problemas. As empresas que faziam a manutenção demoravam muito a consertar. Um dia, um colega meu acompanhou um conserto e descobriu que, na maioria das vezes, o técnico trocava apenas um chip específico na placa. Pronto. Lá fomos nós começar a comprar esses chips e a consertar terminais burros também, tudo com o objetivo de ser mais rápidos.

Para ligar vários terminais a um único servidor (um, 286, 386, 486, ou um Pentium 100), precisávamos de placas multi-seriais. Usávamos umas de uma empresa chamada TAL. A instalação era toda física. Tinha de ser um modelo específico, recebíamos a placa e tínhamos de "jumpear" os endereços de memória corretos nela. Depois, tínhamos colocar na interrupção (IRQ) certa no computador (geralmente a IRQ 4) para que o PC a reconhecesse . Só depois disso é que dávamos um comando no QNX para ele reconhecer as novas portas seriais. E claro, isto exigia reiniciar o computador, o que, antes do "mapa.ces", era sempre um risco de perder o boot outra vez.

Se a instalação era assim, imagine o suporte. Naquela época não havia internet. Não havia como conectar-se remotamente à máquina do cliente. O suporte era feito por telefone fixo. O cliente ligava, descrevia o problema, e nós tínhamos de tentar entender e simular o bug na nossa máquina no escritório.

O cliente ficava, por vezes, vários dias com aquele problema. Quando descobríamos a correção, compilávamos o executável novo, gravávamos num disquete e enviávamos pelo correio. O tempo de resolução era medido em dias, na melhor das hipóteses.

Quando um incidente era muito grave, não havia alternativa: tínhamos de pegar no ônibus e ir até lá. Perdi a conta de quantas vezes, eu, com um notebook 286, ia programando, a noite inteira, dentro do ônibus de Porto Alegre para Uruguaiana, para conseguir chegar lá no outro dia de manhã já com a correção pronta.

E por vezes, a viagem era para descobrir o impensável. Lembro-me de um cliente em Chapecó que ligou para dizer que um terminal burro tinha parado de funcionar. Testámos tudo o que podíamos por telefone. Perguntamos pelo cabo, e o cliente jurava que o cabo estava íntegro, que não tinha arrebentado. Nada funcionava. Tivemos de viajar de Porto Alegre até Chapecó. Chegamos ao cliente e fomos inspecionar o cabo. Descobrimos que alguém tinha cortado o cabo RS-232 e feito uma "emenda" com fita durex. Sim, com Durex. Como é que um cabo de comunicação serial, que depende de sinais elétricos precisos, iria funcionar assim? Essa era a nossa realidade.

Capítulo 7: A Revolução Gráfica (Flagship, C++Builder e os Anos 2000)

Voltamos então a 1996. O mundo estava a mudar. O Windows consolidavasse cada vez mais e o mercado estava dividido: o mundo legado era dominado pelo Clipper, mas a grande novidade que estava a explodir em popularidade era o Delphi, baseado em Pascal. Eu comecei a estudar o Delphi, fiz vários cursos, mas nunca me apeguei ao Pascal. A minha formação e paixão sempre foi o C. Foi então que, num desses cursos de Delphi, um professor mencionou algo que mudou o meu rumo: "Olha, tem o C++Builder, que é a mesma coisa que o Delphi, só que em C". Fui imediatamente atrás e me apaixonei. Era o melhor dos dois mundos: o poder RAD (Rapid Application Development) do Delphi, onde eu podia "desenhar" a tela arrastando componentes, mas usando a sintaxe e o poder do C++.

Vendo a necessidade do mercado de migrar do texto para o gráfico, a minha primeira tentativa foi começar a migrar as minhas aplicações de consultório e clínicas do QNX/Clipper diretamente para o C++Builder. Mas não funcionou muito bem. Primeiro, porque eu ainda não dominava totalmente a ferramenta e nem o paradigma de orientação a eventos do Windows. Segundo, e mais importante, naquela fase inicial, o C++Builder, os estudos que eu tive e o que eu lia, era que dependia muito do BDE (Borland Database Engine) e de arquivos Paradox para a gestão de dados. Nos meus testes, eu não tinha tido uma boa experiência com eles.

Enquanto o C++Builder parecia promissor, mas não estava maduro (melhor falando: eu não estava maduro para ele), eu tinha uma necessidade de negócio imediata: eu precisava de uma alternativa moderna ao QNX. O QNX era fantástico, mas era um sistema operacional antigo, de 8 bits, e a sua manutenção era demasiado complexa, como vimos. Eu precisava de algo que rodasse em hardware moderno e sistemas operacionais mais acessíveis. Um problema que eu tive é que o QNX 3.21 não rodava em Pentium III 500, que eram os computadores da época. Foi uma dificuldade imensa fazer rodar nessa máquina, e as máquinas, a cada mês, davam um grande salto na tecnologia.

A solução veio do pragmatismo que aprendi com o Clipper. Como eu já tinha migrado grande parte da lógica da minha aplicação principal para Clipper (para atender os clientes pequenos), a minha grande jogada estratégica foi outra. Descobri o FlagShip, que era basicamente um compilador que pegava em código Clipper e o fazia rodar em Linux . Eu já tinha as aplicações em Clipper; a migração do QNX para o Clipper estava em grande parte feita. Converter o código Clipper para FlagShip foi "um tapa", coisa de fazer quatro ou cinco alterações no código e principalmente mudar os índices dos arquivos DBF.

Essa foi a nossa principal estratégia de migração. Abandonamos o QNX e passamos a nossa aplicação principal para FlagShip, rodando em Linux (usávamos o Conectiva 8, uma antiga distribuição nacional do Linux). Para o cliente, era uma solução fantástica: saíam de um sistema operacional proprietário e caro (QNX) para um sistema estável, moderno e barato (Linux), mantendo a performance e a lógica de terminais (o FlagShip funcionava em modo texto no Linux). A motivação foi pura necessidade de mercado.

Hoje, olhando para trás, vejo que deveria ter investido mais tempo no C++Builder naquela época; foi um arrependimento estratégico. Mas, na altura, o FlagShip resolveu o nosso problema imediato.

Contudo, eu não desisti do C++Builder. Enquanto a minha aplicação principal (saúde) rodava em FlagShip/Linux, eu usei o C++Builder para desenvolver a aplicação administrativa interna da CompCet. Todo o nosso controle de clientes, gestão de mensalidades, controle de atendimentos de suporte, emissão de boletos bancários e até a impressão de etiquetas para enviar as cobranças pelo correio, tudo isso foi feito numa aplicação Windows que construí em C++Builder . Foi ali que comecei a dominar a ferramenta de verdade.

Houve até uma "loucura" que criei nessa fase de transição: o nosso sistema QNX (que ainda rodava em alguns clientes) não tinha como gerar relatórios com gráficos. Um cliente precisava disso. A solução que criei foi um híbrido de duas eras: fiz a aplicação QNX (em C86) comunicar via porta serial (RS-232) com uma nova aplicação que fiz em C++Builder. O sistema antigo enviava os dados puros pela serial, a aplicação Windows recebia-os, processava-os e usava o "velho e bom QuickReport" (o gerador de relatórios do C++Builder) para imprimir o relatório final, já com os gráficos que o cliente queria.

Enquanto eu dominava a ferramenta, comecei a usá-la para criar projetos visionários, ferramentas que eu via que eram necessárias, muito antes de o mercado lhes dar um nome. Criei uma aplicação em C++Builder chamada "Screen Demand". Era basicamente um Jira: um gestor completo de tarefas e demandas, que fazia o controle total das demandas e atividades, inclusive com um workflow completo.

Criei outra ferramenta para mim, para gerar os status report dos projetos que eu tocava. Era uma aplicação que lia os arquivos do Microsoft Project ou do Project Libre, extraía os dados e gerava os meus próprios relatórios de status de projeto, muito mais detalhados e personalizados do que os que as ferramentas originais ofereciam.

Na virada dos anos 2000, o cenário mudou. O C++Builder amadureceu, tornou-se imensamente mais robusto e a sua comunicação com bancos de dados de verdade (como SQL Server e PostgreSQL) tornou-se muito mais simples e nativa, sem a dependência do BDE/Paradox. Houve uma evolução na ferramenta com a chegada de novos componentes, mas o principal foi a evolução do meu conhecimento sobre a ferramenta.

Foi aí que tomei a decisão final: reescrever tudo. Comecei, gradativamente, a migrar toda a aplicação principal (a de clínicas e laboratórios, que estava em FlagShip) para o C++Builder, usando agora um banco de dados SQL Server. Foi um processo que demorou alguns anos, porque eu estava desenvolvendo esta nova versão sozinho, enquanto eu e os outros colegas tínhamos de continuar a dar suporte e desenvolvimento às outras aplicações da empresa nas linguagens antigas.

Até que, no final da década de 2000, eu terminei. O resultado foi, sem dúvida, a melhor aplicação que eu já desenvolvi na minha vida: um sistema completo para clínicas e laboratórios, totalmente gráfico, robusto, seguro, feito inteiramente em C++Builder com SQL Server. Foi o culminar de décadas de experiência, desde o C86, passando pelo Clipper, até à maestria na ferramenta gráfica mais poderosa que encontrei.

Conclusão: O Valor da Experiência

A minha trajetória de 40 anos não parou no final da década de 2000. Eu continuo a programar e a resolver problemas complexos. A ferramenta que escolhi há quase 30 anos, o C++Builder, continua a ser a minha principal aliada para entregar performance que muitos consideram impossível.

A prova mais recente disso aconteceu agora, em 2020. Fui chamado para resolver um problema de processamento de dados em massa. A tarefa era receber dados em planilhas Excel extremamente complexas, que tinham mais de 40 estruturas diferentes e diversas regras de negócio aplicadas, e que convertia toda essa informação em scripts Oracle para importação direta a base de dados.

Antes da minha solução, existia uma aplicação que executava esta mesma tarefa. Para processar uma planilha com 600.000 registros, essa aplicação demorava uma semana. Sim, uma semana inteira de processamento. Usando o C++Builder e a experiência de décadas a "escovar bits" e a otimizar processos, construí uma nova aplicação do zero. Essa aplicação pegaria os mesmos 600.000 registros e executaria a mesma conversão, só que com muito mais funcionalidades e segurança, gerando todos os scripts necessários, em muito menos tempo: 30 minutos. O que levava uma semana, agora leva meia hora.

Isto, para mim, foi o valor prático da experiência. É o resultado de 40 anos a entender um problema desde o byte até à arquitetura.

Contudo, voltando ao tempo novamente, logo após eu terminar a minha aplicação em 2010, a capacidade comprovada de uma entrega, digamos atrasada, colidiu de frente com a realidade do mercado. A minha empresa, a CompCet, quebrou em 2012. A partir desse momento, mesmo com décadas de experiência e um domínio profundo de uma área de negócio (Saúde-SADT) e um histórico de resolução de problemas que iam do hardware ao software, tive uma dificuldade imensa em me colocar no mercado de trabalho.

Primeiro fiz o óbvio, procurei os meus grandes concorrentes, as maiores empresas de software de saúde do Brasil. Contei a minha história às pessoas dos Recursos Humanos, expliquei o que tinha construído, mas nunca tive uma única chance de conversar diretamente com alguém. As portas simplesmente não se abriram.

O episódio mais marcante dessa fase aconteceu em Porto Alegre. Havia uma grande empresa na área da saúde para a qual eu achava que o meu sistema seria uma aquisição valiosa. Eles não tinham sistema algum, eles são representantes de um grande sistema da área da saúde. Procurei-os e fiz uma oferta: eu estava oferecendo o meu sistema principal de clínicas e laboratórios (a melhor aplicação da minha vida, o resultado de anos de trabalho) completo, com todos os códigos-fonte. O responsável pela empresa não foi capaz nem de falar comigo. Ele mandou um estagiário pegar as informações da aplicação comigo.

É incrível como, até hoje, um profissional com este nível de conhecimento e um histórico de soluções comprovadas não é valorizado. Assim como eu, tem vários muito melhores do que eu, que tem a mesma dificuldade.

Novamente, voltando ao tempo, em 2012, consegui uma oportunidade no Rio de Janeiro, na Tecnoarte, onde atuei por um tempo, o que foi uma experiência muito boa. Mas acabei por voltar para o Rio Grande do Sul e, mais uma vez, enfrentei dificuldades em conseguir uma posição para aplicar o meu maior domínio, a área da saúde.

De lá para cá, tenho atuado em diversas funções: fui gerente de projetos, voltei a ser programador Clipper, programador C++Builder, atuei como agilista e como líder técnico de equipes Clipper, Java e “.Net”. São funções super importantes, que ampliaram a visão dos desafios da engenharia de software. Mas não posso negar que a minha habilidade central: capacidade de unir a engenharia de software, a engenharia de dados (incluindo a 'arqueologia' de sistemas legados) , com a arquitetura de produtos complexos e o domínio profundo das regras de negócio, continua a ser o meu maior ativo. É nessa intersecção, independentemente do setor, que está a minha maior capacidade de gerar impacto e transformação.

As Lições

Ao olhar para trás, para estas quatro décadas, vejo lições que resistiram ao tempo. A primeira é o valor do fundamento. A minha capacidade de otimizar um processo de uma semana para 30 minutos em 2020 não aconteceu apesar do meu conhecimento "antigo" do C e do QNX; ela aconteceu exatamente por causa dele. Numa era de abstrações infinitas, a maioria dos profissionais sabe usar a ferramenta, mas poucos entendem a máquina. Ter sido um "escovador de bits", forçado a contar bytes e a analisar setores de disco, deu-me uma visão fundamental que a tecnologia moderna não ensina, mas da qual ainda depende desesperadamente.

A segunda lição é que as ferramentas mudam, mas a resiliência é eterna. A tecnologia que usei (TK 85, C86, Clipper, C++Builder) evoluiu, mas o desafio central da engenharia de software nunca mudou: resolver um problema que parece impossível, sob pressão, com restrições severas. A resiliência mental necessária para programar a noite inteira num ônibus para Uruguaiana, ou a teimosia para fazer uma impressora funcionar quando a própria fábrica dizia ser impossível, é exatamente a mesma "skill" necessária hoje para depurar um sistema complexo em produção.

Mas a tecnologia é apenas metade da equação. Um arquiteto constrói sistemas, mas um líder constrói equipes. A lição mais profunda que aprendi é que a matéria-prima da liderança não são "recursos", mas almas. Recuso-me a ser um capataz; escolhi ser um "arquiteto de almas". Enquanto o mercado corporativo cria culturas baseadas no medo, aquele "silêncio que adoece" nas reuniões, eu descobri que equipes de alta performance (seja em Clipper, Java ou .Net) nascem do exato oposto: da segurança psicológica.

O meu método sempre foi demolir essa cultura do medo, começando pela minha própria vulnerabilidade. A minha equipe sabe que quando um erro grave acontece, a minha primeira pergunta nunca é "quem errou?", mas sim "você está bem?" e "o que nós podemos aprender com isto?". Ao assumir os meus próprios erros abertamente, eu dou à minha "tropa" o direito de ser humana. O erro deixa de ser uma vergonha e torna-se uma "cicatriz de batalha", uma lição paga pela equipe inteira.

Num ambiente de pressão e prazos, a minha ferramenta de gestão mais poderosa nunca foi o chicote, mas a alquimia do riso. Eu uso o humor e a piada autodepreciativa para quebrar a tensão, para dissipar o "clima de velório" de uma reunião difícil. O líder que ri do próprio tombo dá a todos a permissão para serem falíveis. E quando noto o "fantasma na baia", o colega cuja alma está ausente, eu entendo que a lógica perversa de "deixar os problemas em casa" falhou. O meu dever é oferecer o "gesto que liberta": um "vá para casa cuidar do seu filho", um apoio real que planta a lealdade que dinheiro algum pode comprar.

Rejeito a ideia da "família de fachada" que o mundo corporativo usa para manipular. O que eu construo é um "clã de propósito": uma tropa unida não por sangue, mas por um pacto de respeito mútuo e compromisso.

No fim, esta é a grande ironia que a minha história revela: o mercado atual, através dos seus processos de seleção, procura desesperadamente por "cultura", "agilidade" e "alta performance", mas muitas vezes filtra os seus candidatos por palavras-chave de frameworks novos, descartando a experiência profunda. Eles valorizam o currículo, mas falham em ver a alma. A minha métrica de sucesso não está nos lucros; está na paz de espírito de ter provado que a canção mais sublime de uma equipe de alta performance é, e sempre será, o riso.