Comecei Por Necessidade, Não Por Plano

01Comecei Por Necessidade, Não Por Plano

Não houve um dia em que decidi tornar-me técnico. Houve um relatório semanal chato, feito à mão, que me fazia perder uma tarde. Automatizá-lo não foi o primeiro passo de um plano de carreira, foi só a forma mais óbvia de deixar de perder aquela tarde.

É uma história menos elegante do que "sempre soube que quereria construir coisas", e é a verdadeira. A maior parte de quem conheço que construiu competência técnica a sério, mais tarde na vida, chegou lá por um caminho parecido: um problema concreto, resolvido, depois outro, depois outro, sem plano nenhum a amarrar os pontos até se olhar para trás.

02O Diploma Que Ficou Parado Quinze Anos

A minha vocação era TI. Tenho um certificado em Ciência da Computação e Informática de 2007. Durante quinze anos, não escrevi código a sério. Trabalhei em apoio ao cliente, depois em qualidade, depois em formação. O diploma existia numa gaveta, tecnicamente verdadeiro no currículo, irrelevante na prática.

Isto contraria uma ideia comum: que uma base formal antiga te dá vantagem quando finalmente decides usá-la. Na minha experiência, deu quase nenhuma. O que sabia de 2007 estava desatualizado, e o hábito de programar tinha desaparecido por completo. O que realmente contou, quando voltei a construir, não foi o que tinha aprendido então. Foi a disciplina que trouxe de outro sítio, o que é o tema do capítulo 4.

Se tens formação técnica antiga e parada, o conselho é simples e desconfortável: não contes com ela como vantagem. Conta com ela, no máximo, como prova de que já uma vez conseguiste aprender isto, o que ainda serve de alguma coisa, só não é o que te vai levar mais longe agora.

03O Primeiro Script Que Importou

A minha primeira exposição relevante a programação aplicada foi já como Technical Trainer, a construir ferramentas de automação em Python para reduzir erro manual na administração da formação. Não era um sistema, não estava em produção para clientes, não tinha arquitetura nenhuma que merecesse o nome. Fazia uma coisa chata deixar de ser feita à mão.

É tentador desvalorizar esse tipo de primeiro projeto, por ser pequeno e sem consequência para ninguém além de ti. É exatamente o oposto do que interessa: é pequeno e sem consequência que faz dele o sítio certo para começar. Erras à vontade, sem ninguém a depender do resultado, e aprendes o suficiente para o projeto seguinte já não ser o primeiro.

04Disciplina Importada, Não Aprendida de Novo

O que realmente transferiu da década em qualidade e formação para construir software não foi conhecimento técnico, era zero. Foi disciplina: critérios escritos antes de avaliar, verificação antes de confiar, mais do que um avaliador antes de decidir. É a mesma disciplina que descrevo, aplicada a código, no guia sobre verificar o que a IA constrói.

Isto é uma boa notícia para quem vem de um percurso não técnico: a disciplina que já tens, de qualquer área a sério, provavelmente transfere melhor do que imaginas. O que falta não é caráter, é vocabulário e prática específica. O vocabulário aprende-se relativamente depressa. A disciplina, se já a tiveres, não precisa de ser aprendida de novo.

05Começa Pelo Que Te Dói, Não Pela Teoria

K. Anders Ericsson, num trabalho de referência de 1993 sobre a aquisição de desempenho de perito, mostra que o que distingue quem melhora depressa não é o tempo total gasto, é a prática deliberada: tarefas específicas, com feedback imediato sobre o que correu mal, a repetir a parte que falhou até deixar de falhar. Estudar teoria sem aplicação imediata não é isso.

Um problema real teu, por pequeno que seja, dá-te prática deliberada de graça: sabes exatamente quando funcionou (o problema desapareceu) e quando não funcionou (continuas com o mesmo relatório chato à tarde seguinte). Um curso genérico raramente dá esse feedback tão imediato nem tão pessoal.

06O Salto de Scripts a Sistemas

Um script resolve um problema uma vez, para ti. Um sistema continua a funcionar quando tu não estás a olhar, para pessoas que nunca vais conhecer, com dados que não controlas. A distância entre os dois não é de tamanho, é de responsabilidade: um script que falha custa-te uma tarde chata outra vez, um sistema que falha custa a outra pessoa alguma coisa que ela não escolheu arriscar.

O salto não aconteceu de repente. Foi cada projeto a exigir um pouco mais do que o anterior: primeiro só automatizar, depois lidar com o caso em que algo corre mal, depois lidar com mais do que uma pessoa a usar ao mesmo tempo, depois com dinheiro real a passar por ali. Cada exigência nova ensinou uma coisa que o projeto anterior não tinha pedido.

Não saltes esta progressão de propósito, com medo de "perder tempo" em projetos pequenos. É nos projetos pequenos que se aprende, sem custo grave, o que falta para os grandes.

07Construir Não Chega

Aprender a construir resolve metade do problema. A outra metade é conseguir que alguém use o que construíste, e é fácil, vindo de um percurso técnico recente, achar que a segunda metade se resolve sozinha se a primeira estiver bem feita. Não se resolve.

Já escrevi um guia inteiro sobre isso, sobre porque a competência técnica não substitui adoção e o que fazer quanto a isso. Não repito aqui, só deixo o aviso: se estás a meio do caminho deste guia, a aprender a construir, vale a pena leres também o outro antes de assumires que construir bem é suficiente.

08Ainda Estou a Meio do Caminho

Seria mais confortável fechar este guia como uma história de chegada: comecei do zero, cheguei lá, aqui está o mapa. Não é verdade. Construo e opero vários projetos, e nenhum me sustenta ainda por si só. Continuo, todos os dias, a aprender coisas que um percurso técnico contínuo teria ensinado há muito.

Isto não é falsa modéstia, é a razão de este guia existir: se estiveres à espera de sentir que "chegaste" antes de te considerares um construtor a sério, vais esperar mais tempo do que precisas. Ninguém, incluindo eu, sente isso tão cedo como gostava.