ler documentação #

Quanto mais cedo você se expor à documentação melhor. Não sei se existe alguma maneira correta de começar este tipo de leitura, mas talvez ler a documentação oficial de funções que você já está familiarizado de alguma forma seja uma abordagem mais tranquila e não tão intimidadora assim. Digo isso porque eventualmente você vai depender de ler ou código ou documentação. Nesse sentido, é fundamental se expor ao tipo de linguagem da tecnologia que você pretende utilizar. Não se assuste com o jargão e claro que vão surgir conceitos que você não tem familiaridade, mas este é o primeiro passo para deixar de seguir os passos de outras pessoas (tutoriais) e começar a trilhar o próprio caminho.

pensar o código #

Acho que a partir de um certo nível de experiência (não tão alto assim), você já deve ter uma certa expectativa do resultado do código que você escreveu. No sentido de conseguir ler o código linha por linha e entender. Claro que você não vai conseguir entender tudo de cara, mas acho que tentar “adivinhar” o comportamento de um programa que você acabou de fazer antes de executá-lo é uma maneira boa de treinar isso de um modo natural.

abstração da caixa preta #

Você não precisa saber exatamente o que cada coisa vai fazer dentro de uma linguagem ou dentro do computador, muitas vezes só fazer funcionar basta. E conseguir dividir um problema em passos (qualquer coisa mesmo) que muitas vezes estão além do seu conhecimento, e continuar repetindo essa divisão nos passos pensados até chegar em algo “abordável” é fundamental para desenvolver a capacidade de desenvolver projetos. Existem outras habilidades que estão além da minha capacidade atual e que eu não vou comentar sobre. Por exemplo, como gerenciar o tempo, ou até estimar o tempo que algo irá levar para ser feito. Agora, para desenvolver qualquer projeto novo, você deve se sentir confortável em não saber algo. Porque qualquer programa que vale pena (no sentido dos resultados) não será uma tarefa trivial. Acho que uma maneira fácil (uma idéia básica mesmo, existem outras mais sofisticadas e os padrões da indústria) de pensar algum programa possível seria considerar as entradas e as saídas, isso é algo que é relativamente simples se você tem uma ideia qualquer. Um exemplo simples seria uma calculadora, um programa que você coloca números e operações e ele te dá o resultado daquilo. Outro exemplo mais complexo seria um navegador da web, você coloca um endereço de internet e ele te mostra uma página da web. Como você dividiria esses programas? E que programas você tem vontade de desenvolver? Acho que isso são coisas fundamentais que alguém deve pensar de tempos em tempos para conseguir se manter programando e consequentemente crescer como programador. Então a ideia da abstração da caixa preta seria dividir um programa qualquer em funções ou etapas menores que ou são conhecidas (o suficiente para serem chamadas de ‘passo’) ou parecem que estão ao seu alcance, no sentido de você ser capaz de entender alguma resolução daquilo na internet, e (talvez) ao invés de implementá-las, simplesmente reutilizar o código de outra pessoa.

• aprenda a usar código de outras pessoas Outra habilidade que é extremamente importante e que vai depender da sua capacidade de ler documentação é utilizar bibliotecas de código. Elas serão ferramentas essenciais na hora de produzir algo mais desafiador, não tem porque reinventar a roda se você está programando com a finalidade de montar algo que funcione ao invés de entender sobre ‘rodas’. Quero deixar isso claro, porque vejo que dá para tirar muitos frutos positivos de tentar implementar uma biblioteca qualquer que faça algo relativamente simples (ainda que pior do que alguma outra já existente), mas saber reutilizar código é algo que vai te dar a capacidade de fazer maiores e melhores, porque de um certo modo você permitiu que mais pessoas se envolvessem nele (ainda que indiretamente).

