O programador é uma máquina de transformar café em código. Essa piada, muito comum no nosso meio, pode até ser engraçada, mas é baita armadilha.

Pense bem, dizer que precisamos de café para trabalhar deixa implícita a ideia de que vamos programar por horas a fio. Isso significa dizer que vamos fazer horas extras (e sem receber por isso, claro) e ter menos tempo de qualidade com a família.

Com isso, começamos a naturalizar esse círculo vicioso de trabalho árduo e sufocante de correr atrás de prazos inviáveis para entregar projetos que muitas vezes nem vão pro ar.

Daí vem a pergunta: o que é ser programador? É viver nessa eterna ralação? Não!

Ser programador é ter a capacidade de, com custo virtualmente zero, criar riqueza por meio de código, de bits e bytes.

Mas para fazer isso, temos que mudar o mindset. Temos que deixar de ser entregadores de demandas para nos tornar solucionadores de problemas.

Caso contrário, corremos o risco de viver como um hamster correndo naquelas rodinhas — fazemos muito esforço, mas não saímos do lugar, não evoluímos como profissionais, nem como pessoas.

Na minha jornada, entendi que para termos uma carreira que nos traga um bom retorno — tanto financeiro, quanto emocional — é preciso entender que o papel de um programador não é criar software, mas sim entender como usar a tecnologia para aumentar a capacidade de interação, realização e solução de problemas.

Por essa razão, nesta série de três artigos, vou compartilhar com você 10 habilidades-chaves que me ajudaram a sair desse modelo alienado de desenvolvimento de software — que destrói nossa qualidade de vida — e me permitiram ser um programador eficaz, que gera mais valor e tem mais autonomia.

Neste texto, falaremos das três primeiras habilidades.

1) Programe apoiado por testes

Programar apoiada por testes é um meio pelo qual a gente usa o processo científico para desenvolver soluções. Tradicionalmente, os programadores se tratam como criativos. Pensam de forma abstrata, pensam por intuição.

Na hora de programar, porém, a coisa vai ficando bagunçada se você não tem um método de desenvolvimento. Quando você faz o TDD (desenvolvimento guiado por testes), você utiliza uma estrutura científica e cria um teste como um resultado desejado.

Daí, você faz o percurso de trás pra frente. A partir do resultado desejado, você cria o menor código, a menor solução capaz de gerar esse resultado.

Esse processo funciona como o MVP do pedaço de código. O menor código viável, porque você faz primeiro uma gambiarra que funciona. A partir desse ponto, você vai melhorando. O interessante é que você parte de algo que já funciona. Essa é a grande questão.

Cada novo teste tem o objetivo de aumentar a capacidade do código. O resultado disso é que você passa a ter um programa que atende necessariamente a requisitos expressos em código. E você também tem um conjunto de códigos que valida que o programa se comporta da maneira desejada.

Isso é o básico para você fazer um monte de outras coisas, como mudar o código sem medo, por exemplo. Isso é crucial.

O TDD, além de ser uma ferramenta de criação de código, é um processo de trabalho que vai , de forma incremental, aumentando a capacidade do seu software até que ele atenda a todos os requisitos necessários.

2) Trabalhe com ciclos curtos de feedback

A essência do ciclo de feedback é que, quando o cliente me diz o que ele quer, eu tenho que ter certeza que eu entendi. Então, eu preciso verificar o mais rápido possível se meu entendimento está correto.

Um problema comum no desenvolvimento de software é que a galera leva semanas — e até meses — para validar que entendeu adequadamente o problema que precisa ser resolvido.

Isso aumenta o risco, porque qualquer caminho errado, qualquer desentendimento te custa o tempo total da equipe e o salário de duas ou três semanas do time inteiro. E tem projetos que são meses! Isso é um problemão.

Nesse sentido, o ciclo de feedback é importante para você estar o tempo todo tratando o seu entendimento sobre o que o cliente precisa como uma hipótese. Por mais que você tenha uma puta convicção, você não deve tratar isso como certeza.

Você calça a sandália da humildade e considera que pode ter entendido errado ou que o cliente não soube explicar — o que é muito comum.

Então, você trata toda demanda de código como uma hipótese de que aquilo é realmente a coisa certa a fazer. Para lidar com o risco, eu intensifico o ciclo de feedback.

O tempo entre eu entender o que o cara falou, mexer no código e mostrar o resultado para ele na prática tem que tender a zero. O tempo entre a dúvida e a certeza tem de ser o menor possível.

O ideal é que, se possível, você faça um novo deploy e lance uma versão nova para o cliente todos os dias, mesmo que essa versão não vá para produção. O importante é que alguém seja capaz de usar aquilo que você produziu.

Enquanto isso não acontece, você não entregou valor.

A forma de intensificar o ciclo de feedback é reduzir o escopo. Para isso, você pode fazer mudanças pequenas, usar testes para validar se o que você está fazendo atende à expectativa e usar os testes anteriores para garantir que suas mudanças não quebraram nada que já estava funcionando.

Se tudo estiver funcionando, legal! Você bota no ar para o cliente ver, valida e segue o desenvolvimento. Dessa maneira, o cliente vai vendo o software surgir na frente dele, o que:

• Aumenta a confiança dele no seu trabalho;

• Aumenta a certeza de que o projeto vai dar certo;

• Reduz os riscos do projeto;

• Intensifica os investimentos.

Além disso, essa estratégia evite estresse desnecessário e mantém um ambiente de trabalho saudável e produtivo.

3) Planeje de trás pra frente — backward planning

É muito comum, quando se planeja alguma coisa, a gente pensar em passos sequenciais: primeiro eu faço isso, depois isso, depois aquilo.

O problema dessa estratégia é que você não tem claro qual é o ponto de chegada. Então, o backward planning é como usar o Google maps no seu projeto de software.

Você entende qual a sua origem — o presente –, decide o destino e aí calcula rotas possíveis. O desafio é você encontrar a menor rota que resolve o problema — é a questão do 80/20.

O interessante dessa estratégia é que eu estou sempre olhando para o meu objetivo final. Eu estou sempre olhando para o centro do alvo para poder soltar minha flecha pro lugar certo, em vez de ficar atirando igual macaco com a arma na mão.

Com isso, você consegue sempre manter o foco no que é importante. Isso te ajuda a fugir das falsas urgências e das demandas sem pé nem cabeça, que são apenas caprichos do cliente.