A polêmica continua, e essa aqui é uma dica que vale ouro. A galera da mentoria sempre fica “chateada” quando eu digo isso, mas é a pura verdade para mim. Hoje abordamos muitos assuntos, mas não abordamos métodos para estudar, eu vou contar o que faço.

Afinal, o que são posts, e tutoriais?

Posts e tutoriais têm a função de apresentar uma ideia e dar uma pincelada em um assunto, sob uma ótica propositalmente limitada. Tutoriais não ensinam, eles te mostram uma perspectiva, que em geral se traduzem em simplificações de uma coisa qualquer. Boa parte dos vídeos que não são treinamentos também entram nessa categoria e possuem mais ou menos esse propósito.

E os tutoriais?

Um tutorial vai te mostrar como fazer algo. Isso não é ensinar uma tecnologia, mas ensinar a operacionalizar uma ideia finita e pré-moldada. Então vamos citar o exemplo de JWT, tema que apresentamos em uma live de mais de 3 horas. Aquilo foi uma pincelada no assunto, mostrando diversas tecnologias e estimulando você a abrir sua cabeça para a ideia de que há conhecimentos e conceitos de Dev e Ops que precisam ser compreendidos na hora de subir uma infra completa, e mostrando como algumas coisas são resolvidas. Se você assistir até o final vai sair sabendo tudo sobre JWT? Não!!! Mas provavelmente você sairá do vídeo sabendo muito mais do que sabia antes, e já com uma ideia mais clara de como os pontos se conectam.

Afinal, como estudar?

Aqui vão algumas dicas:

1. Alguém citou um nome que você não faz ideia do que seja. Leia um post sobre o tema em no máximo 1 semana. Isso não quer dizer que você vai ESTUDAR, vai apenas se iterar. Pegue o celular e faça isso após a reunião. Dê de 3 a 10 minutos ao tema, simplesmente para sair da ignorância absoluta. E pode ser que daí surjam novos nomes/termos/tecnologias, agente para os dias subsequentes. Quanto mais no início desse processo, vai perceber que faltam fundamentos. Não tem problema, é normal. Quanto mais disruptivo pra você, mais fundamentos irão faltar.
2. O tema está se repetindo? Agora que você já faz ideia do que se trata, e precisa tomar uma decisão: Estudar ou não.
   1. Se optar por estudar:
      1. Vá para a maldita documentação. A tendência natural é que nenhum post seja melhor do que a documentação para expressar uma visão completa de um produto ou tecnologia. Há exceções? Sim. Mas trate exceção como exceção em vez de tratar como padrão.
      2. Algo está confuso ou você não está certo do que seja (Imagine que você viu um cara chamado Istio e não lembra muito bem o que seja service mesh. Estude redes mesh, depois service mesh antes de presumir que lembra o que seja.)

A documentação vai te mostrar como usar a tecnologia, quais são os recursos disponíveis. Vai te dar uma visão muito mais completa mas não necessariamente esse material está disposto de forma clara. Assim, mantenha como ponto de partida a documentação, mas se sinta a vontade para fuçar outros conteúdos sobre o tema, quando perceber que algo não está tão claro quanto gostaria. As vezes é uma questão simples de didática, as vezes são pre-requisitos que você não tem.

Dicas de ouro

Minha resolução sobre o tema

Na minha visão a forma mais eficiente de estudar é ir direto na documentação sem passar por tutoriais. Então eu vou direto na documentação tento pescar o máximo em uma timebox, e daí fico com aquilo na cabeça por algum tempo. Se algo não tiver claro o suficiente, eu busco algo complementar para conectar os pontos. É muito comum ir na documentação diversas vezes, passar pelos mesmos pontos, para formular de fato uma ideia e revalidar pensamentos.

As últimas tecnologias que estudei sob essa ótica foi o Istio e Envoy. Envoy já é um service mesh que namoro a algum tempo. Mas ao dar uma estudada no Istio, você nota claramente que ele é um wrapper que automatiza e orquestra diversas atividades do envoy que por sua vez é usado de diversas formas. Então estudar envoy é fundamental para entender Istio. Entender o conceito de POD do Kubernetes e por sua vez, entender sidecars e service mesh também faz todo sentido para entender ambos.

Cuidado com o Google

Muito cuidado com a indexação do google, ela tende a entregar o que é mais clicado para a sua pergunta levando em conta suas características como “manada”. Isso quer dizer que o google vai olhar para seu perfil e para os demais perfis parecidos com o teu para determinar o que é mais ou menos relevante. Não necessariamente é o melhor post, não necessariamente é o mais completo ou o mais esclarecedor. Navegue um pouco e dê preferência por nomes que você confia, caso não tenha, fique de olho, em algum momento você estabelecerá esse padrão e conseguirá.

Processo de aprendizado

O gráfico acima mostra o processo de aprendizagem em 4 etapas muito bem definidas.

