Certo dia estava debatendo com um colega sobre a “melhor” estratégia para estudar para se aprimorar como desenvolvedor. Aspas enormes em “melhor”, porque existem diversas maneiras de se estudar e isso não significa que um caminho é objetivamente melhor que outro.
Estude a medida da necessidade
Esse colega trouxe a seguinte afirmação:
> Eu acredito que o melhor caminho seja focar naquilo que surge do dia-a-dia. Então, por exemplo, não vou parar para estudar sobre Caching a menos que surja a necessidade.
No geral, a experiência que adquirimos no mercado de trabalho costuma ter maior impacto na nossa formação profissional. É no primeiro emprego que aprendemos como funciona uma aplicação em produção, a mexer com bancos de dados de projetos reais, e principalmente a derrubar prod numa sexta-feira à tarde.
Quando estudamos por conta, nos vemos constantemente focados exclusivamente nas partes que gostamos, procrastinando os afazeres mais chatos, ou caindo no velho anti-padrão do Tutorial Hell — a inabilidade de progredir sem o auxílio de um tutorial.
Observando por esse prisma, então por que criar estudos abstratos que terão pouco ou nenhum impacto no aprendizado real e, ao invés disso, utilizamos a carga de trabalho para definir o que precisamos estudar?
Na minha opinião, é uma faca de dois gumes.
Princípio de Pareto (Regra do 80/20)
> 20% dos esforços geram 80% dos resultados.
Para construir um serviço temporário em Node.js na AWS, certamente não é um requisito ser especialista em Node.js, ou em JavaScript, nem em AWS, e quem dirá computação em nuvem de forma geral.
Presumindo que alguém já tenha experiência prévia com JavaScript e tenha um conhecimento mínimo que seja sobre Linux, sem dúvidas seria capaz de buscar passo-a-passos ou outros artigos que auxiliem nessa tarefa e, ao final de tudo, atingiria seu objetivo em poucas horas.
80% dos problemas (ou até mais) em tarefas que executamos diariamente já foram resolvidos. E existe um post no StackOverflow com a resolução que busca. Em geral, nós não estamos criando coisas novas constantemente. A maioria dos programadores ocupa seu dia com tarefas de manutenção e evolução de aplicações existentes, e toda a estrutura do software e esteira de deploy já está estabelecida, mesmo que “deploy” signifique subir arquivos por FTP — longe de ser a solução mais elegante.
Buscar conhecimento à medida que problemas aparecem é bastante eficaz para esse tipo de problema. Mas quando a complexidade aumenta, pode não ser tão efetiva.
Entenda fundamentos e construa bases sólidas
Então 80% dos problemas são resolvidos por 20% do conhecimento sobre o domínio do problema. Logo, fica claro que é possível construir uma carreira adotando o processo de estudar conforme a necessidade.
No entanto, onde estão esses 20% de problemas que não são tão facilmente resolvidos? Ou melhor, onde estão os demais 80% de conhecimento que não foi adquirido com algumas pesquisas simples em busca da solução?
Amplitude
No livro Fundamentos da Arquitetura de Software, o conhecimento técnico é dividido em uma pirâmide separada em três tipos de conhecimentos:
- O que você sabe que sabe;
- O que você sabe que não sabe;
- O que você não sabe que não sabe.
A ideia de ampliar o conhecimento vem de buscar trazer os conhecimentos essenciais das camadas mais baixas para cima. Ou seja, aquilo que eu não sei que não sei, eu vou buscar conhecer para se tornar algo que sei que não sei.
A camada do meio (sabe que não sabe) é importante, não por nos tornar capacitados em determinado assunto, mas sim conhecer o horizonte e ter ideia de tudo aquilo que pode se tornar uma ferramenta útil.
Voltando ao exemplo da hospedagem de uma aplicação Node.js: eu posso não ter proficiência em arquitetura de software. Porém, ao ler sobre o assunto e conhecer os diferentes estilos de arquitetura (Monolito em camadas, Event-driven, Microsserviços, etc.), eu passo a conhecer todas as estratégias que posso adotar em uma aplicação e buscar mais sobre a medida que preciso a fim de entender se serve a necessidade da minha solução.
Note que, neste momento, ainda não se sabe na prática como é implementado um estilo de arquitetura mais complexo. Mas, ao ler sobre o assunto, se torna uma peça chave que podemos recorrer e buscar mais profundamente sobre quando se faz útil.
Profundidade
Aprofundar em conhecimentos específicos exige muito mais prática do que teoria. É também a abordagem central de um especialista: se tornar o mais hábil em determinado tópico, e isso exige conhecimento teórico, sim, mas também muita experiência prática.
Programar em Java é fácil. Se você já é familiar com lógica de programação, condições, laços de repetição, aprender Java se traduz para aprender sua sintaxe, entender o básico de OOP - se já não o tiver - e, claro, botar a mão na massa.
No entanto, se tornar um especialista Java não será uma tarefa fácil. Programar em Java é apenas a superfície, mas para se especializar no tópico é preciso ter vivência com a linguagem e aprender a fundo sua arquitetura, o que também exige muita experimentação. E o caminho para se especializar em algo não costuma vir em um simples Roadmap. Geralmente, a tal experiência e as dores em projetos vão revelar tudo aquilo que você ainda não sabe e vai precisar buscar iterativamente para preencher tais lacunas.
Nesse sentido, é coerente buscar o conhecimento à medida que ele surge, desde que tenhamos mente aberta a enxergar o que ainda não entendemos e buscar sobre. Problemas surgem e, muitas vezes, somente conhecimento teórico não é suficiente, e assim passamos a entender os detalhes do tópico que buscamos.
O caminho de se aprofundar costuma ser bastante nebuloso, pois ele não costuma ser óbvio.
Equilibrando o aprendizado
Se você está só começando na programação, essa tarefa não é tão simples. Lógica de programação pode não ser um tópico familiar, classes e objetos não fazem sentido, e criar um laço de repetição dá nó na cabeça.
Note que, no fim do dia, dependemos das bases que construímos através do conhecimento fundamental que adquirimos com estudo e vivência. Para quem está apenas começando, é muito difícil aprender a primeira linguagem, pois não tem a experiência e o conhecimento fundamental que um programador de longa data terá.
Afinal, essa mesma linguagem que pode ser difícil para um iniciante, é considerada simples por alguém com mais repertório. É muito mais fácil aprender a 5ª linguagem de programação do que a 1ª.
