A palavra de ordem é objetividade. O grande desafio de qualquer programador é escrever código que seja objetivo, ou seja, a menor quantidade de código possível que resolva um problema proposto. Sem frescura, sem invenção de moda, sem a preocupação de demonstrar conhecimento. Curto e grosso. No entanto, não é sempre assim na área de computação. É comum encontrar engenharia de foguete onde deveria ter, no máximo, uma casinha de sapé.

Design Pattern à força

Há programadores que querem usar design patterns de qualquer maneira em seus códigos. É bonito, é elegante, mas em grande parte do tempo desnecessário. Você deve usar design patterns onde eles são necessários e não por que você os conhece. Infelizmente há programadores que forçam o uso de design patterns para a resolução de problemas de programação. O efeito colateral é código complexo, altos footprint e consumo de recursos.

O resultado é apenas um: código desnecessariamente complexo, de difícil manutenção e com problemas que não acabam mais. Não é incomum ver software coberto de defeitos sem fim que nunca são totalmente consertados.

Desenhe antes de programar!

Gaste todo o tempo do mundo desenhando e planejando o que você vai fazer antes de sair programando como um animal de carga que não olha para os lados. É possível fazer desenvolvimento e design incrementais, mas isso exige muita disciplina. Desenhe antes! Faça esquemas, use papel, lápis, caneta, faça disso uma arte. Não comece a programar a menos que você já tenha estruturado tudo o que você vai fazer antes.

A falta de desenho antes de iniciar a programação leva a código confuso, principalmente para programadores sem muita experiência. Código sem desenho é altamente acoplado, com falhas de encapsulamento e com problemas tais que chegam a ser gritantes. Desenhe antes, programe depois. E entenda que mesmo depois de haver desenhado o que você vai fazer, você precisará ajustar seu desenho durante a escrita do código. É um trabalho interativo.

Leia e pesquise

Pesquise sobre a linguagem e o ambiente que você vai utilizar antes de sair programando. Por que isso? Para evitar quer você saia escrevendo código que já existe. Não acredite e não seja pretensioso de achar que seu código é melhor do que o código de um SDK ou biblioteca. O seu código nunca foi testado pois você o está escrevendo agora. O código do SDK ou biblioteca já foi muito testado, consertado, alterado e evoluído. Programe com humildade.

Replicar em código o que já existe é comum de quem sai programando com viseira, sem olhar para os lados, preocupado apenas com o prazo final. Sim, o prazo de entrega é importante. Mas é importante, também, que o software chegue lá funcionando. Não adianta nada atingir um prazo final com um software cheio de problemas. Isso irá te ocupar desnecessariamente e consumirá os recursos do projeto a ponto de levá-lo ao prejuízo. Dependendo do tamanho do prejuízo seu emprego estará em xeque.