Torne-se um bom Programador em 6 Etapas Muito Difíceis

Introdução

Em primeiro lugar, saibam que Peter Norvig, Director de Investigação da Google, compreendeu isto há muito tempo: leva 10 anos a aprender a ser um programador. Depois há um excesso de livros do tipo "Aprender X em algum pequeno número de dias", lá fora; há hordas de artigos de blog sobre "Como melhorar a sua programação em poucas maneiras fáceis"; e, em geral, um grande número de pessoas procuram conselhos sobre como se tornar um génio com o mínimo esforço.

Neste artigo, vamos mudar um pouco o passo. Em vez de “Cinco maneiras fáceis de tornar o seu código surpreendente em 21 dias”, vamos descrever como é na realidade. Vamos tentar fazê-lo de forma ligeira, por vezes a parecer brincadeira, mas na realidade é mesmo assim. Bem-vindo ao Como se tornar um bom programador em seis etapas muito dificies.

Passo 1

Entre no tema a longo prazo ou dedique-se à ornitologia

Claro que pode sempre mexer-se e fazer bons scripts de shell e talvez um pequeno jogo ou outro; se está satisfeito com um conjunto de competências limitadas, siga de imediato a rota do fácil-e-rápido. Não estamos a tentar diminuir a legitimidade dessa opção, de todo - algumas pessoas não têm tempo (ou mesmo o desejo) para se tornarem um programador mestre. Se não lhe agrada a ideia de praticar este ofício durante dez anos antes de se tornar bom nisso, então não se preocupe - mas não se iluda, você vai ser sempre limitado no que pode fazer e no que pode fazer bem. Se isso é uma situação razoável para si, óptimo! Não precisa terminar este artigo.

Para o resto de nós, porém, há algo sedutor sobre conseguir ser Realmente Bom em programação. Nós queremos ser especialistas, ninjas, gurus – qualquer que seja o substantivo superlativo de mestria que seja a sua fantasia. Para nós, 10 anos parece ser um investimento razoável. Talvez um pouco pesado, mas se vale a pena fazer, então vale a pena fazer certo... certo?

Assim, o primeiro passo para ser um bom programador é engolir a pílula. Aceitar que este não é apenas um processo de 10 anos, mas um processo para a vida. E como Norvig observa muito justamente, deve fazê-lo, porque quer. Ninguém se torna excepcionalmente bom a fazer algo que preferia não estar a fazer; os recordistas mundiais não entram nos livros da história, porque meio acidentalmente comeram a maior quantidade sempre de cachorros-quentes de uma assentada, mas naquele dia não chegaram a sentir fome.

Passo 2

Escrever muito código

Não tem que ser bom código. Não vai ser bom código, durante algum tempo. Apenas deite material cá para fora. Sempre que encontrar um pequeno incómodo na sua vida diária com o computador, pense sobre como pode escrever um programa para ajudar a resolver esse problema. Sempre que encontrar alguma coisa interessante que quiser experimentar, faça-o. Jogue com novos conceitos, ferramentas e linguagens, tanto quanto possível.

O processo de aprendizagem nunca vai parar. Então se abordar esta questão com a atitude de que você absorve tanto mais conhecimento e experiência quanto maior for a aprendizagem que pode fazer num dia, então vai longe. Entre na mentalidade de que um dia / semana / mês em que ainda não aprendeu algo interessante é um fracasso. Há tanto material lá fora, que certamente pode aprender alguma coisa útil todos os dias; isto torna-se mais difícil passados 15 anos, mais ou menos, mas ainda é perfeitamente possível. Nenhum mortal pode assimilar todo o conhecimento que existe no mundo sobre programação, por isso, se alguma vez sentir que já não encontra mais coisas para aprender, procure um novo projeto e escreva mais código.

Enquanto estiver a fazer isto, esteja atento. Procure por padrões - coisas que faz muitas vezes que possam ser úteis de automatizar, ou coisas que escreve muitas vezes no seu código e que possa ser capaz de separar em bibliotecas partilhadas ou outros locais centralizados. Procure linguagens que tornem determinadas tarefas fáceis. Depois procure outras linguagens que não são tão boas para aquelas mesmas tarefas e tente descobrir por que uma é mais produtiva que a outra.

