Evolua a sua carreira na programação — Parte 1/3

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.

Programe sem ser programado

Os três pontos que abordei neste artigo compõem uma nova visão do desenvolvimento de software. O foco está naquilo que está além da programação. Isso abrange uma série de elementos que te permite usar seu conhecimento de forma estratégica para ampliar o número de caminhos possíveis para sua vida.

Esse será um dos temas do Welcome to the Django, que começará em breve, no dia 20 de maio de 2019.

Se você quer recuperar o prazer em programar e quer usar suas habilidades para ter mais liberdade e qualidade de vida, esse curso é pra você.

Abriremos as matrículas no dia 07 de maio de 2019! Se inscreva aqui no site para receber todas as informações em primeira mão.

PS: Na próxima semana, vou falar de mais quatro das 10 habilidade-chaves que vão te ajudar a evoluir na sua carreira de programador. Até lá!