Kit de sobrevivência do Bootcamp da Le Wagon

Então você comprou uma passagem para embarcar na pequena van vermelha e branca com destino à sua nova vida! Eu acabei de terminar a minha jornada de nove semanas e gostaria de compartilhar algumas coisas com viajantes que virão em seguida. Antes de mais nada, um disclaimer: caso você não entenda alguns dos termos utilizados neste texto, relaxe. Em breve eles farão sentido (mas sinta-se livre para usar o Google e ter alguns spoilers).

Pense que estou apenas descrevendo alguns pontos de uma estrada. Você pode até não os visualizar agora, mas irá reconhecê-los assim que os vir no caminho. E caso você revisite esse texto outras vezes, será uma forma de perceber sua evolução também. São pontos que provavelmente não servirão para todo mundo, mas que facilitaram bastante minha vida.

Você irá ouvir bastante que o bootcamp “é uma maratona, não um sprint”. Eu ouvi, mas só fui entender isso de verdade quase na metade do curso, algo que fez toda a diferença. Funciona assim: todos os dias temos challenges (exercícios práticos) obrigatórias e opcionais. No começo, eu tentava ir o mais rápido que podia, pois queria me testar. Ao terminar as obrigatórias, eu me enfiava em tentar resolver as extras, que quase sempre abordam conceitos que só serão vistos no futuro. Cheguei a perder longas horas tentando resolver algo que, com a ferramenta certa que eu veria no dia seguinte, levaria alguns minutos. Ia dormir cansado, às vezes até com dores de cabeça.

Tudo começou a ficar mais tranquilo quando entendi o ideal não era me desgastar correndo para uma linha de chegada, mas que deveria aprender com calma os conceitos do dia, trocar com colegas, e que eu sempre poderia retornar às challenges não cumpridas em algum outro momento. Confesso que mesmo assim continuei dando uma olhada nas opcionais, mas só investia naquelas que aparentemente eu não levaria tanto tempo para resolver.

A minha versão do bootcamp ser uma “maratona” é que o melhor é seguir num ritmo constante, sem pressa, com passos firmes, economizando energia para ir mais longe a longo prazo. Tentar adiantar as coisas ou viver para bater metas (mesmo que subjetivas) atrapalha a experiência.

Nas primeiras semanas a sensação era a de que eu estava tendo “câimbras cerebrais”. Além de aprender uma lógica nova, eu lutava com linguagem em si (pobre Ruby...). Muitas vezes me vi perdido, sem saber a razão do resultado inesperado, até que criei alguns hábitos.

1.      Comecei a sempre me questionar sobre o que ou qual tipo de dado estava sendo “retornado”. Muitas vezes eu esperava uma string, mas recebia uma array, ou recebia um integer quando esperava um float. Muitas vezes isso não fica tão explícito, principalmente quando encadeamos uma coisa após a outra. No início (e talvez para o resto da vida), logar constantemente partes do programa é um ótimo hábito que quanto mais cedo você adquirir, melhor.

2.      Comecei também a ver mais detalhadamente as mensagens de erro (quando existiam). Quem usa algum tipo de computador com frequência já se deparou com uma diversidade delas, com cores diferentes, longas linhas de código, números, pop-ups etc. Até então, para mim elas eram apenas um sinal de que o que eu estava tentando fazer não deu certo. Um admirável mundo novo surgiu quando parei para dar atenção aos erros que o computador me mostrava. Muitas vezes é um dialeto bem rudimentar, mas que pode dizer, minimamente, o que deu errado (o que seria realizado), quando deu errado (até onde as linhas de código foram executadas) e onde deu errado (o nome do arquivo, o número da linha, etc.). É comum o problema ser apenas uma pontuação, colchete ou chave que esteja faltando ou em excesso, mas para coisas mais complexas, uma busca no Google usando a própria mensagem que o computador retornou é uma mão na roda. O fato é que, ao aprender a programar, as mensagens de erro são nossas amigas, pois tornam muito mais fácil encontrar o bug. Quando elas não existem e o programa não funciona como gostaríamos, aí sim temos um belo problema.

3.      Adotei um pato de borracha. Há um método de depuração de código chamado “rubber duck debugging”. Ele consiste em descrever para alguém (real ou não), de forma simples, cada linha escrita e o que se espera com ela. Pode parecer bobo, mas realmente funciona e consegui avançar bastante com ela. Algumas vezes ao pedir ajuda, só de explicar o que eu estava tentando fazer me mostrou onde estava o problema que eu lutava há algum tempo para encontrar.

