#196 - O dev que ainda constrói por diversão

Num mercado obcecado por métricas e buzzwords, o projeto pessoal virou ato de resistência.

mai 05, 2026

Hey! 👋

Falando em construir por diversão, a Codecon tem um evento feito exatamente pra isso.

A Codecon Universe é um hackathon de ideias inúteis e absurdas, soluções pra problemas que não existem e projetos que desafiam a lógica. Sem KPI, sem ROI, sem pitch pra investidor. O objetivo é criatividade técnica pura.

Se você ficou com vontade de ir pro galpão, vai lá pega suas ferramentas e se inscreve!

🛸 Codecon Universe 26

Gabriel Nunes (@nunesgabriel)

O dev que ainda constrói por diversão

Existe um tipo de dev que está desaparecendo. Não o dev desempregado, não o dev substituído por IA, mas o dev curioso aquele que passava uma tarde inteira implementando um emulador de Game Boy só pra entender como hardware funciona, que subia um serviço com uma tecnologia nova sem escrever uma proposta pra isso, que construía coisas sem saber exatamente por quê. Esse perfil foi sendo substituído aos poucos pelo dev performático aquele que vive preocupado com o próximo case do LinkedIn, com subir o DAU, com escolher o framework certo antes mesmo de ter um problema pra resolver.

A cultura do desenvolvimento virou uma corrida de KPIs disfarçada de inovação. Todo mundo “constrói”, mas poucos ainda criam. E no meio disso tudo, o projeto pessoal, aquele galpão improvisado no quintal, sem blueprints nem aprovação de comitê, ficou com cara de coisa de quem tem tempo sobrando. Só que tempo não é o problema. A gente passa em média duas horas por dia consumindo conteúdo que não muda nada na nossa vida. O que falta não é hora no relógio, é clareza sobre o que vale a pena construir com ela.

O argumento mais honesto a favor dos side projects não é que eles podem virar startups. A maioria não vai. O argumento real é que eles são o único espaço onde você ainda é o arquiteto, o revisor e o usuário ao mesmo tempo. É onde você quebra coisas sem que ninguém pague o preço, onde experimenta sem precisar justificar o ROI, onde o erro custa uma noite e não um trimestre. E é exatamente nessa liberdade que o aprendizado acontece de verdade, não nos cursos, não nos certificados, mas na gambiarra que funcionou e na que não funcionou.

Tem algo mais profundo acontecendo aqui também. O trabalho em empresa grande ensina a escala, a disciplina, os processos que existem porque alguém aprendeu do jeito difícil o que acontece sem eles. Mas escala tem um custo: a rigidez. Você vira um trabalhador num canteiro enorme, raramente escolhe os materiais, quase nunca experimenta com a fundação. O “galpão” é onde você pega tudo que aprendeu finalmente testa nas suas próprias condições. É onde a curiosidade não precisa pedir passagem.

Proteger seus projetos pessoais não é conselho de produtividade. É quase um ato político num mercado que quer transformar todo dev em executor de tickets. O dev que ainda constrói por diversão é o que lembra por que entrou nessa área, é o que aparece numa reunião com contexto real porque já quebrou aquela ferramenta no próprio ambiente, é o que não depende só do emprego pra continuar crescendo. O side project não é o oposto do trabalho sério. É o que garante que você ainda vai querer construir quando o trabalho tentar convencer você do contrário.

Um recado do patrocinador 📣

Quando o sistema cresce, a arquitetura precisa acompanhar

Sistemas começam simples. Poucos serviços, poucas integrações, decisões rápidas.

Com o tempo, isso muda. Novas demandas aparecem, o volume cresce e aquilo que antes funcionava bem começa a gerar acoplamento, dependências e gargalos difíceis de evoluir.

É nesse momento que arquitetura deixa de ser só organização técnica e passa a ser uma necessidade para sustentar crescimento.

A arquitetura celular surge como uma forma de lidar com esse cenário. Estruturar o sistema em partes mais independentes, com responsabilidades claras, ajuda a evoluir com mais segurança, reduzir impactos e manter a velocidade do time.

No Asaas, esse tipo de desafio faz parte do dia a dia da Engenharia. Pensar a evolução da arquitetura não é algo isolado, mas contínuo, sempre conectado ao que o produto precisa.

Para quem gosta de atuar nesse nível de construção e evolução de sistemas, o Asaas está com uma oportunidade aberta para Tech Leader de Engenharia (arquitetura celular), confira mais detalhes: vaga Tech Leader de Engenharia

🤖 As regras de ouro do produto agent-first

O PostHog reconstruiu sua arquitetura de IA duas vezes antes de chegar numa coisa que funcionasse. O aprendizado virou cinco regras: agentes precisam conseguir fazer tudo que o usuário faz, devem ser encontrados no nível de abstração onde já raciocinam bem (SQL, no caso deles), o contexto universal precisa ser carregado desde o início, e assim por diante. É a visão mais prática que li sobre o que significa construir um produto pensando em agentes como usuário primário, não como feature bolt-on.

⚡ Imperativo vs. declarativo: a distinção que você usa todo dia sem saber nomear

Todo mundo que aprende React escuta que “React é declarativo”. Mas quando você tenta explicar o que isso significa, a definição de livro não ajuda ninguém. Esse artigo resolve isso com metáforas e exemplos reais de código comparando for loops com map e reduce. A virada é perceber que toda solução declarativa é uma abstração sobre uma implementação imperativa e que React é só mais uma camada disso.

🧠 Procrastinação produtiva: por que seu cérebro foge das tarefas chatas

Você terminou três tarefas hoje, mas a mais importante não saiu do lugar. O autor percebeu isso nos próprios dados de edição de vídeo: quanto mais tempo entre a gravação e a edição, menor a produtividade e os projetos “especiais” (novos, fora da fila) sempre saíam mais rápido. A ciência explica, nosso cérebro responde mais a estímulos novos (dopamina), evita emoções negativas associadas à tarefa principal (amígdala) e ainda se convence de que já foi produtivo o suficiente depois de completar tarefas menores (moral licensing). A solução não é força de vontade é entender a mecânica e construir um hábito.

🪝 Uma promise que nunca resolve, como padrão de controle de fluxo

Uma promise que nunca resolve é uma forma surpreendentemente limpa de interromper uma função assíncrona. O Inngest usa esse padrão em produção no SDK TypeScript pra pausar workflows, memoizar resultados de steps e retomar execuções serverless, tudo isso sem abrir mão do async/await normal. O artigo também derruba o medo de memory leak: a garbage collection cuida de tudo quando nada mais referencia a promise.

🔍 Os comandos git que você deveria rodar antes de ler qualquer código

Cinco one-liners de git que revelam o estado de saúde de um codebase antes de você abrir um único arquivo. Churn hotspots, bus factor, clusters de bug, velocidade de commit e frequência de reversões de emergência. O autor trabalha como auditor de codebases e usa exatamente esses comandos na primeira hora de qualquer auditoria. Dados de equipe disfarçados de dados de código.

🎨 “Design Engineer”: o título que revela a confusão do mercado

As descrições de vagas com esse título variam tanto que parecem falar de profissões diferentes. E a autora argumenta que isso não é falha de RH, é o mercado tentando nomear algo em tempo real enquanto a IA redefine os limites entre design, produto e engenharia. O título vai se estabilizar. O que o mercado está pedindo de fato é uma postura, a disposição de ter responsabilidade sobre o arco completo, da ideia ao produto entregue.