Senhoras e senhores da classe de 2009:
Usem linguagens dinâmicas.
Se eu pudesse lhes oferecer somente um conselho para suas carreiras futuras de programação, seria o de usar linguagens dinâmicas. Os benefícios a longo prazo das linguagens dinâmicas já foram provadores por milhares de programadores enquanto o resto dos meus conselhos não tem qualquer outra base se não minha própria conturbada experiência.
Eu lhes darei esses conselhos agora.
Aproveite o poder e expressividade de uma linguagem homoicônica. Ou esqueça que elas existem. Você nunca vai entender o poder e expressividade de uma linguagem homoicônica até passar quarenta horas acordado depurando um heisenbug. Mas acredite quando eu digo que, daqui a vinte anos, você vai olhar para trás, para todo código que você escreveu e desejar que ele tivesse sido escrito em uma linguagem homoicônica. Seu código atual é elegante, mas nem tanto.
Não se preocupe com a quantidade de linhas que você escreve. Ou preocupe-se, mas saiba que contar linhas de código é tão efetivo quando tentar contar parênteses em Lisp. O tipo de métrica que realmente vai lhe trazer problemas é a quantidade de declarações de tipo presente em seu código–justamente o código que vai falhar em uma madrugada movida a cafeína e fazer você amaldiçoar o compilador com todas as suas forças pelo pretenso sistema de tipagem segura.
Escreva uma linha de código a cada dia que assuste outros programadores.
Comente.
Seja cuidadoso com o código das outras pessoas. Não tolere pessoas que não são cuidadosas com seu código e introduzem problemas de manutenção nas elegantes estruturas que você construiu.
Não use marcações TODO, HACK ou FIXME em seu código.
Não perca tempo em discussões sobre linguagens de programação. Algumas vezes a sua está à frente no índice TIOBE, outras vezes ela está atrás. A corrida para entrega do código é longa e, no final das contas, suas linhas são as únicas quem contam.
Lembre-se dos forks e patches que seu repositório recebeu. Esqueça os comentários sobre a qualidade do código. Se conseguir fazer isso, me diga como.
Jogue fora a documentação obsoleta. Guarde o código antigo.
Faça forks do código alheio.
Não se sinta culpado por ainda não ter aprendido Assembly. Os melhores programadores que eu conheço não aprenderam até precisarem. Alguns dos mais excepcionais programadores que eu conheço preferem não aprender.
Beba café em quantidades moderadas. Seja bondoso com suas mãos. Você vai sentir falta delas quando a LER atacar.
Talvez você escreva um compilador, talvez não. Talvez você escreva um driver para o kernel do Linux, talvez não. Talvez você programe sistemas de inteligência artifical em ML, talvez não. O que quer que você faça, lembre-se que isso é tão relevante quando decidir se você vai usar o Emacs ou o Vi.
Aproveite bem os testes que você escreveu. Use-os da melhor maneira que puder. Não tenha medo dos que os outros dizem sobre TDD ou o que as pessoas pensam sobre BDD. Sanidade no desenvolvimento é a maior ferramenta que você vai ter em toda sua carreira.
Comemore cada build bem sucedido mesmo que você esteja sozinho no datacenter e ninguém mais possa compartilhar sua alegria.
Escreva um Makefile pelo menos uma vez, mesmo que depois nunca mais você vá usar algo similar.
Não leia revistas sobre tecnologias da Microsoft. Elas somente vão deprimir você pela pura estupidez da re-implementação.
Conheça os luminares de programação. Você vai sentir falta de saber o que Alan Turing e Donald Knuth fizeram algum dia. Seja gentil com seus colegas programadores. No futuro, eles são aqueles que provavelmente vão lhe apontar para o código que você precisar no momento certo.
Entenda que linguages aparecem, se tornam populares e desaparecem com a mesma facilidade mas há algumas que você deve prezar. Trabalhe muito para reconhecer as características boas de cada linguagens que você usa porque, quanto mais tempo de programação você tiver, mais vai precisar reconhecer quando e para quê certas técnicas e linguagens servem.
Programe em C durante um tempo, mas abandone a linguagem antes que ela lhe convença que controle manual de memória é uma coisa boa. Programe em Haskell algum tempo, mas abandone a linguagem antes que ela lhe convença que mensagens de erro absurdas são parte do fluxo normal de programação. E lembre-se de aprender uma nova linguagem de quando em quando.
Aceite certas verdades inalienáveis: linguagens do mercado como Java e C# são uma porcaria, tipagem dinâmica é melhor do que tipagem estática e sua carreira de programação vai terminar um dia. E quando ela terminar, você vai fantasiar que, quando você era um pogramador hot shot, linguagens de mercado eram boas–mas só pelo dinheiro–, que tipagem estática era mais segura e que sua carreira não terminaria nunca.
Respeite aqueles cujas carreiras já terminaram porque eles contribuíram bastante para o lugar em que você está.
Não espere que ninguém lhe ensine como programar melhor. Talvez você tenha um bom mentor. Talvez você tenha acesso a bons livros e documentação. Mas você nunca sabe quando quando essas coisas vão desaparecer.
Tenha uma biblioteca reusável mas não coloque coisa demais nela ou, quando você precisar, vai descobrir que a maioria do código lá está obsoleto ou é horrível demais para ser usado.
Seja cuidadoso com os algoritmos de terceiros que você usa, mas seja paciente com aqueles que os criaram. Algoritmos são como bichos de estimação. As pessoas que os criaram sempre pensam que eles são confiáveis, limpos e rápidos mas a verdade é sempre diferente e eles raramente valem o bytecode que geram.
Mas confie em mim quando eu falo de linguagens dinâmicas.
—–
Melhor desfrutado ao som de “Wear Sunscreen” do qual é uma óbvia paródia.
(Texto de autoria de Ronaldo Melo Ferraz e licenciado em CC-BY-SA)