Como ser um ótimo programador todo mundo sabe. Mas e que tal o contrário? Eu separei aqui embaixo alguns erros que diversos programadores iniciantes cometem (aposto que você já fez ou viu alguém fazer a maioria), e o porquê de não fazê-los. Divirta-se.

Commits motivacionais

"Bom dia, aqui eu corrigi um bug e melhorei o sistema", pode parecer piada mas eu já vi um commit como o anterior. Com certeza, é inspirador. Com certeza te motiva a trabalhar mais. E com certeza te faz pensar por 4 segundos antes de entender o que acabou de acontecer.

Não faça os outros programadores pensarem, muito menos com commits motivacionais que não dizem absolutamente nada. Isso é completamente irritante e custoso.

Seus comentários são um livro, então banque o Shakespeare

O que você pensa do commit abaixo?

// a função abaixo possui o objetivo de analisar um documento de CPF
// que pode ser adquirido ao dialogar com órgãos responsáveis do
// governo brasileiro e possui como objetivo identificar uma pessoa
// física por um número de 11 dígitos
// a função irá validar o registro do CPF através de um cálculo que 
// demonstrará se o CPF está correto ou se é simplesmente um conjunto 
// aleatório de números passados pelo programador
function funcaoAnalisaCpf(cpf)
{
    // codigo
}

Vamos começar pelo fato de que o comentário possui 7 linhas que poderiam ser resumidas em apenas trocar o nome da função para validaCpf. Depois, leia esse comentário: ele não diz absolutamente nada de relevante para o desenvolvedor. É simplesmente um lixo virtual que, além de não trazer absolutamente nada. Você poderia mudar essa função para:

function validaCpf(cpf)
{
    // codigo
}

Aí você pode perguntar "mas você tirou todos os comentários". Isso mesmo. Um comentário só deve explicar o que o código não consegue fazer sozinho. Eu geralmente só uso comentários para coisas extremamente confusas, como uma expressão em regex solta no meio do nada. Não precisa ser o Shakespeare, apenas tenha bom senso.

Gambiarra não, melhoria temporária permanente

Não tem problema fazer uma gambiarra para solucionar um problema que o cliente está reportando em 5 minutos e depois gastar mais tempo pra fazer da forma correta sem que o cliente perceba que a resolução demorou mais que 5 minutos. O problema é quando você faz a gambiarra e não corrige depois. Se você faz isso uma vez, você vai fazer outras, e isso vai virando uma bola de neve, até que o sistema vire um caos.

Simplesmente não faça isso, tente ao máximo não fazer gambiarras ou códigos sujos, e, se fizer, corrija o mais rápido possível. É de vital importância para "manter a casa em ordem" e evitar a anarquia completa no seu projeto.

Eu sou especialista em fazer "Hello World" em dois bilhões de linguagens

Fim de semana chegou e você decidiu aprender algo novo. Ao invés de começar um curso de aprimoramento do seu framework preferido, você, como em todos os fins de semana, vê que a linguagem xyz está em alta, e decide aprender um pouco. Você instala o compilador da linguagem, baixa uma IDE super completa e parruda, estala seus dedos, cria seu "Hello World", e... nunca mais toca nela na vida...

Isso te lembra alguma coisa? Pois é, todos temos essa fase, mas tente se libertar dela o quanto antes. Não traz nada de bom ficar pulando de galho em galho no mundo da tecnologia, não tem nada de errado querer aprender uma linguagem diferente, mas pare de ficar aprendendo uma linguagem nova por semana.

Vou adicionar essas duzentas bibliotecas para fazer minha página estática

Você está querendo montar uma página estática para seu formulário, aí você cria um projeto com React, importa o Materialize, o JQuery e o SwiperJS, depois adiciona o Babel para conseguir rodar em navegadores mais antigos, adiciona um router diferenciado feito por um indiano, aí ainda adiciona um pouco de WebAssembly com Rust e mais um pouco de WebAssembly com C++, ainda adiciona o FontAwesome e os ícones da Google, e, quando percebe que o Materialize não te atende 100%, você ainda adiciona o SCSS, o Sass e duas bibliotecas de terceiros que precisam do SCSS e do Sass. Logo depois você percebe que tem um script legal em CoffeeScript que poderia fazer seu sistema ficar mais bonitinho e funcional. No final das contas, seu sistema funciona, mas é um Frankenstein complexo, pesado e que não parece fazer muito sentido.

Não tem problema nenhum adicionar bibliotecas diferentes, mas mantenha o sistema enxuto. Colocar mais bibliotecas no projeto aumenta a complexidade dele, assim como o peso e a dificuldade de realizar manutenção nele. Adicione apenas o essencial e abandone a "arquitetura Frankenstein".

