No artigo anterior, eu falei sobre três das dez habilidade-chaves que um desenvolvedor deve ter para ser mais eficaz e evoluir na carreira.

Vimos que é fundamental trabalhar apoiado por testes (1), para evoluir seu código de forma segura e sustentável. Essa prática é complementada pela estratégia de ciclos curtos de feedback (2), que permitem que valide sua ideia com o cliente o mais rápido possível — evitando desperdício de tempo e dinheiro.

Por fim, explicamos a importância de usar o backward planning (3), para planejar de trás para frente. Assim, você garante que seu trabalho sempre vai estar direcionado ao seu objetivo final.

Neste artigo, vamos tratar de mais quatro habilidades-chaves que aprendi na minha jornada. Elas me permitiram reprogramar a minha vida e a minha carreira para ter mais autonomia e ampliar o número de caminhos possíveis.

4) Elimine os delays

Sua forma de programar tem de eliminar esperas entre uma etapa e outra. Por exemplo, uma situação muito comum é que as pessoas programam, programam, programam e depois tem um monte de coisa para colocar no ar. Daí, todo mundo tem que ficar esperando uma janela de deploy, uma janela de homologação.

Isso tudo vai atrasando o projeto indefinidamente. Daí, você vai criando uma série de gambiarras para que as coisas funcionem. Se funciona de primeira, é lindo.

O problema é que isso nunca acontece.

Imagina que você entra nessa esteira e tem que esperar 15 dias para homologar e depois mais 15 dias para ir pra produção. E, quando vai pra produção, rola uma verificação que mostra que tinha um erro.

Pronto! Você perdeu um mês. Tem que voltar tudo e recomeçar o desenvolvimento.

Então, o time trabalha em um momento de demandas, mas não conclui nenhuma delas, porque o ciclo de entrega tá cheio de gargalo, tá cheio de delay.

Por isso, você tem que ser capaz de ter um sistema de integração contínua, no qual você cria o teste do código direto na sua máquina. Se você rodou o teste e está tudo funcionando, você manda o código pra um repositório — um Github da vida -, que dispara todo um processo de verificações automáticas.

Se tudo der certo, no final do processo, automaticamente esse código já entra em produção.

Em resumo, eliminar delays é você conseguir zerar os gargalos que geram espera e que podem virar atrasos no seu projeto. Isso diz respeito não só à forma como você programa, mas como você trabalha para se integrar ao processo de produção como um todo.

5) Reduza o custo do setup

Organize-se como um chefe de cozinha. Tenha tudo à mão. Uma das grandes dificuldades quando alguém entra no projeto é o custo de setup.

Quando o projeto está bem organizado, o custo de setup é zero. Alguém entra na empresa hoje e o cara com um comando já consegue acessar o projeto para começar a trabalhar.

Tem lugares, porém, que esse processo leva semanas.

O cara tem que preparar a máquina, instalar um monte de coisa, fazer várias configurações na mão. É uma verdadeira corrida de obstáculos. Isso acontece, porque o cenário não tá bem arrumado.

Isso é caro pra empresa, atrasa o projeto, aumenta o risco quando há troca de pessoas na sua equipe e é um sintoma de que seu projeto não está bem organizado — não só no nível do código, mas também no ambiente de desenvolvimento.

Por isso é muito importante — e eu faço isso nos meus projetos — que, quando alguém queira contribuir, consiga fazer isso com um comando apenas. Esse script não vai fazer o trabalho completo, mas vai sinalizar o que está faltando.

Com isso, a pessoa pode começar a rodar o sistema na máquina dele a partir do primeiro minuto que ele entrou na empresa.

6) Trabalhe com um único codebase para todas as instâncias

Um ambiente de integração contínua envolve rodar o código em diferentes instâncias para poder identificar e corrigir falhas. Assim, você entende o comportamento dele em diferentes ambientes.

Onde que mora o problema? É muito comum alguém pegar o código-fonte para configurar o projeto e configurar algo fixo dentro do código — por exemplo, o diretório onde ele está armazenado ou endereço do banco de dados.

Quando o colega vai usar o mesmo código, ele não tem a mesma estrutura de diretório. É aí que o código quebra.

Para não cair nesse buraco, você tem que separar os pedaços do software que são configurações de instância dos outros pedaços que são configuração de projeto, do código em si.

Por exemplo, configuração de projeto: o software faz login com Facebook. Agora definir o app do Facebook que vai ser usado para essa tarefa já é uma configuração de instância.

Assim, você tem que ter uma forma de desacoplar esses dois universos para que o mesmo código — sem nenhuma alteração, apenas com complementos de configuração por ambiente — consiga rodar em qualquer ambiente que eu desejar.

7) Crie experimentos para validar as estratégias

Quando eu encontro um problema que eu quero resolver, eu tento identificar quais são seus pontos críticos. A partir daí, eu crio pequenos experimentos para entender, enquadrar e validar esses itens.

Não necessariamente eu faço isso dentro do meu código. Eu posso criar códigos separados para exercitar esse processo e entender onde está o risco da minha estratégia de resolução do problema.

Sempre há escolhas a fazer e, muitas vezes, as pessoas pensam que existem soluções mágicas. Por exemplo, o dev diz “se eu usar banco relacional vai ser melhor”.

Nesse cenário, você deve se perguntar não só se vai mesmo ser melhor, mas se é necessário fazer isso e se sua equipe entende desse assunto.

As pessoas acreditam muito em ferramentas, quando deveriam acreditar em métodos de trabalho e em estratégias.

Criar experimentos é o processo empírico e científico de abordar a questão.

O problema é que as pessoas veem a prova de conceito como custo, porque elas fazem as coisas sem muita reflexão. Mas ela é algo essencial.

A prova de conceito tem que ter um alinhamento estratégico bem definido com as particularidades do seu projeto.

Eu uso muito essa técnica. Monto pequenos programinhas que vão validar minha estratégia. E por que eu faço isso? Porque, se eu tentar fazer esses experimentos por dentro do meu código, pode ser que eu tenha vários obstáculos.

Então, quando eu crio esses experimentos de forma isolada, eu não preciso lidar com essas restrições. Eu consigo ir direto ao ponto.

Amplie seus horizontes e enxergue o que está além da programação

Os quatros pontos que abordei neste artigo e os três do primeiro texto compõem aquilo que está além da programação. Minha vida e minha carreira deram um salto quando percebi que o trabalho do programador não é escrever código, mas sim resolver problemas.

Para fazer isso, é preciso entender que o software que você desenvolve é só uma parte da jornada. O que importa mesmo é aquilo que acontece quando alguém usa o programa que você desenvolveu.

Essa é uma nova visão da programação, que te permite assumir as rédeas da sua vida e criar seu próprio caminho — alinhado com seu propósito.

Grande Abraço, HB!