Em uma madrugada dessas eu esbarrei com uma frase atribuída ao Alan Turing que me parece a mais pura verdade:

Programming is a skill best acquired by practice and example rather than from books.

Essa frase pode ser traduzida como: “Programar é uma habilidade melhor desenvolvida pela prática e pelo exemplo do que pelos livros”.

Passei um bom tempo pensando nesta frase e lembrei da minha época de moleque, onde eu virava noites futucando a internet, sempre acompanhado de um dicionário inglês-português pra tentar entender os tutoriais e transformar minhas ideias em código rodando.

Naquela época, tempo não faltava! Programava durante a noite e dormia durante as aulas da escola. Quem nunca? Mas ainda assim meu processo de aprendizagem não era nada produtivo.

Eu li em algum lugar que o jovem usa intensidade e tempo para compensar sua falta de experiência. Enquanto o velho usa a experiência para compensar seus limites de intensidade e tempo.

Imagina poder juntar essas duas vantagens?

Pra mim seria um sonho!

Por que a prática da programação é importante?

O ato de programar tem múltiplos níveis de desafios entrelaçados. A gente identifica um problema, imagina uma possível abordagem para chegar na solução, escreve o código em uma linguagem que tem suas próprias regras e restrições, transforma esse código em algo que a máquina possa executar, executa o código e só então verificamos se o resultado da execução de fato nos traz a resposta que buscamos.

A distância entre o que fazemos e porque fazemos é gigantesca! São muitas partes móveis que geram uma análise combinatória de coisas que podem dar errado.

A chance de você acertar um código de primeira é ridiculamente pequena. E o risco de você perder horas procurando o que não está funcionando é enorme.

Sabendo de tudo isso, eu sinceramente não faço ideia como existem programadores otimistas que pensam que “é só fazer um cadastrinho”.

É através da prática e da repetição que o programador constrói um repertório de caminhos possíveis para abordar um problema. São padrões e estratégias que vão se acumulando com a experiência.

Entretanto, quando olhamos a programação por essa perspectiva, há uma chance de cairmos na conclusão precipitada de que aprender a programar exige muito tempo ou muito talento. Quando vamos para a prática, o esforço e a disciplina na grande maioria das vezes superam talento e tempo!

É a qualidade da prática que faz total diferença no processo de aprendizagem. Observe que estou falando de qualidade, não quantidade.

Como superar a falta de tempo?

Se você sente que o pouco tempo que tem não é suficiente para desenvolver a sua habilidade de programar, você não está sozinho! Muitos dos membros do Welcome to the Django chegam com esse mesmo problema.

A maioria das pessoas tem a vida corrida. Muitos fazem faculdade, trabalham em período integral, estão montando os seus próprios negócios, tem famílias que dependem deles, e isso acaba consumindo todo o tempo que eles poderiam usar para praticar.

É muito comum as pessoas começarem a programar já idealizando um projeto todo complexo para “motivar” seu aprendizado. O problema é que na prática a complexidade te envolve numa verdadeira macarronada de código que te faz passar mais tempo investigando problemas do que de programando de fato e o risco de frustração é enorme.

Eu mesmo já sofri demais com esse tipo de comportamento quando estava começando. Eu iniciava vários projetos e não terminava nenhum. Com o tempo eu fui compreendendo algumas estratégias para ter menos desperdícios no meu processo de aprendizagem.

Neste post, eu vou contar para você 06 estratégias que você deveria começar a usar agora mesmo para driblar a falta de tempo e conseguir desenvolver as suas habilidades com a programação.

#1 Resista a tentação de queimar etapa!

Quando você começa a resolver um problema com programação, é incrivelmente comum os “saltos criativos”. Você começa com uma ideia e vai fazendo, no meio da caminho percebe o que parece um padrão ou atalho e já começa a implementá-lo. Isso se repete algumas vezes até que 30 minutos depois você se toca que não executou o código uma única vez sequer.