Não tem problema nenhum colocar essa variável com o nome "numx" aqui

Não tem nada que dê mais raiva ao abrir um código que variáveis que não descrevem seu propósito e são usadas a toda hora, te obrigando a ler todo o contexto para entender o que ela faz. Isso é desperdício de tempo, gera desorganização e torna extremamente mais difícil de compreender o código do desenvolvedor. Adicione nomes que façam sentido, e que te poupem tempo

Testar tecnologia em produção é demais

Você é um programador iniciante em Ruby on Rails, mas um programador experiente em um outro framework completamente diferente, e decide iniciar um projeto freeelance com Rails do zero para aprender. Esse projeto estará fadado ao fracasso, e você terá de lidar com atrasos, bugs e diversas outras coisas que seriam facilmente solucionadas se você conhecesse o mínimo sobre o assunto.

Projetos de aprendizado e testes servem exatamente para isso: testar. Não teste algo completamente novo em produção ou em um projeto com prazo curto, reserve um tempo nos intervalos para lidar com um projeto de teste.

Prazos? Pfff

Sabe o lema da Debian: "o sistema vai estar pronto quando estiver pronto"? Pois é, deixe ele para o Debian. Não é uma coisa muito profissional você levar muito tempo a mais que o prazo para entregar uma tarefa, um projeto ou qualquer outra coisa. Se você ainda estiver em uma equipe maior, não entregar determinada tarefa no prazo vai significar que outras tarefas dependentes dessa também estarão em pausa, e você pode estar atrapalhando o desenvolvimento da equipe inteira.

Metodologias ágeis são besteira de programador hipster, o negócio é programar como der na telha

Já ouviu falar de XGH? É uma piada frequente com esse tipo de programador, que simplesmente faz tudo sem se preocupar com boas práticas, com padrões ou com qualquer outra coisa (e um dia o barco afunda, mas tudo bem). Programadores que programam dessa forma, ignorando padrões, metodologias e a forma que outros programadores da mesma equipe agem são a causa da anarquia completa nas equipes, com trechos de código que não fazem sentido algum e com grandes trechos completamente destoantes do resto do código. Por favor, não seja adepto do XGH. Eu agradecerei.

SVN? Git? Nah, eu versiono com arquivos .zip

Sempre tem o cara que entrega seus projetos em um arquivo zip e que versiona os códigos criando novos arquivos zip chamados projeto.1.0.0.zip, projeto.1.0.1.zip, projeto.1.0.2.zip e assim por diante. Isso não é apenas feio, é arcaico, desfuncional, lento e deixa uma má impressão. Dá ainda mais agonia quando você tem que dar manutenção pra um código desses. Isso é algo aceitável apenas para o início do seu aprendizado com programação, não siga com isso depois, vai pegar muito mal, além de ser extremamente difícil de manter um código decente com isso.

Escolha um sistema de versionamento, como Git, SVN ou outro de sua preferência, aprenda a usá-lo e use-o. Zip é para compactar arquivos, não para versionar código...

Quem tem que entender o sistema sou eu, o cliente que se vire

Nada pior para o usuário que um software que não se descreve sozinho, um software onde você precisa entrar em 3 menus diferentes para realizar uma ação simples, ou que as ações não estão onde você espera que elas estejam.

A regra que todos devem levar para si ao desenvolver qualquer coisa é NÃO ME FAÇA PENSAR!!! Se o cliente precisou pensar para fazer uma ação, é porque seu sistema é confuso. E não adianta você dizer "mas eu consigo fazer em segundos, é muito intuitivo". Não se esqueça que para os chineses o mandarim é extremamente intuitivo, mas para você é apenas um grupo de rabiscos que parece magia. Apenas faça da forma que o seu usuário pensa que deve funcionar.

Sabe como eu faço para saber se o sistema está confuso ou não? Eu chamo minha irmãzinha e peço para ela usar. Se ela precisar perguntar absolutamente qualquer coisa pra mim, está confuso demais. Não tem uma irmã? Então arrume um amigo, um vizinho, alguém leigo que seja capaz de servir de cobaia. Aposto que vai ser melhor que ter que pensar em como outra pessoa pensa...

Python ou Java? Nah, vou aprender a programar com BASIC no DOSBOX

Não é raro conhecer o programador diferentão que quer aprender a programar com uma tecnologia completamente nada a ver, mas você realmente quer ser o cara que aprendeu a programar com VBScript no Windows 2000 na equipe ou com outra linguagem pouco usual?

Programar coisas diferentonas pode ser divertido, mas tenha um foco principal, algo que você seja capaz de usar no dia a dia, ou você realmente acha que uma empresa vai te contratar para programar com o BASIC de 1964? Ou com o Batch do Windows?