Construir side projects quando você já trabalha 8h por dia de código
Todo mundo fala que você deveria ter projetos paralelos. Ninguém fala sobre o cansaço cognitivo de programar o dia todo e tentar programar de noite também.
Existe um conselho que circula em comunidades de desenvolvimento que parece razoável até você tentar aplicá-lo no mundo real: "se você quer crescer como dev, construa projetos paralelos."
A lógica faz sentido. Projetos paralelos permitem experimentar tecnologias que você não usa no trabalho. Constroem portfólio. Desenvolvem a habilidade de tomar decisões de design sozinho, sem a estrutura de uma equipe.
O problema é que esse conselho ignora completamente a realidade de quem trabalha com código o dia todo.
Programar é mentalmente exaustivo de um jeito específico. Não é o mesmo cansaço de fazer trabalho físico repetitivo. É o cansaço de manter vários contextos na cabeça ao mesmo tempo, de resolver problemas que não têm solução óbvia, de depurar comportamentos que parecem impossíveis.
Quando você termina oito horas de trabalho intenso de desenvolvimento, abrir um projeto paralelo não é só questão de motivação. É questão de capacidade cognitiva. O músculo que você precisa para resolver problemas de programação já foi usado hoje.
Eu tentei ignorar isso por um tempo. Planejava programar nas noites depois do trabalho, definia metas semanais para o projeto paralelo, e depois ficava olhando para a tela sem conseguir formular um pensamento coerente.
O que funcionou foi parar de tentar competir com a noite de terça-feira e começar a usar finais de semana com intenção.
Não todo final de semana. Não por oito horas. Mas blocos de duas a três horas numa manhã de sábado, quando o cansaço da semana ainda não instalou completamente mas a cabeça já descansou o suficiente.
Isso reduziu a ambição dos projetos, mas aumentou o que realmente ficava pronto. Um projeto de escopo menor que chega a alguma forma funcional enseina mais do que um projeto ambicioso que fica em 30% por dois anos.
Teve uma época em que eu tinha três projetos paralelos ao mesmo tempo. Nenhum deles avançou de verdade. Eu ficava rodando entre eles, fazendo um pouco em cada, sem nenhum ganhar tração suficiente para ficar interessante.
Mudei para um projeto por vez. Mesmo que demorasse mais para qualquer coisa ficar pronta, eu aprendia mais profundamente — porque ficava com o projeto tempo suficiente para chegar nos problemas difíceis, não só nos fáceis do começo.
Tem um tipo de projeto paralelo que aprendi a preferir: projetos que resolvem um problema meu real.
Não necessariamente um produto que vou vender. Pode ser um script que automatiza algo que eu faço toda semana, uma ferramenta de linha de comando que melhora alguma parte do meu fluxo de trabalho, uma dashboard que agrega informações que eu normalmente acesso em lugares diferentes.
Projetos assim têm uma propriedade valiosa: eu vou usar. E usar é o teste real. Quando você usa o que construiu, descobre problemas que nunca aparecem quando o projeto é teórico. E corrigir esses problemas é onde o aprendizado real acontece.
Sobre comparação com outros devs que parecem ter projetos paralelos incríveis sempre: a maioria do que aparece online é resultado de seleção. Você vê os sucessos, não os projetos abandonados depois de duas semanas. Você vê o produto final, não as seis tentativas anteriores.
Construir projetos paralelos com cansaço cognitivo real é diferente da versão que existe no LinkedIn. E tudo bem. O que importa é aprender, não parecer produtivo.
Essa semana: se você tem um projeto paralelo parado, verifique se o escopo está correto. Se você não consegue terminar uma parte pequena em duas horas de trabalho focado, o escopo provavelmente está grande demais para a energia que você tem disponível agora.