Nós que escrevemos linhas de código para viver colocamos os programas em um pedestal. Nós programamos no tempo livre. Falamos em código em termos estéticos e até mesmo dizemos que alguns código são obras de arte. Para nós, é natural achar que a coisa de mais valor em uma empresa (sobretudo as empresas de tecnologia) é o código que escrevemos. Para nós, o código tem um valor intrínseco.

Aos poucos eu comecei a perceber algo que mudou totalmente meu comportamento profissional e acho que a maioria dos programadores se beneficiariam em aprender isto:

Código não vale nada.

Código só vale o que traz de valor para o negócio, o resultado. Isso até mesmo em empresas de tecnologia. Um programa pode ter o código mais limpo possível, bem documentado e cheio de testes, mas se não agrega valor ao negócio, então seria melhor não tê-lo.

Códigos como o do buscador do Google, ou o algoritmo de relevância do Facebook geram muito valor para essas empresas. Mas possivelmente o Uber não vai ganhar nada implementando um mensageiro instantâneo para que seus funcionários se comuniquem.

Pense em código como um administrador pensa em estoque. Construir um estoque tem custo, que retornará em forma de lucro somente em um futuro incerto. Estoque ocupa espaço gerando custos. Alguns produtos apodrecem. A maioria dos produtos desvaloriza com o tempo.

Da mesma forma todo o código de uma empresa gera custos. O custo de manter a infraestrutura do código. O custo de manter a documentação atualizada. Se os desenvolvedores originais de um projeto vão para outras empresas, muitas vezes muito conhecimento é perdido e aí temos o custo de aprendizado de todo uma base de código para novos funcionários.

Se o custo de produzir um software in-house for maior do que usar uma alternativa open source ou comprar um licença, então não crie o software. Por mais que seja um problema interessante e que vai ficar ótimo no seu currículo, o melhor para empresa é que você use alguma biblioteca ou idealmente encontre uma alternativa que não gere custos.

Entre duas soluções que resolvem um problema, a melhor é que usa menos código. Se uma fórmula no Excel resolve o problema para uma empresa, pode não fazer sentido implementar uma aplicação Web baseada em microserviços que implementa uma REST API. Talvez o melhor seja só usar a tal planilha.

Algumas vezes desenvolvedores afirmam que “é mais fácil implementar que usar uma biblioteca”, ou seja, é mais fácil escrever uma nova implementação de algo que já existe do que usar algo que já está pronto. Essa afirmação pode ser verdadeira em alguns casos, mas em geral o melhor é usar coisas já prontas. Existe uma economia de escala, então possivelmente o custo de comprar uma solução é menor que criar uma do zero. Além disso a biblioteca será melhor documentada pois existem outras pessoas no mundo usando e pode até mesmo ser possível contratar pessoas que já têm experiência com aquela solução, algo impossível se você cozinhar o seu próprio código.

Os desenvolvedores então não têm que se focar em escrever o máximo de código possível, não somos pagos para escrever código e sim para solucionar problemas. Se a melhor forma de resolver o problema é escrevendo código, então devemos escrever código. Mas se podemos minimizar a quantidade de código escrita, seja procurando uma alternativa ou comprando software, daí estamos agregando o máximo de valor à empresa.