• não se sentir mal em não saber as coisas A maior parte do tempo você vai estar em contato com coisas que não sabe ou não domina, mas usa mesmo assim (ver abstração da caixa preta). Até porque não tem como ser um programador onipotente que entende tudo nos mínimos detalhes de todas as coisas. A maioria dos programas que você fizer vai depender do código de outras pessoas de maneira indireta, e tudo bem. :D

entender que fazer programas de computador é essencialmente resolver problemas #

por isso eu adicionei uma seção sobre resolução de problemas depois das outras dicas. Claro que serão problemas diferentes daqueles encontrados na matemática e na física, porque envolverão um passo a mais: a automatização desse tipo de resolução. Então, de um certo modo, usar um computador para resolver um problema de matemática é mais difícil do que resolver o próprio problema de matemática. Se você não é “bom” nesse tipo de coisa, não se preocupe, porque considerando a minha própria experiência. Esse tipo de habilidade se desenvolve com o tempo, de um certo modo não existem atalhos, mas também não existem empecilhos.

perguntar #

Uma outra habilidade muito importante é perguntar. E isso se relaciona um pouco com aquela coisa da abstração da caixa preta, assim que você dividiu o seu programa em partes que podem ser expressas na linguagem que você vai usar, você (na maioria das vezes) não vai saber fazer boa parte do que dividiu. Aqui entram duas coisas, ler documentação (que você não vai conseguir entender sempre) ou perguntar mesmo. Aí montar perguntas claras e que estejam relacionadas com o seu problema é algo fundamental. Porque, muitas vezes, se fizermos as perguntas certas, você até acaba descobrindo que pode estar tentando resolver o problema de uma forma errada e outras pessoas podem te ajudar a melhorar o seu código. Use o StackOverflow para treinar isso, tanto a ferramenta de pesquisa como para perguntar coisas inéditas. Eles sào meio rígidos nas regras, mas não se intimide se deletarem suas perguntas, é o que assegura a qualidade do site e impede que vire uma bagunça. ** PRA FAZER inserir o link da entrevista com o criador do stackoverflow pra quem souber inglês, acho que vale a pena dar uma escutada nesta entrevista:

comentar e explicar algo para você mesmo #

Olha, como alguém que não costumava comentar código, e se você também não comenta, um bom exercício para comprovar a importância de comentários para quem não acredita é tentar ler o código de outra pessoa, ou pegar algum código que você escreveu alguns meses atrás e tentar ler aquilo. E se você não sabe o que comentar, acho que um bom começo seria escrever o código em “português” antes mesmo de começar a programar. Até para você criar um “índice” que você pode usar posteriormente para se orientar quando for navegar pelo código. Acho que até dá para pegar o que você separou nos passos da abstração da caixa preta e já colocar todos eles nos comentários.

algumas dicas de como resolver problemas #

princípios da resolução de problemas #

entender o problema #

pensar num plano #

tentar reconhecer algo familiar #

tentar reconhecer padrões #

usar uma analogia #

introduzir alguma variável #

pegar por casos #

trabalhar de trás pra frente #

estabelecer objetivos secundários #

pensar no inverso #

indução matemática #

executar o plano #

revisar #

dicas para melhorar na resolução de problemas #

tips to be a better problem solver https://www.youtube.com/watch?v=QvuQH4_05LI 3blue1brown

usar as definições dos dados do problema #

use the defining features of the setup

dar nomes (expressivos) às variáveis e funções #

give things (meaningful) names

usar simetria #

leverage symmetry

tentar descrever um objeto de duas maneiras diferentes #

try describing one object two different ways

desenhar um diagrama ou esquema do problema #

draw a picture coordenadas usando números

monte uma versão mais simple do programa #

ask a simpler version of the problem

leia e pense muito sobre problemas #

sempre tenha algum problema que você não sabe na sua cabeça read a lot and think about problems a lot

procurando “pontos de entrada” em código alheio #

ler código de outras pessoas #

entenda testes #

matemática #

aqui eu poderia citar o paper do dikjstra sobre provas vs testes e como provar um programa que está certo.