4.      Reconheci que a produtividade no fim do dia é baixa mesmo. Perdi as contas de quantas vezes eu fiquei até tarde tentando resolver um exercício simplesmente pela sensação de “estar quase” ou por ser “uma questão de honra”. Até que percebi que essas últimas horas do dia já não contavam com minha melhor performance. Não foi raro o problema que me tomou horas numa noite (resultando em fracasso) ter sido resolvido no dia seguinte em poucos minutos. Isso me fez entender que ao cair a noite é melhor descansar do que dar aquele último check na lista de tarefas do dia.

5.      No início também eu tentava correr atrás do tempo perdido nos fins de semana, pois era uma forma de cumprir a tabelinha das challenges dos dias anteriores. Fiz isso até perceber que eu já começava a semana seguinte cansado. Passei a não tentar mais escrever códigos aos sábados e domingos. Ao invés disso, me dediquei a leituras como forma de me manter em contato com o que aprendia no bootcamp. Três dos livros que abriram minha mente durante o bootcamp foram Eloquent Ruby (Russ Olsen), The Pragmatic Programmer (David Thomas e Andrew Hunt) e The Well-Grounded Rubyist (David A. Black e Joseph Leo III).

6.      Perceber do que eu não era capaz há uma semana sempre me dava uma injeção de ânimo. Fazer o curso no Le Wagon nos coloca em dias bastante intensos e muitas vezes o que mais dominava meu horizonte era que ainda havia um problema para resolver, faltavam competências, mas quando eu olhava para alguns dias no passado a diferença em minhas habilidades era imensa. A evolução no curso é muito rápida e pode passar despercebida. Por isso, de tempos em tempos, lembre-se de como você começou o bootcamp. O que você conseguia fazer antes e o que você consegue fazer agora? Você irá se surpreender mesmo que de uma semana para outra.

Para escrever código de maneira produtiva você precisa de um editor voltado para isso. Há muitas opções gratuitas e pagas, e apesar do Sublime aparentemente ser o queridinho da maioria, em vários momentos eu percebi a vantagem de estar usando o VS Code. A interface, variedade de extensões, recursos, atalhos, formatação automática (principalmente de .erb!), commits e pushes com um clique, snippets, highlights, são pequenos detalhes, mas que no conjunto da obra facilitaram minha vida, principalmente mais para o fim do batch.

E por que não? Segue uma array com algumas de minhas extensões favoritas [“Auto Close Tag”, “Auto Rename Tag”, “Bracket Pair Colorizer”, “Git Blame”, “GitHub”, “GitHub Pull Requests and Issues”, “Highlight Matching Tag”, “indent-rainbow”, “Prettier”, “Quokka” ]. Além dessas, recomendo instalar para cada linguagem seus respectivos intelliSense code snippets (que sugerem e autocompletam pedaços de código) e formatters (que ajustam seu código de acordo com as convenções de formatação).

Quanto mais mergulhamos no mundo do desenvolvimento de software, mais vemos que o número de linguagens, frameworks, patterns e tecnologias é praticamente infinito. Pelo menos para mim, a sensação era a de que eu iria me afogar. Me questionava de quantas vidas eu precisaria para aprender tudo aquilo. A tranquilidade só veio quando compreendi que seria impossível ter “fluência” em tudo, e que isso nem seria necessário na verdade. Mesmo que você se aprofunde num pequeno conjunto de tecnologias, em algum momento você precisará de ajuda, pois não saberá tudo o que precisa sobre elas. Além de fazer bastante sentido, vejo pessoas muito experientes no ramo dizendo isso. Mas se não precisamos memorizar tudo, o que precisamos aprender então? Os fundamentos!

Alguns conceitos estão presentes em todas as linguagens (e muitas vezes nas tecnologias relacionadas a elas). Quando compreendemos a lógica e a relação entre eles, fica fácil traduzir esses conhecimentos para qualquer outro contexto. No bootcamp, todos eles são apresentados: data types, objects, operators, variables, conditions, loops, functions, iteration, concatenation etc. Nosso trabalho como alunos é certificarmo-nos de que não deixaremos passar nenhum sem a nossa devida atenção, pois, além deles serem necessários para tudo que vamos construir, é por meio deles que vamos pedir ajuda.

Eu só estou começando a minha vida de dev, mas algo que fica cada dia mais claro para mim é que com o tempo eu poderei até saber de cor aquilo que utilizarei com frequência, mas eternamente precisarei recorrer a outras fontes de conhecimento, seja o Google, uma documentação oficial, um livro, um tutorial ou outra pessoa. Não foi sempre assim. Ao iniciar o Le Wagon eu tinha a postura de sempre tentar resolver as coisas por mim mesmo. Afinal, sendo programador eu precisaria aprender a me virar sozinho, resolver meus bugs por conta própria.