Mas acima de tudo, escreva código. Todos os dias, mesmo que seja apenas uma expressão regular para pesquisar no seu histórico de email. Faça algo de programação tão frequentemente quanto puder. E lembre-se, se isto deixar de ser divertido, vá fazer outra coisa qualquer; não há nenhum objectivo nisto se não se estiver a divertir.

Passo 3

Ler ainda mais código

Depois de ter acumulado um pequeno conjunto de projectos, comece a ler o código de outras pessoas. No início, será difícil; elas vão fazer coisas que ainda não tinha visto antes, ou usar estilos a que não está habituado, ou mesmo linguagens que ainda não aprendeu. Se você encontrar algo interessante, leia o seu código, se possível. Não se preocupe em analisar profundamente um determinado projecto, pelo menos de início; pode ser um trabalho a tempo inteiro apenas para entender algumas bases de código existentes, como as de muitos grandes projetos. Escolha uma ou duas coisas que desejaria conseguir aprender a fazer, e descubra como elas foram feitas.

A leitura de novo código vai expô-lo a novas formas de pensar e isso ajuda a “esticar” o seu cérebro. Este esticar é vital para se manter o progresso e vai ajudar a garantir que à medida que avança, vai continuando a descobrir coisas novas para aprender.

Não se esqueça de falar com outros programadores também. Pergunte como e por que eles fizeram determinadas coisas. Pergunte se eles iriam fazer as coisas de forma diferente se voltassem atrás. Pergunte se eles têm alguma sugestão para o seu código. (mas seja educado; a maioria dos programadores alto perfil são extremamente ocupados e não têm necessariamente tempo ou inclinação para navegar através do trabalho de outras pessoas, de graça. O respeito leva-o por um longo caminho; esta é uma indústria muito compacta e a reputação significa muito.)

Passo 4

Aprenda muitas linguagens. Domine um par delas

Não irá conseguir ter um excedente prático de tempo, pelo menos não o suficiente para dominar várias linguagens simultaneamente, a não ser que seja extremamente sortudo. Portanto, aprenda tantas linguagens quanto possível a um nível superficial - o suficiente para saber o que as faz mover, o que as torna boas nos seus trabalhos específicos e quais as suas fraquezas. O esticar do cérebro é importante aqui; não se limite apenas a linguagens imperativas, como o C, ou orientada a objetos linguagens, como o Java; expanda-se para linguagens funcionais e linguagens declarativas também.

Aprenda um dialeto do Lisp. Isto não vai fazer nada pela sua programação do dia-a-dia, porque não vai usá-lo, mas vai fazer de si um melhor pensador e vai-lhe dar uma compreensão profunda da beleza dos sistemas recursivos. Agarre-se ao Lisp até que o momento "aha!" ocorra; até lá, vai parecer uma sopa de sintaxe estranho e convenções bizarras. Depois disso, ele permanecerá consigo durante a sua carreira, como um dos mais incrivelmente elegantes conceitos já concebidos pela humanidade.

Então, aprenda uma linguagem puramente funcional. Recomenda-se o Haskell, porque o obriga a ser puro de uma forma que outras linguagens funcionais (incluindo a maioria dos dialetos Lisp) não fazem. Vai ter que dobrar um pouco a sua mente, mas uma vez que o inevitável momento "aha!" ocorra (por volta da altura em que entenda o propósito dos monads) vai voltar a aumentar um nível no seu pensamento e na capacidade de projectar sistemas elegantes.

Finalmente, aprenda uma linguagem declarativa. O SQL conta, apesar de ser um pouco sem-saborão aprender apenas SQL. O Prolog é muitas vezes recomendado, mas não é necessariamente acessível. No âmbito da prática, XAML, XSLT e XQuery são boas ferramentas para conhecer e vão apresentá-lo aos conceitos por trás da programação

