Como não ser um dev de tutoriais e aprender de verdade
Tutoriais e cursos são bons meios de aprendizado. Mas estão longe de ser o suficiente pra você ser um bom engenheiro de software.
A carreira em TI se tornou mais famosa nos últimos anos.
Tivemos um boom muito forte, especialmente durante a pandemia. Muitas vagas abertas, poucas pessoas disponíveis.
Quantas vezes eu não vi um anúncio nos moldes de: faça isso para ter um salário de 5 mil em 6 meses.
Diminuíram, mas tem alguns que ainda estão aí. Não acredite nessas promessas.
Não estou dizendo que é impossível. Mas a barra está sim mais alta.
O mercado que causou uma tempestade perfeita a favor de candidatos a vagas de TI acabou.
As vagas estão se normalizando de novo, e o mercado abrindo as portas.
Porém, devido ao grande interesse em TI e engenharia de software, o mercado de júnior e pleno está super competitivo.
Eu recebo muitas dúvidas similares nesse meio:
Qual o melhor jeito de conseguir trabalho sem muita experiência?
O que eu devo estudar? Qual linguagem de programação?
Estou em transição de carreira, qual caminho eu devo seguir?
A minha tentativa hoje é explicar o que eu faria nesse tipo de mercado.
E, acima disso, mostrar como você sair de uma fase que muita gente passa muito tempo: fazer tutoriais demais.
✨ O que esperar do artigo
Por que só fazer cursos e tutoriais não é suficiente para se destacar em engenharia de software
Como misturar aprendizado guiado e não-guiado para acelerar seu crescimento
Estratégias práticas para sair do tutorial hell e começar a construir projetos reais
Abordagens de aprendizado guiadas e não-guiadas
Em engenharia de software, existem dois tipos principais de aprendizado:
Guiado: Tutoriais, cursos, vídeos do YouTube. Qualquer coisa onde você está seguindo um guia.
Não-guiado: Criar seus próprios projetos, modificar tutoriais existentes, consultar documentação. Qualquer coisa onde você não está seguindo um passo a passo.
O problema? A maioria das pessoas foca apenas no aprendizado guiado. É confortável. É seguro. Você sempre sabe o próximo passo.
Mas é uma armadilha.
Se você só seguir tutoriais, nunca vai desenvolver as habilidades de resolução de problemas necessárias para ser um engenheiro de software.
Por outro lado, se você focar apenas em aprendizado não-guiado, vai reinventar a roda várias vezes. E pode desistir achando que "não tem jeito para a coisa".
A solução? Misture os dois tipos de aprendizado.
Algumas estratégias que funcionam:
Siga um tutorial, mas faça modificações intencionais
Termine o tutorial e tente refazer sem olhar o código
Use o projeto do tutorial como base para criar algo novo
Como praticar de maneira eficiente
A prática em engenharia de software pode vir de várias fontes. E cada uma tem seu papel no seu desenvolvimento.
Educação formal vs autoditada
A faculdade pode ser um excelente ambiente para praticar. Você tem:
Projetos com prazos definidos
Feedback de professores experientes
Um ambiente seguro para cometer erros
Colegas para fazer pair programming
Acesso a diferentes áreas da computação
A faculdade é um ótimo caminho, e eu recomendo para todos que podem. Mas não é a única maneira de entrar no mercado.
Se você não pode ou não quer fazer faculdade, existem alternativas:
Bootcamps intensivos (3-6 meses)
Cursos e livros técnicos
Comunidades de programação
Mentoria 1:1 com desenvolvedores mais experientes
O importante é ter um ambiente onde você possa praticar com feedback constante. Em especial, onde você possa achar oportunidades de aprendizado não guiado.
Cometa erros (sem medo!)
Uma das melhores maneiras de aprender é fazendo experimentos.
Quando estiver seguindo um tutorial:
Mude valores e veja o que acontece
Remova linhas de código para entender sua função
Adicione funcionalidades extras
Tente quebrar o código de propósito
Em desenvolvimento de software, erros são gratuitos. Diferente de outras profissões, podemos experimentar sem consequências graves.
Se você está sempre acertando, provavelmente não está aprendendo o suficiente.
Ideias de projetos
O segredo é começar com problemas reais:
Resolva seus próprios problemas: A Shaundai Person, hoje Senior Software Engineer na Netflix, começou sua transição de carreira criando ferramentas para seu trabalho anterior em vendas
Crie para usuários reais: Mesmo que seja só sua família ou amigos usando
Compartilhe seu código: Especialmente para projetos frontend, onde é mais fácil ter feedback visual
Contribua para open source: Comece com documentação e bugs simples
Algumas plataformas que podem ajudar
Estas plataformas misturam aprendizado guiado com desafios práticos:
GreatFrontEnd: Para entrevistas e projetos frontend
CodeCrafters: Recrie ferramentas populares do zero
iCodeThis: Desafios diários de frontend
Advent of Code: Puzzles de programação sazonais
Frontend Mentor: Projetos reais com design profissional
Kaggle: Plataforma de competições e projetos de data science, com datasets públicos e comunidade ativa de cientistas de dados.
O importante é que você não fique só consumindo conteúdo. Crie algo. Mesmo que seja pequeno. Mesmo que não seja perfeito.
Do tutorial ao projeto real
Vamos pegar um exemplo concreto: o clássico tutorial de TODO list.
Em vez de apenas seguir o passo a passo, você pode:
Adicionar categorias para as tarefas
Implementar subtarefas
Adicionar um timer Pomodoro para cada tarefa
Sincronizar com um calendário
Adicionar tags e filtros
O segredo é pensar: que problema real esse projeto poderia resolver?
Por exemplo: em vez de uma TODO list genérica, que tal uma aplicação para controlar manutenções do carro? Ou uma lista de compras que calcula o preço total baseado nos últimos gastos?
Equilibrando teoria e prática
Como dividir seu tempo entre aprender e fazer?
Uma regra que funciona bem é o princípio 70/30:
70% do tempo em projetos práticos
30% em tutoriais e documentação
Por exemplo, numa semana de 10 horas de estudo:
3 horas assistindo tutoriais e lendo documentação
7 horas codificando e experimentando
A chave é manter um ciclo curto entre aprender e aplicar. Não passe mais que algumas horas consumindo conteúdo sem colocar a mão no código.
Eu sei que as vezes é difícil. Eu mesmo já sofri muito com isso. Se você olhar meu histórico do Google, provavelmente vai encontrar eu pesquisando qual a melhor linguagem de programação centenas de vezes.
Acredite, não vale a pena.
Gaste o seu tempo fazendo atividades práticas. E não questionando se vale a pena aprender Go em 2024.
Escolha uma linguagem. De preferência, uma que é amplamente usada no mercado, para ter mais facilidade em procurar emprego depois.
TypeScript/JavaScript, Python, Java, Go, C#, Ruby.
Não importa a tua escolha.
Mas, no começo, você precisa de profundidade antes de amplitude.
Seja mestre em uma linguagem de programação. Depois, aprenda 1 cada 1-2 anos, pois é sempre um bom jeito de estuar. Mas não antes de dominar uma.
Medindo seu progresso
Como saber se você está realmente evoluindo?
Aqui estão alguns sinais positivos:
Você consegue ler documentação técnica com mais facilidade
Bugs não te assustam tanto - você tem um processo para debugar
Você começa a ver padrões em diferentes problemas
Você consegue ajudar outras pessoas com dúvidas básicas
Seus projetos são mais complexos que tutoriais básicos
O progresso nem sempre é linear. Às vezes você vai sentir que está regredindo - geralmente é sinal que está prestes a dar um salto no aprendizado.
🎯 Desafio da semana
Aqui está um desafio para você colocar isso em prática:
Escolha um tutorial que você já fez
Liste 3 modificações que tornariam o projeto mais útil
Implemente pelo menos uma dessas modificações
Compartilhe seu progresso no LinkedIn ou Twitter
Se você criar algo e quiser divulgar, pode me marcar no LinkedIn ou no Twitter. Adoraria ver.
Por que você precisa abraçar o desconforto
Não deixe o perfeito ser inimigo do bom o suficiente.
Se você estiver sentindo síndrome do impostor, quer dizer que está indo no caminho certo. É sério.
A partir do momento que você se sentir confortável, é quando você não vai estar aprendendo o quão rápido você pode.
Não quer dizer que você precisa insistir em sempre aprender algo novo todos os dias. Mas sim, especialmente no começo, você precisa se acostumar a ser a pessoa mais inexperiente num grupo.
E, assim que você estiver sabendo mais do que todos ao seu redor, é hora de arrumar outro grupo.
Uma citação que ouvi recentemente resume bem isso:
"Parei de perseguir promoções e comecei a perseguir o crescimento de opções. Pare de focar na carreira sequencial e veja sua carreira como um portfólio de experiências." - Stephanie, Head of Technical Marketing no Google Cloud
Essa é uma citação que ouvi recentemente no excelente podcast do Refactoring.
E é algo que faz total sentido, agora que passo pra pensar. Não foque muito em ser promovido, especialmente no começo. Mas sim em aumentar o seu leque de opções disponíveis para a tua carreira.
🌟 Resumo
Misture aprendizado guiado (tutoriais, cursos) com não-guiado (projetos próprios)
Existem vários caminhos para aprender. A faculdade é um ótimo caminho, mas se você não puder, existem alternativas
Foque em resolver problemas reais e obter feedback frequente
Não tenha medo de errar - é assim que se aprende mais rápido
Mantenha-se desconfortável - quando estiver muito confortável, é hora de novos desafios
📚 Referências
How To Learn Stuff Quickly: o Josh é um dos criadores mais sensacionais que existem. O conteúdo dele é incrível, e esse artigo é super relevante para o tema de hoje.
Learn In Public: já falamos disso no artigo de como ter sorte mas vale a pena reiterar os benefícios de aprendizado em público.
🔗 Links interessantes dos últimos dias
O Paul Graham fez um pequeno artigo sobre escrever. Achei especialmente interessante a analogia sobre como antigamente as pessoas eram mais fortes, quando trabalho manual era necessário. Com IAs cada vez mais "inteligentes", é possível que o mundo se divida em pessoas que escrevem, e pessoas que não escrevem. O que não é um bom olhar para o futuro.
Não deixe que o sucesso dos outros diminua a satisfação dos seus próprios esforços. Uma mensagem sensacional pelo DHH neste artigo.
Recentemente batemos a marca de 1000 assinantes! 🙏
Essa era minha meta para esse ano, mas agora que batemos, vou precisar pensar em outra.
Tenho um evento super interessante planejado para Dezembro: uma discussão sobre o que significa senioridade em engenharia de software. Em particular, as participantes são todas mulheres, pois existe um débito grande de diversidade na indústria.
E eu quero mostrar para outras mulheres engenheiras que podem sim ter referências de pessoas com senioridade e em poosições de liderança, mesmo que não trabalhem na mesma empresa.
A ideia é ter uma conversa e discutir sobre esse tema que tem várias opiniões diferentes.
Mais detalhes na próxima semana!
Muito obrigado a todos que confiam no meu trabalho. Estou muito feliz de estar podendo mandar essa mensagem pra 1000+ pessoas que gostam do meu conteúdo sobre engenharia de software e mercado internacional.
Se você quiser fazer mais algo pra me ajudar, compartilhe esse artigo com outras pessoas e clique no botão de ❤️ curtir.
Bom demais, obrigado!