Durante o bootcamp nós temos a possibilidade de abrir tickets, que são pedidos de ajuda oficiais enviados à equipe de professores quando empacamos em alguma coisa ou queremos tirar dúvidas pontuais. Mais para o fim do curso, eu aprendi que para mim era interessante abrir um ticket entre 30 e 40 minutos sem ter nenhuma evolução num problema. Para você pode ser mais ou menos que isso, não há um tempo exato. O importante é saber que há coisas que simplesmente não valem a pena gastar tempo e energia quando se tem outra opção, mas o que gostaria de trazer aqui são os processos que me ajudaram antes de chegar ao ticket.

Além de logar constantemente o que era retornado, do pato de borracha, de não tentar resolver bugs com a cabeça cansada e de olhar com mais cuidado para as mensagens de erro (inclusive do rake), duas outras coisas foram muito importantes: saber usar o Google e me familiarizar com documentações.

Realizar buscas de maneira eficaz é das ferramentas mais poderosas de quem programa, e ela é completamente dependente dos termos corretos (ou seja, fundamentos). Para encontrar o que procuramos, primeiro precisamos saber o que estamos procurando (duh!). Digamos que você queira repetir uma mesma operação para todos os elementos de um conjunto em seu programa escrito em Ruby. Ao invés de colocar isso na busca, seria mais interessante algo tipo “Ruby how to iterate array”. Dessa forma, você está tornando explícita a linguagem na qual está trabalhando, a ação que você quer executar e o que sofrerá a ação. Geralmente a primeira página de resultados contém uma resposta que você precisa (Stack Overflow ❤).

Existirão casos em que você não vai encontrar o que precisa de forma clara, sendo necessário explorar mais profundamente, e as documentações são ótimas para isso. Linguagens, frameworks e algumas outras tecnologias geralmente têm longos documentos descrevendo seu funcionamento. Elas não são das literaturas mais amigáveis, mas, assim como os dicionários, são para referência, não lazer. Quanto mais você tiver contato com esse tipo de texto, melhor ficará sua experiência e mais você aprenderá a respeito das ferramentas. Ah, escrever documentações também faz parte do trabalho de devs.

Algo que faço há muito tempo e que me ajudou também no bootcamp foi a criação notas, prints ou esquemas, fossem eles de aulas, livecodes ou quaisquer outras coisas que eu considerasse relevantes. Além de reforçar a assimilação de informações novas por nos colocar numa atitude ativa, facilita na hora de buscar algum material. Particularmente recomendo o Notion e o OneNote, mas qualquer outro funcionaria. Se curtir a ideia, você pode até criar seu próprio app de notas ao fim do seu batch.

Antes de cada aula também eu dava uma lida na aba Source referente a ela, mesmo que eu não compreendesse nem 10% do conteúdo. Isso ajuda a diminuir o choque de um dado novo, tornando as novas informações mais familiares e fáceis de compreender.

A troca com colegas é das coisas mais importantes num curso. No caso do bootcamp, ler códigos de outras pessoas, acompanhar os caminhos que fizeram, fazer perguntas, são atitudes que abrem nossos horizontes. Por isso, ao ajudar alguém você também estará aprendendo. Algo que fica cada vez mais claro para mim é o fato de que, por mais que faça uso de elementos da lógica formal, exatos e objetivos, a programação está muito mais próxima das artes. Não há apenas uma forma de resolver um problema, e quanto maior sua complexidade, maior o número de ideias válidas para uma solução.

Assim como existe uma “curva de aprendizagem”, existe também uma “curva de esquecimento”. Flashcards são uma ótima ferramenta para lidar com a última, já que dedicar um tempo para relembrar informações durante o processo aprendizagem potencializa a memória de longo prazo (trust me, I’m a psychologist). No Kitt temos os flashcards específicos para cada dia (com o tradicional lembrete do Slackbot às oito da noite). Uma ferramenta que adotei há algum tempo e recomendo bastante é o Anki, um aplicativo open-source multiplataforma no qual você pode criar seus próprios cartões, configurar sessões de estudo ou o tempo em que cada cartão será mostrado novamente. Enquanto fazia os flashcards do Kitt eu criava os meus próprios com o Anki. É trabalhoso, mas compensa, pois você pode reforçar sua memória facilmente enquanto se desloca para o trabalho, espera por um atendimento ou qualquer outro momento em que você precise passar o tempo.

Se você chegou até aqui, desculpe-me pelo longo texto. A versão curta seria: economize suas energias, pois o caminho é longo; não abra mão de compreender os fundamentos, mas liberte-se de achar que precisa saber todo o resto; tente desenvolver suas habilidades de solucionar problemas, mas não sofra só; não deixe suas frustrações passageiras de hoje te impeçam de comemorar mesmo as pequenas evoluções dos últimos dias e descubra suas melhores formas de aprender, pois você fará isso diariamente a partir de agora. Boa viagem!