Uma dica massa pra saber se você tem esse impulso é quando você se depara com um problema, percebe que são vários elementos e em vez de resolver com 1 elemento você mete logo um loop no meio do código só pra complicar tudo.

Calma! Segura a ansiedade.

Resolve pra um e depois generaliza. Vai do particular para o geral e não o inverso. Esse impulso é uma espécie de otimização prematura, onde você tenta melhor algo que ainda nem funciona. Perda de tempo.

Por isso, é fundamental tratar todas as idéias como meras hipóteses e validá-las concretamente executando o código o quanto antes.

Foque em fazer funcionar. Se tiver que dar uma “roubadinha” usando um “ajuste técnico” também conhecido como “gambiarra”, faça. E assim que funcionar e você validar que aquela estratégia realmente dá o resultado esperado, então você parte para fazer direito.

Essa simples estratégia economiza uma enormidade de tempo, pois você está o tempo inteiro trabalhando em um código que, independente da implementação, faz o que precisa ser feito.

2# Não mate o paciente durante a cirurgia.

Eu sei que metáforas tem seus limites, mas pessoalmente, eu gosto de tratar o código como se fosse um organismo vivo. É o que eu chamo de Live Software, e com isso eu trato as mudanças que eu tenho que fazer para aprimorar ou evoluir o código como “incisões cirúrgicas”.

Então, nada de ter uma “ideia brilhante”, selecionar 10 linhas, deletar e sair “fazendo de novo”. Em vez disso, busque sempre a menor incisão no código para provocar a mudança que você quer realizar. Assim, você consegue manter o código o mais estável possível, sempre funcionando, o que economiza muito tempo de bateção de cabeça para consertar algo que já estava correto.

3# Teste o tempo inteiro

Eu sou fã de desenvolvimento guiado por testes! Além de permitir que a própria máquina valide o comportamento do meu programa automaticamente, o processo de começar a programar a partir dos testes é uma excelente ferramenta de design de código.

Quando programamos os testes antes do código, começamos por definir o comportamento esperado do código que ainda vamos criar.

É uma dinâmica onde usamos os testes para estabelecer e cumprir pequenas metas, uma de cada vez, aumentando gradualmente a capacidade do código sem deixar passar um efeito colateral indesejado em algo que já estava funcionando.

Além de aumentar sua confiança no código que você escreve, os testes reduzem o esforço cognitivo do programador, afinal você não precisa ficar revendo mil vezes na sua cabeça se não esqueceu de nada ou quais os possíveis problemas que sua mudança vai causar.

Basta executar os testes e você pega os erros imediatamente!

Já ouvi de muita gente que programar fazendo os testes primeiro é “mais lento” do que sair escrevendo o código.

Eu tenho a impressão que é só um problema perspectiva, afinal programar não é um tiro de 100 metros, mas uma maratona. O código vai mudar enquanto alguém estiver usando o seu sistema.

Pode até ser mais lento para escrever, mas como evita a quebradeira, você acaba chegando mais rápido no seu destino. É totalmente excelente!

4# Sozinho é mais difícil. Colabore!

Já perdi a conta de quantos artigos já li enaltecendo o “heroísmo” de aprender tudo sozinho sem perguntar nada pra ninguém, munido apenas de uma suposta genialidade. Grande balela!

Sim, empenho e esforço são fundamentais. Não há alternativa ao esforço! Mas 2 pessoas empenhadas em resolver um problema tem um campo muito maior de caminhos possíveis proporcionados pela interação.

Ah, Henrique, então você é contra ser autodidata?

Eu disse isso? Não! Um autodidata é alguém que aprendeu a aprender, alguém que consegue perceber que está empacando e reformula a estratégia pra quebrar o problema em tamanhos menores pra conseguir juntar o quebra-cabeças.

Mas eu não vejo conflito algum entre ser autodidata e aprender colaborativamente. Muito pelo contrário. Meus anos de Coding Dojo com a galera do Dojorio me mostraram quão poderoso é reunir pessoas em busca de um aprendizado comum.

