Autonomia & Tecnologia

06 estratégias para superar a falta de tempo e desenvolver suas habilidades na programação

Descubra como é ser um desenvolvedor eficaz mesmo tendo pouco tempo para programar.

13

 

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 melhorar 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.

Curtiu e quer dar o próximo passo?

Este post é um conteúdo preparatório para o webinário: O Caminho da Autonomia na Programação.

O evento foi gravado e você pode assistir agora mesmo através do formulário abaixo!

Este artigo deu dicas para você resolver o problema da falta de tempo para programar. Neste bate papo ao vivo, nós fomos além para entender como usar esta habilidade de programar para resolver problema reais das pessoas, trabalhar com o que a gente gosta e fazer dinheiro atacando três pilares principais:

#1 – Sua relação com o seu código

  • Como realizar o trabalho de programação da forma correta?
  • Como você abordar o problema que você está resolvendo para reduzir o risco do projeto?
  • Como tomar as decisões na programação alinhadas ao valor que você precisa gerar?
  • Como aumentar a capacidade do seu software sem aumentar a quantidade de código?
  • Como melhorar o produto reduzindo o código?

#2 – Sua relação com o seu cliente ou empregador

  • Como você vai entender o que é valor e o que não é na empresa que você trabalha?
  • Como você faz para entender o que o seu cliente realmente precisa?
  • Como você faz para entender a relação entre os setores da empresa que você trabalha para você evitar aquela briga com os outros setores?
  • Como você faz para não ser visto como custo, e sim como investimento?
  • Como você faz para organizar o seu trabalho para não ficar preso em horas-extra?
  • Como não perder tempo fazendo sistemas que ninguém vai usar, mas sim sistemas que solucionam problemas?

#3 – Sua relação com o futuro da sua carreira

  • Como analisar financeiramente a sua carreira com a empresa que você está e os clientes que você atende?
  • Como você descobre o impacto financeiro do código que você escreve?
  • Como você se organiza, em termos profissionais, para não se tornar refém do seu empregador?
  • Como se preparar para empreender sem quebrar no primeiro ano?

Assista agora ao bate papo que ficará disponível por tempo limitado!

[]’s, HB!


Imagem disponível em Wikiart.

você pode gostar também
  • Leandro Laia

    “É 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.”

    Passei por isso recentemente. Realmente a sensação é horrível.

    • Tenho um outro artigo aqui onde falo da importância da técnica do Baby Steps. Acho que vc vai gostar.

  • jeverson

    excelente conteudo meu amigo, to começando a aprender programar agora, e eu adorei as dicas um grande abraço

    • Que massa, @disqus_OTvXwkH3oB:disqus! Fico feliz que vc curtiu! Qual dica fez mais sentido pra você?

  • kOLACO

    Excelente, boa HB 😀

  • Sensacional!
    Por muito tempo ficava preocupado em só estudar, ler um monte de livros e acabava que não praticava tanto e ficava ansioso pra aprender muita coisa ao mesmo tempo. Resultado: não me sentia confiante pra programar e tirar os projetos do papel.
    Mudei o mindset há um tempo e sinto uma evolução constante. É impressionante que um gatilho certo no nosso jeito de pensar e agir pode mudar totalmente o resultado, o todo. O Welcome to the Django me ajudou e ajuda demais nisso! É só o começo.

    • Grande, Eder! Vc é o cara! Seu progresso inspira todos nós aqui no WTTD. Mete ficha que tá massa! o/

  • Mais um artigo interessante. Parabéns HB!

    • Massa d+ que vc curtiu, André! Tô contando os dias pra gente botar o papo em dia em BH!

  • First! hehe

    Brincadeiras a parte, curti muito o texto, são ótimas estratégias que inclusive desconstroem o que estamos acostumados a ouvir por aí.

    Em especial eu curti muito o item 6#, pois a maioria das vezes nos pegamos mais lendo sobre algo que queremos aprender do que simplesmente rodando um teste de conceito.

    Pensando aqui, acredito que a abordagem de aprender de forma “puxada” parece ser mais natural. Pois é como uma criança aprende a falar, aprender a andar e etc. Elas não leem um livro entitulado “Como andar de forma certa” ou “Como aprender a falar”. 😉

    • É exatamente isso: crianças aprendem de forma puxada. O que fazem na escola é instrução. É totalmente diferente.

      O problema, é que promover a aprendizagem puxada da muito mais trabalho pq não basta expor conceitualmente as coisas! É preciso construir uma experiência de aprendizagem fazendo o design dos ciclos de feedback.

      É por isso que o wttd é como é. 😉

      • Verdade, como a aprendizagem puxada vai de encontro aos métodos “tradicionais” de aprendizado, a galera meio que se perde no “como fazer” e muitas vezes nem se ligam que existe essa forma.

        Acho que no WTTD isso é feito de forma muito esclarecedora e traz uma mudança de mindset essencial para todas as pessoas, ao meu ver. 😀