declarativa. (Em poucas palavras, dizemos ao computador o “que” queremos que ele faça e ele descobre como fazê-lo; isto está em contraste direto com a programação imperativa, onde dizemos ao computador como fazer as coisas e esperamos que ele faça o “que" de forma correcta e com a programação funcional, na qual descrevemos as transformações de tipos e dados.)

Como bónus, aprender ferramentas baseadas em XML depois de aprender um dialeto Lisp tornará dolorosamente óbvio o quão desesperadamente o XML está a tentar reinventar as expressões –s, e quão pobre é o trabalho que ele faz.

Passo 5

Crie uma linguagem

A linguagem não tem que ser complexa, rica, ou sofisticada, ou mesmo particularmente elegante. Nem sequer tem que ser original; É costume sugerir-se escrever um interpretador de Lisp (pontos de bónus se fizer isto num dialeto Lisp!) como uma boa maneira de aprender as bases. Em essência, quer ter uma sensação dos fundamentos do design de programação de computador: análise léxica (lexing), análise sintática (parsing), compilação, interpretação, máquinas virtuais e as inúmeras maneiras como as decisões básicas de projecto de uma linguagem afetam a forma como ela é útil para várias tarefas.

Isto irá permitir-lhe realizar três coisas:

• Vai ganhar uma compreensão mais profunda de como as suas ferramentas de eleição funcionam, o que lhe dará a capacidade de ser mais eficaz com elas.
• Vai começar a perceber as razões por trás das decisões de design das principais linguagens e ferramentas, que tanto o fascinar como irritar (se o fizer de forma correcta). Essa percepção vai ajuda-lo a escolher as suas ferramentas de forma mais eficaz, quando iniciar novos projetos.
• Vai vislumbrar as possibilidades inexploradas que ainda existem para a criação de ferramentas e linguagens, e, esperamos, vai abrir os seus horizontes para uma série de novas oportunidades de coisas interessantes para aprender e experimentar.

Passo 6

Aprenda algo que ainda ninguém aprendeu

Este é o passo mais difícil e o final. Até agora, tem estado principalmente a aprender coisas que já são conhecidas; coisas que pode descobrir através da leitura do código de outras pessoas, ou livros, ou trabalhos académicos; coisas que são boas de saber, mas que não são novas.

Agora está na altura de se libertar dos limites, e realmente ascender à mestria. Agora está na altura de abrir um caminho num território em que ninguém se tenha aventurado ainda.

Não se engane; isto é algo que não vai querer enfrentar até bem depois do seu "décimo ano" de experiência, principalmente porque até então será muito mais provável ter estado apenas a reinventar a roda do que realmente a fazer pesquisa nova e original. Mas assim que tenha um bom entendimento sobre o campo, não é exatamente difícil encontrar as deslumbrantes fronteiras do conhecimento inexplorado por que a ciência da computação aguarda.

O mais provável é que isto irá levar mais dez anos, se não para sempre. Não desista; lembre-se que isto ainda deve ser divertido. Se a qualquer momento você parar de apreciar esta actividade, vá fazer outra coisa. A vida é muito curta para perder tempo a tentar fazer algo que já não quer fazer.

Nem toda agente vai ter sucesso neste passo, mas quem fizer uma tentativa será recompensado pelo esforço. Não deixe que as probabilidades o deitem abaixo. Mesmo que nunca ganhe o Prémio Turing, o seu crescimento contínuo como programador e a sua jornada rumo à mestria final dependem de esticar constantemente o cérebro - e, para o efeito, problemas não resolvidos são a melhor maneira de esticar.

Parabéns! Agora é um bom programador!

Oh espere ... na verdade, você acabou de morrer de velhice. Desculpe. Melhor sorte na próxima vida!

Com toda a seriedade, porém, não espere terminar nunca. No momento em que parar de fazer progressos na sua jornada, começa a morrer e a tornar-se irrelevante. Alguns dos falhanços mais tristes que já se viram no mundo da programação, derivam de pessoas que percorreram uma certa parte do caminho e decidiram que tinham terminado a aprendizagem; hoje são completamente irrelevantes no mundo do software e, provavelmente, nunca irão além da sua situação atual - a menos, é claro, que decidam começar a aprender de novo.

 

Agora, vá em frente e crie código! Talvez um dia, quando você for um grande programador, nos possa dizer como o conseguiu. Nós adoraríamos aprender.

 

Tradução livre do artigo “Become a Good Programmer in Six Really Hard Steps”

Nota: Na tradução optei por usar o masculino, não com qualquer intenção de discriminação, mas apenas como facilidade de linguagem.