Essa experiência impactou minha vida de tal forma, que a primeira coisa que eu faço quando quero aprender algo é encontrar alguém que sabe o que eu quero saber, que faz o que eu quero fazer. Isso me ajuda a me conectar com algo concreto me dando foco no que eu preciso estudar ou experimentar mais.

5# Jogue o Um Anel no fogo de Mordor

Certamente você já viu um programador Gollum, que olha para o código e diz: “My Precious!”

O apego ao código é um sintoma de que algo errado não está certo. Afinal o código que escrevemos não nos define.

O código escrito na correria virando noite é completamente diferente do código feito pela manhã após uma boa noite de sono.

É claro que dá um barato resolver um quebra-cabeças, criar uma solução massa, implementar uma estratégia que você não tinha feito antes. É parte fundamental de curtir o processo de criação.

O drama é quando caímos na cilada de tratar o código como um atestado da nossa capacidade, ou falta dela. Já sofri muito isso no início e eu tinha uma resistência enorme em compartilhar meu código com outras pessoas ou até mesmo publicar na internet. Sempre vinha aquele medo da crítica alheia. Perda de tempo!

Principalmente quando estamos aprendendo algo novo, quanto antes publicarmos um código, melhor. Pedir para um amigo dar uma olhada, comentar e sugerir alternativas te acelera na construção do seu repertório.

Use o seu código como uma ferramenta de comunicação que te ajuda a explorar novas perspectivas. Quanto mais desapegado do código você for, mais chances você tem de aprender com ele.

Eu sugiro inclusive que você dê um passo além e tenha um blog para compartilhar seus pensamentos e seus códigos. É um belíssimo exercício de expressão e desapego que vai te economizar tempo e acelerar o aprendizado.

6# Aprenda de forma “puxada” em vez de “empurrada”.

Uma outra cilada que eu já caí muito no passado era a fixação no ideal de ler um livro técnico de capa à capa. Por algum motivo bizarro eu focava em me preparar para fazer em vez de de fato fazer.

Com o tempo eu fui descobrindo o óbvio: A forma mais efetiva de aprender a programar, é programando.

Livros são ótimos e eu tenho vários. O que eu faço é usar o livro para alimentar o meu ciclo de feedback de aprendizado. Eu invento um micro-probleminha que aplique algo que um capítulo ensina pra ter algo concreto sobre o que me debruçar. Evito ao máximo ficar apenas no conceitual, porque no fim do dia eu preciso mesmo é fazer o código rodar.

Esse apego com as abordagens puristas é algo que eu vejo inclusive em muitas listas de discussões na internet. Chega um iniciante querendo resolver algo e vem um pela-saco com um balde de água fria:

mimimi pára de tentar programar mimimi e vai estudar lógica antes mimimi.

Pensa numa ideia estúpida? É essa! Não quer ajudar não atrapalha!

Programar não é elaborar puramente proposições lógicas.

Sim, você precisa desenvolver o seu raciocínio lógico o máximo possível. E você pode fazer isso com um processo empírico onde a tentativa e erro da prática vai te alimentando com feedbacks sobre o que funciona e não funciona.

O aprendizado vem do concreto para o abstrato e não o contrário. O pensamento abstrato é uma sofisticação que se constrói sobre um repertório de experiências.

Por isso, ao invés de ingerir conteúdo goela dentro, foque na prática do simples para gerar as perguntas que naturalmente te farão pesquisar e aprender mais.

Conclusão

É fundamental compreender a natureza da programação, respeitar o seu tempo e praticar.

Comece do mais simples possível e vá gradualmente aumentando a dificuldade. Você vai ver que não vai demorar, e você rapidamente vai acelerar o ritmo.

O ganho incremental de conhecimento que você consegue nessa dinâmica é como juros compostos trabalhando ao seu favor. Então o maior risco é empacar sem produzir nada por tentar dar um passo maior do que a perna.

Imagem disponível em Wikiart.