1. Você nem faz ideia de que algo existe, nunca foi apresentado ao tema ou sequer sabe do que se trata. Você está inconscientemente incompetente.
2. Você deu uma lida, entendeu mais ou menos o que precisa para entender, já sabe qual roadmap para aprender aquilo. Você está conscientemente incompetente.
3. Você estudou, aprendeu mais um pouco e agora faz, com alguma insegurança ou recorrendo eventualmente à alguma ajuda. Você está Conscientemente competente.
4. É o estágio de andar de bicicleta, você nem sabe o que sabe, você simplesmente sabe. Você está competentemente inconsciente.

Bom, saber isso ajuda a entender como você está no processo, e se você tem uma lista do que precisa estudar para aprender algo, boas novas! Você superou a primeira etapa! Mas tenho algo muito mais importante a dizer. O processo entre a segunda e a terceira fase é o caminho crítico do aprendizado. É nesse ponto que as pessoas desistem. Mas tenho uma informação muito importante sobre isso: É nessa fase que começam a surgir as dúvidas e inseguranças. Se você está confuso, está em dúvida ainda, é bem provável que esteja mais perto da fase 3 do que da fase 1! Então temos um novo motivo para comemorar!

Saber isso ajuda a entender que falta pouco para a próxima fase do jogo. E esse jogo nunca acaba. Cada tecnologia, pattern, arquitetura, vai te dando alicerces para que o próximo aprendizado seja mais fluido. Aos poucos, você vai notando que tua lista de gaps é cada vez menor. E cada vez é mais fácil sair da zona de conforto e aprender algo.

Se você está lendo isso aqui, é muito provável que você tenha de fazer isso para o resto da tua vida.

Conclusão

A meta não é saber tudo de tudo, mas saber mais que o básico. Mais que um overview e principalmente: Não ter entendimento errado sobre algo.

Na dúvida:

UPDATE 08/07/2024 Matéria no IGN: A verdade está em outro lugar: programador autodidata dá dica de como aprender mais rápido: evite tutoriais e o Google

Uma das coisas me trouxeram absurda vantagem em toda a minha carreira, foi entender que existia algo mais importante que resolver problemas: Não cometê-los.

Nos primeiros dias de minha carreira profissional percebi alguns dos meus colegas embora tivessem anos de experiência profissional a mais que eu, não conheciam ou não dominavam muitos dos assuntos que eram familiares para mim por conta da forma como eu estudava.

Na época trabalhávamos com ASP clássico, ASP 3.

Naquela época, os objetos do ASP como Application, Server, Session, Recordset, eram recorrentes objetos de dúvida. Eles conheciam apenas as partes mais usadas e sequer sabiam da existência de outras.

Nenhum se importava em conhecer tudo.

Eu me importava.

Querer conhecer tudo
não significa conhecer tudo.

A grande diferença está na intenção de expandir a cobertura de conhecimento sempre que possível em vez de limitar ao que uso no dia-a-dia.

Fiz isso com ASP (VBS), HTML e Javascript.

Em menos de 4 meses eu já estava achando brechas na hierarquia que me permitiu criar meus primeiros componentes, criei uma grid que foi apelidada pela galera de GaGrid.

Aliás, aprendi essa stack para entrar na Petrobras, e só foi possível passar na prova, por conta desse método de estudo. A pior questão na prova demandava formatar data no javascript. Não me recordo se era no papel ou no interdev.

Essa abordagem me fez logo de cara, já começar ajudando meus colegas, e em 8 meses estava no time de arquitetura.

Era um time desejado, porém poucos estavam dispostos a estudar o suficiente para chamar a atenção.

Eu queria saber porque, como, com quais variáveis, eles consideravam para tomar decisões. Afinal, eu precisava saber qual era a regra do jogo para não ter minhas aplicações rejeitadas.

Saber como eles pensavam e quais eram as regras do jogo, me permitiria entender o que é certo e errado, bem antes de escrever a primeira linha de código.

Eu era muito jovem, aquele era meu primeiro emprego, e estava entrando na fase adulta, e meu processo de descoberta havia sido esse até então.

Não precisei passar por dificuldades para chegar a esse método de estudo. Eu simplesmente fazia assim porque quando comecei a aprender a programar, eu não tinha um problema específico a ser resolvido, eu simplesmente tinha a demanda de aprender um determinado assunto.

Minha busca era pelo conhecimento,
porque eu julgava que todos os profissionais fizessem isso
julguei que todos os profissionais soubessem determinado assunto com profundidade.

Era um misto de FOMO com caverna de Platão.

Assim que entrei na Petrobras percebi que a maioria dos meus colegas, juniores, plenos e até seniores buscavam resoluções de problemas ao invés do conhecimento.

O resultado prático é que eles batiam mais cabeça do que o novato, em seus primeiros meses de trabalho, e isso me permitiu ajudar colegas mais novos e até alguns mais velhos.

Recentemente o IGN publicou uma matéria, 5 anos depois desse post, falando de uma publicação no Reddit.

https://br.ign.com/tech/126390/news/a-verdade-esta-em-outro-lugar-programador-autodidata-da-dica-de-como-aprender-mais-rapido-evite-tuto

Vale a leitura.