20 lições importantes

Recentemente a Guta me disse que eu estava muito ranzinza nesse blog e que faltava humildade. Reclamei do Joel, reclamei do artigo sobre manutenção, disse que meu artigo era melhor que o do Stroustrup... ela tem razão e não quero que esse blog seja um lugar para se falar mal dos outros. Assim, começo o ano de 2010 falando muito bem de um artigo que li durante as férias: Top 20 programming lessons I've learned in 20 years. O autor é Jonathan Danylko. Eu concordo com tudo!

Segue abaixo então minha tradução livre do artigo. Aliás, livre até demais: eu mantive as 20 lições intactas, mas os comentários são meus.

1. Decida quanto tempo você quer gastar com um problema antes de começar. Ao invés de ficar pelejando por uma semana com um problema que deveria levar um dia pra resolver, como eu fiz na semana passada, decida antecipadamente quanto tempo você vai dedicar a ele. Pode ser uma semana, um dia, uma hora, 30 minutos, não importa. Se você não conseguir resolver o problema no tempo em que você se permitiu trabalhar nele, procure ajuda ou repense suas prioridades ao invés de tentar ser o super-programador.
2. Uma linguagem é uma linguagem é uma linguagem. Um sábio professor uma vez me disse que o problema que o seu programador mais júnior está tendo com a namorada tem mais impacto no sucesso do seu projeto do que a linguagem de programação que você escolher. Ele tinha razão. Escolha uma linguagem que te dê conforto, e pronto.
3. Não exagere nos design patterns. Pense duas vezes antes de usá-las - se houver uma solução mais simples, use-a. 
4. Faça backups do seu trabalho diariamente.
5. Você não é o melhor programador. Conforme-se com isso. Sempre tem alguém melhor que você.  Aprenda com eles ao invés de tentar ser melhor.
6. Aprenda a aprender mais. Se você não está gastando pelo menos 50% do seu tempo aprendendo, sua produtividade está piorando. Sim, parece um paradoxo, mas não é.
7. Mudanças são constantes. O que você sabe hoje não vai ser tão importante amanhã. Diversifique seus conhecimentos. 
8. Apoie os menos experientes. Ajudar os programadores da sua equipe a se tornarem melhores é o melhor investimento a longo prazo que você pode fazer.
9. Simplifique seu algoritmo. Quando terminar, volte atrás e veja o que você pode fazer para tornar seu código mais simples e fácil de ler. O futuro agradece.
10. Documente seu código. De novo, o futuro agradece. Aliás, quem provavelmente mais agradecerá será você mesmo.
11. Teste, teste, teste.
12. Celebre cada sucesso. Não espere uma data longínqua para se dar os parabéns. Programar é cansativo. Comemore cada passo a frente e cada bug removido, da maneira que preferir. Só não comemore comendo chocolate, como eu faço.
13. Faça revisões de código. No Google cada linha de código que é escrita é revisada por pelo menos um outro programador. Nenhuma outra atividade é tão importante para se garantir a qualidade dos sistemas. Mesmo que você não chegue a esse extremo, peça a seus colegas que revisem as partes importantes e ofereça-se para fazer o mesmo.
14. Estude seu código antigo. Leia código que você escreveu quando ainda não era tudo isso e maravilhe-se com o quanto você aprendeu desde então.
15. Tenha senso de humor. Ha ha.
16. Evite trabalhar com programadores possessivos ou prepotentes. O possessivo é aquele que não permite que ninguém altere ou critique seu código; ele pode arruinar seu projeto. O prepotente é aquele que tem sempre a última palavra; ele vai prejudicar sua auto-estima.
17. Nenhum projeto é simples. Nenhum. Não existe nada de qualidade em computação que possa ser feito "rapidinho, em dois dias".
18. Cuidado com o excesso de confiança. Enquanto não estiver funcionando e aprovado, nunca está 90% completo. Os 10% que faltam em geral levam o mesmo tempo que você gastou com os 90%.
19. Software nunca está pronto. Leia o post Persistir ou jogar tudo fora? 
20. Paciência é uma virtude. Saiba esperar a hora certa de implementar; antes tente entender seu problema. Quando as coisas derem errado, procure entender por que ao invés de sair tentando qualquer coisa.