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.