A alegria de criar software de brinquedo

• Criar software de brinquedo é uma forma de recuperar a alegria e a criatividade essenciais do desenvolvimento de software
• Em uma era em que a alegria pura de desenvolver software está desaparecendo por causa da IA e da industrialização, criar programas simples de brinquedo como projetos pessoais pode levar a conhecimentos úteis no trabalho e a uma compreensão mais profunda
• Software de brinquedo segue a regra 80:20, implementando o máximo de funcionalidade com o mínimo de código, e o ponto-chave é evitar excesso de design e obsessão por acabamento
• A própria experiência de construir e enfrentar os problemas por conta própria, sem depender de ferramentas de IA como LLM, é a alegria essencial do aprendizado e do crescimento

---

Por que você deveria criar mais programas de brinquedo

• A famosa frase de Richard Feynman, “Aquilo que eu não consigo criar, eu não entendo”, mostra que a experiência de construir algo com as próprias mãos leva a uma compreensão profunda
• Ao contrário do conselho tradicional de “não reinventar a roda”, a experiência de construir a roda você mesmo ensina mais do que leitura ou estudo teórico
• Recentemente, a IA e a industrialização do software estão ameaçando a alegria e o espírito artesanal do desenvolvimento
• Criar software de brinquedo ajuda a recuperar a alegria simples de se apaixonar novamente pelo computador

Princípios dos programas de brinquedo: Keep it simple

• Software de brinquedo segue o princípio 80:20: atingir 80% da funcionalidade com 20% do esforço
• O objetivo não é o produto final, mas a simplicidade e a implementação direta dos princípios centrais
• Há um alerta contra arquitetura excessiva (over-engineering), com ênfase em escrever apenas o código realmente necessário
• Recomenda-se uma abordagem em que todos os caminhos de código permaneçam ainda não implementados e sejam ampliados conforme a necessidade
• Mesmo sistemas que parecem pequenos podem, na prática, ser surpreendentemente fáceis de construir

Benefícios adicionais do software de brinquedo

• O conhecimento obtido em projetos de brinquedo muitas vezes ajuda mais do que o esperado no trabalho real, em rastreamento de problemas, correção de bugs e prevenção de erros
• Vivenciar diretamente as restrições ao esbarrar nelas na prática traz insights sobre a essência do software e pode até levar a soluções inovadoras

Exemplo: lista de vários projetos de software de brinquedo

Aqui está uma organização dos tipos de projetos de brinquedo que o autor implementou diretamente nos últimos 15 anos, com dificuldade e tempo estimado. Cada projeto inclui uma breve descrição e materiais adicionais de referência

• Engine de regex (dificuldade 4/10, 5 dias): interpretar regex no estilo POSIX e identificar strings correspondentes, levando a uma compreensão profunda do funcionamento interno das expressões regulares
• Kernel de SO x86 (dificuldade 7/10, 2 meses): inclui CLI, drivers simples, gerenciador de memória etc.; é possível expandir com sistema de arquivos em memória, executáveis ELF, GUI, isolamento de processos e mais
• Emulador de GameBoy/NES (dificuldade 6/10, 3 semanas): compreensão de conjuntos simples de instruções e do hardware, com implementação de PPU, PSG e formatos peculiares de cartucho
• Jogo para GameBoy Advance (dificuldade 3/10, 2 semanas): jogo simples baseado em sprites, com comunidade de desenvolvimento GBA ativa e estrutura de sistema que dá para entender sozinho
• Engine de física 2D (dificuldade 5/10, 1 semana): mecânica newtoniana básica e tratamento simples de colisões, com possibilidade de expansão para formas complexas, inércia, algoritmos de resolução, soft bodies e interações compostas
• Interpretador dinâmico (dificuldade 4/10, 1–2 semanas): um tree-walking interpreter; criar sua própria linguagem traz prazer técnico e criativo
• Compilador da família C (dificuldade 8/10, 3 meses): sistema de tipos simples e ambiente-alvo, com projeto de arquitetura para várias otimizações e suporte a múltiplos backends
• Editor de texto (dificuldade 5/10, 2–4 semanas): começando de E/S simples de arquivos; pode usar toolkits de UI (QT/GTK etc.), com preferência por console, e adicionar unicode, syntax highlighting, múltiplos buffers, LSP e outros recursos
• Runtime assíncrono (dificuldade 6/10, 1 semana): no caso de Rust, tratamento de tarefas impl Future e implementação de concorrência, com adição de wake-up de I/O
• Hash Map (dificuldade 4/10, 3–5 dias): aprender o funcionamento interno, closed e open addressing, regra de Robin Hood, além de entender desempenho e quando usar
• Rasteriser / Texture Mapper (dificuldade 6/10, 2 semanas): aprender a estrutura do pipeline gráfico 3D, matemática vetorial, Z-buffer, mapeamento de textura e até algoritmos de shading
• Renderização com Signed Distance Field (dificuldade 5/10, 3 dias): representação matemática do espaço, visualização simples e compreensão de shaders e matemática vetorial
• Engine de voxel (dificuldade 5/10, 2 semanas): fácil de entender para quem já tem experiência com gráficos 3D ou desenvolvimento de jogos, com possibilidade de adicionar texturas, geração procedural, rede e mais
• Máquina virtual threaded (dificuldade 6/10, 1 semana): interpretador rápido, implementação otimizada sem geração de código específica por arquitetura, com desempenho que pode rivalizar com compiladores
• Toolkit de GUI (dificuldade 6/10, 2–3 semanas): após experiência com ferramentas básicas de UI, é possível implementar diretamente recursos avançados como engine de layout, text shaping e acessibilidade
• Simulador de mecânica orbital (dificuldade 6/10, 1 semana): implementação simples do modelo gravitacional newtoniano, com expansão para interação entre vários corpos celestes, algoritmos de integração, visualização e até dados da NASA
• Bitwise Challenge (dificuldade 3/10, 2–3 dias): jogo reproduzido apenas com estado de 64 bits, útil para treinar gerenciamento criativo de estado; regras detalhadas podem ser consultadas no GitHub
• Framework ECS (dificuldade 4/10, 1–2 semanas): implementar diretamente a estrutura Entity-Component-System, integrando o sistema de tipos da linguagem e ajustando para desempenho e restrições específicas
• Emulador de CHIP-8 (dificuldade 3/10, 3–6 dias): máquina virtual simples dos anos 1970, rápida de implementar e capaz de executar vários fan games
• Engine de xadrez (dificuldade 5/10, 2–5 dias): começa pelas regras e evolui aos poucos; perder para uma engine criada por você mesmo é um momento marcante de crescimento como desenvolvedor
• Shell POSIX (dificuldade 4/10, 3–5 dias): princípios e limites de um shell baseado em POSIX, com compreensão profunda e contato com inúmeros truques ao implementar compatibilidade real da linguagem Shell

Conselhos sobre o uso de ferramentas como LLM

• Ferramentas avançadas como LLM também são úteis, mas o aprendizado verdadeiro se aprofunda mais quando você explora por conta própria
• Em vez de olhar soluções existentes, é no processo de explorar territórios desconhecidos e encontrar sua própria resposta que se obtém uma sensação de realização mais profunda
• Ao tocar projetos de brinquedo sem LLM, no começo pode parecer estranho e difícil, mas com o tempo você passa a sentir uma alegria técnica própria e um alto senso de realização

• Se você vai de carro, não sente o “runner’s high” de quem corre — a alegria mais profunda vem da experiência direta, e não do atalho

[tolluset]

Também entendo essa ideia de tentar fazer sem LLM. Se não for algo que exija desenvolvimento rápido, acho mais divertido e gratificante construir entendendo cada parte, uma por uma.

[nezz1204]

Então era sobre projetos paralelos. Pelo título, achei que fosse sobre desenvolver software para brinquedos. haha

[GN⁺]

Comentários no Hacker News

• Fico curioso se mais gente usa LLM como se fosse mecanismo de busca. Antes eu pesquisava no Google algo como “pros cons mysql mongodb” e passava um tempão lendo documentação oficial, fóruns, blogs e até Stack Overflow. Mas o tempo gasto lendo e aprendendo sempre foi bem-vindo. Hoje eu mando para um LLM algo mais específico, tipo “vantagens e desvantagens de mysql vs mongodb para armazenar fotos, com links de referência”. Dá para captar rapidamente o essencial, e gosto do fato de virem links junto, então não preciso depender de alucinação. Às vezes também peço algo mais concreto, como “monte um data schema no postgres para armazenar metadados de fotos; quero separar X em outra tabela”, mas só uso isso quando sei exatamente que tipo de resultado deveria sair. É mais quando tenho preguiça de digitar tudo ou esqueci momentaneamente o nome exato de um tipo (int e integer, por exemplo)

  • Se você usar LLM como motor de consulta técnica, ele muitas vezes entrega algo que parece plausível à primeira vista, mas está errado em pontos importantes. Se você acreditar cegamente e seguir a resposta, pode desperdiçar horas ou até dias à toa. Mesmo pedindo links de referência, metade das vezes eles realmente ajudam e metade vêm com coisas sem relação. Ainda assim, há uma coisa que ele faz de forma claramente boa: busca reversa no estilo "tip-of-my-tongue". Ou seja, você descreve um conceito e ele sugere os termos de busca correspondentes; nisso ele é consistente e satisfatório
  • Em breve, provavelmente as empresas vão pagar muito dinheiro aos LLMs para que seus produtos apareçam em comparações mais favoráveis. O LLM pode mudar só o enquadramento e a ênfase para fazer o resultado parecer 'orgânico'. Isso porque ele pode exibir apenas informações verdadeiras e fundamentadas, alterando apenas a 'ênfase do contexto'
  • Eu também uso LLM do mesmo jeito, para busca. Dá a sensação de voltar ao início dos anos 2010, quando pesquisar no Google era poderosíssimo. Aquele tempo em que dava para encontrar qualquer coisa. Claro que isso não durou muito, e hoje pesquisar no Google é praticamente dor e frustração puras. Tenho muitas reclamações sobre as mudanças que o Google e os profissionais de marketing trouxeram, mas os LLMs atuais passam a sensação de serem muito eficientes para trazer à tona informação online na hora. Os links de referência também costumam ser bem corretos. No fim, a mesma força de mudança de antes vai agir de novo, então parece uma oportunidade passageira antes que isso também se perca
  • Eu também sou uma das pessoas que usa LLM como mecanismo de busca. Ainda não uso AI IDE. Recentemente, numa entrevista técnica ao vivo, tentei responder fazendo consultas no meu LLM escolhido como se estivesse pesquisando no Google, e o entrevistador disse que era a primeira vez que via um candidato usar IA desse jeito. Eu achava que a maioria dos desenvolvedores ainda estava usando IA primeiro para busca, antes de AI IDE. Será que casos como o nosso ainda são raros?
  • Eu uso LLM como mecanismo de busca até no desenvolvimento. Algo como: “analise o repositório que clonei em /src/foo e explique como a barFeature foi implementada. Agora olhe o projeto em /src/baz e explique por que a abordagem de foo é difícil de aplicar em baz”. Eu não peço para criar algo novo; uso para traduzir para minhas ideias dentro de projetos existentes. No desenvolvimento realmente novo e desafiador, eu gosto de programar com as próprias mãos

• Em termos de carreira, uma das melhores decisões que tomei foi um projeto pessoal feito durante uma pausa de 6 meses entre empregos. Eu sempre tinha muitos projetos que queria começar, mas como não havia restrições, o escopo ficava crescendo e no fim eu não concluía nada. Então decidi investir só 1 semana em cada projeto. Eu fazia apenas o que desse para construir em 1 semana. A experiência de sair do zero e fazer em uma semana algo utilizável, numa linguagem ou framework novo, ou até numa área desconhecida, me deu uma confiança enorme. Também me fez lembrar por que eu gostava de programar originalmente. Se você tiver alguns meses livres entre empregos, em vez de ficar só estudando para entrevistas no estilo Silicon Valley, fazer toy projects pode te surpreender pelo tanto que você já sabia

  • Com ferramentas de geração por IA, isso ajuda demais nesses toy projects pessoais. Eu trabalho mais com backend, mas também consigo fazer frontend. Só que CSS sempre me consumia tempo demais, e no passado isso fazia vários projetos pessoais morrerem antes do fim. Agora eu digo para a IA “deixa bonito” e ela entrega algo em 85% do caminho; eu só preciso corrigir bugs e fazer ajustes. Graças a isso, algo que antes parecia um lamaçal agora ficou bem mais leve, e eu acabo criando projetos pessoais com mais frequência
  • Ultimamente venho acumulando frustração com bibliotecas que uso e migrando para consertar eu mesmo. Se encontro documentação de onboarding incompleta, SDLC quebrado ou problemas graves de desempenho, acabo passando o dia inteiro corrigindo essas coisas. Diferente de um projeto colaborativo, em que outras pessoas estão esperando, toy project pessoal facilita cair em side quests
  • Fico curioso sobre como você conseguiu ficar 6 meses parado e ainda assim arrumar o próximo emprego. Eu também queria tirar 6 meses, mas tenho medo de acabar ficando mais tempo sem querer porque não conseguiria arrumar trabalho depois
  • Quando eu era mais novo, montava servidor com classic ASP + SQL, mexia em HTML/CSS/JS e publicava tudo com facilidade. Naquela época bastava subir os arquivos por FTP. Hoje quero experimentar formas mais modernas, mas sempre que faço projeto pessoal acabo me perdendo nas decisões sobre deploy e processo de desenvolvimento. Tenho curiosidade sobre como vocês escolhem hospedagem e forma de deploy para toy projects
  • Para mim também ficou claramente mais rápido tocar esses projetos pessoais porque a IA gera boilerplate e código de automação de testes

• Desenvolver software de brinquedo é parecido com fazer manutenção em bicicleta, carro ou barco. É divertido. Mas consertar a bicicleta que você usa para ir ao trabalho é estressante. Fazer toy software é divertido, mas quando em algum momento eu quero realmente usar aquilo, acabo descobrindo todos os bugs e não tenho tempo para corrigir — esse é o dilema

  • Eu prefiro desenvolver software só para meu próprio uso. Com carro é parecido: me satisfaz mais usar por mais tempo algo mais barato
  • Já houve uma época em que eu administrava meu próprio servidor de email, mas hoje não faço mais isso. Não era porque eu queria fazer pessoalmente; passei a querer deixar esse trabalho com especialistas
  • Recentemente fiz meu próprio aplicativo de faturas. Foi divertido ir adicionando uma a uma as funcionalidades de que eu precisava. Incluí até recursos pelos quais eu pagaria mensalidade em serviços existentes, mas no momento em que realmente precisei enviar uma fatura, percebi que havia muitos problemas a resolver no app que eu mesmo fiz — estilo, preenchimento de endereço etc. No fim, senti a necessidade de encontrar um equilíbrio entre a diversão de pedalar e a praticidade da bicicleta de deslocamento. Com o tempo, talvez diversão e praticidade se aproximem cada vez mais
  • Eu também tenho muita coisa que queria transformar em “software completo”, mas me faltam tempo e energia. Há muito trabalho chato e repetitivo. Ainda assim, gerenciar e selecionar “resultado de IA” também dá um bom trabalho. Ainda estou numa fase inicial de experimento, então não sei se vou manter essa opinião daqui a alguns meses
  • É por isso que fazer homepage pessoal é tão divertido. Dá para usar de verdade como o meu parquinho

• Fico surpreso com tantas opiniões negativas sobre LLM. LLM te entrega a informação mastigada. Quando você começa um projeto novo, obviamente não começa sabendo tudo. Você faz o melhor que pode, quebra a cara, depois estuda, entende por que não funcionou e ajusta com uma abordagem nova — isso é aprendizado de verdade. Se você já souber tudo e só seguir tutorial, não vivencia os limites de cada abordagem nem seus prós e contras reais. Por exemplo, você pode tentar fazer um parser com expressões regulares e descobrir por conta própria que não consegue lidar com expressões recursivas; também aprende na prática sobre estruturas mais complexas e questões de complexidade de tempo. Ao implementar um compilador otimizador você mesmo, vai se frustrar com vários truques de otimização e entender por que compiladores reais foram desenhados daquele jeito. Ao escrever um layout engine do zero, dá até para sentir na pele a dificuldade de tratar corretamente um conceito aparentemente simples como width. Não existe experiência melhor do que aprender por tentativa e erro. Só porque o LLM evita alguns erros, eu não gostaria de perder também oportunidades importantes de aprendizado

  • Muita gente diz que, se você não usar LLM, vai ficar para trás, mas às vezes penso que usar menos LLM pode ser uma grande vantagem no longo prazo

• Eu também passei anos fazendo incontáveis projetos estranhos nas noites e fins de semana para aprender computação gráfica. Não ganhei um centavo com isso, mas foi o que me levou ao emprego dos sonhos. Alguns trabalhos representativos:

  • Tiny ray-tracer
  • 2D rigid-body simulator
  • Character animation system
  • Animation curve visualizer
  • Motion capture playback in the web O verdadeiro objetivo de todas essas montanhas de código era “adquirir conhecimento”

• Sinto que o espírito de “a diversão de programar” apresentado neste texto é algo de que realmente precisamos. Na era da programação por agentes de IA, isso fica ainda mais valioso. Mas acho que o tempo estimado pelo autor para os toy projects é curto demais. Eu também não sou exatamente a média, mas mesmo assim acho que a maior parte daquela lista não são projetos que terminam em poucos dias se você estiver trabalhando só 2 ou 3 horas por dia. Parece que só a pesquisa antes de começar já leva um bom tempo. Por exemplo, recentemente substituí meu blog em Pelican por um site estático pessoal feito com Odin, e isso levou 2 semanas mesmo dedicando apenas 2 a 3 horas por dia. E esse era um projeto mais fácil do que os outros da lista

  • O seu projeto é mais do que um projeto “toy”. Você mesmo é o cliente real e espera que ele funcione direito depois de implantado. Essa expectativa é a fronteira entre toy e ferramenta real. Dá para fazer até um processador de texto em uma hora. Talvez ele só trate uma entrada por vez, seja absurdamente simples e nem tenha botão de sair. Mas mesmo assim isso já seria suficiente como processador de texto “toy”
  • Se você interpretar “X dias” como 24*X horas, a lista fica bem mais plausível
  • Uma das vantagens de toy projects é justamente não ter prazo. Então dá para tocar com calma, sem pressa. Eu mesmo ainda estou lapidando, desde a época da covid, uma linguagem Turing-completa baseada em PEG
  • Esse encurtamento de tempo varia muito conforme até onde você usa bibliotecas de terceiros, o que resolve por conta própria e o quanto realmente se concentra só no núcleo essencial. Se você olhar o GitHub do autor (https://github.com/ssloy?tab=repositories), dá para aprender bastante sobre como manter a escala pequena. E o autor já tem um entendimento profundo do domínio do problema, então consegue programar de forma tão “enxuta” assim. Num tema novo, é difícil implementar desse jeito

• Eu concordo com o conselho de “não use LLM nesses projetos”, mas também acho melhor não levar isso ao extremo. Também acho interessante por que conselhos sobre como receber ajuda de IA soam tão diferentes de pedir ajuda a uma pessoa. Se no fim do blog estivesse escrito “se você tem um amigo muito bom em programação, nunca peça ajuda a ele”, isso soaria estranho. Um amigo especialista entende o contexto e te ajuda a resolver por conta própria. Quase ninguém deve ter tentado pedir à IA algo como “não resolva por mim; me oriente como um amigo especialista”. Claro, talvez ela ainda não consiga fazer isso muito bem, mas em 1 ou 2 anos esse tipo de orientação pode se tornar totalmente natural. Então acho bom desenvolver o hábito de deixar claro que tipo de ajuda você quer. Não precisa partir da ideia fixa de que LLM sempre vai te dar apenas respostas erradas

  • Eu claramente sinto que a IA ainda não é um desenvolvedor especialista
  • Usar LLM como um amigo especialista é justamente a forma como eu mais uso. Para ficar confiável, preciso reformular o prompt ou a própria pergunta de forma menos enviesada. Ultimamente sinto que Claude e ChatGPT estão tendendo demais a concordar comigo
  • (autor) Na verdade, eu de fato recomendaria “não peça ajuda nem a um amigo especialista”. Só quando você estiver realmente travado, talvez seja melhor ler alguma literatura breve sobre o assunto. Eu realmente acredito que a experiência de tentar vários caminhos por conta própria e ir se debatendo até resolver é um elemento essencial para desenvolver criatividade e capacidade de resolver problemas. Esse tempo de confusão é necessário. Mas, no fim, é uma decisão de cada um
  • Eu de fato faço perguntas ao LLM como se fosse um “professor”. Não peço respostas como se ele fosse um estagiário

• Graças a vibe coding com Claude, comecei finalmente um side project divertido depois de muito tempo. Depois de aprender as ferramentas e o processo, em poucas semanas venho criando rapidamente vários apps: um dashboard familiar de calendário/clima, um app de leitura do Bluesky (esconde posts já vistos), um dashboard gamificado de PM da empresa, uma extensão de Chrome que oculta posts do Reddit depois de certo tempo e um app que substitui um plugin de WordPress sem manutenção, entre outros. No começo eu delegava muita coisa ao Claude, como melhorias de UI, mas agora aprendi a ficar satisfeito com 90% de acabamento e focar mais em novas funcionalidades do que em refinamento

  • Fico meio perdido quando o Claude corrige um bug mas não mostra o resultado logo em seguida. Já aconteceu de eu ter de pedir 6 vezes a saída atualizada do resultado para uma única correção. Queria saber se mais alguém passou por isso

• Essa lista é realmente impressionante. Muitos dos projetos que o autor considera fáceis provavelmente seriam bem difíceis para mim. Ainda assim, o efeito motivacional de me fazer querer retomar meus toy projects é real. Só que a conclusão sobre aprendizado com LLM me parece mais sutil. Depende completamente de como você usa. Por exemplo, pedir “implemente este problema para mim” é péssimo para estudar, mas pedir “explique a estrutura de ELF no mais alto nível de abstração, com foco no ‘porquê’” é um acelerador de aprendizado enorme. É verdade que deixar de fazer pesquisa manual toda vez pode ser uma desvantagem, mas se você realmente mantiver uma postura intelectualmente ativa, poder receber perguntas e respostas em estilo socrático a qualquer momento é um efeito gigantesco de aceleração da aprendizagem

  • (autor) Isso é exatamente o que eu quis dizer no texto com “um certo tipo de aprendizado”. Por exemplo, para aprender a estrutura de um binário ELF, você não vai descobrir tudo só na base do chute. É preciso conhecer o histórico e o processo de decisão, então você precisa usar material de referência, seja especificação, documentação ou até LLM. O ponto fundamental é a “aprendizagem construtiva”, fazendo por conta própria; o processo de explorar e trombar nos problemas ao criar você mesmo um formato binário é que te faz entender os motivos e os problemas dos formatos reais, como ELF, além de todo o espaço de design. Para esse tipo de aprendizagem exploratória, eu recomendaria não usar ajuda de LLM. “Se me dessem apenas um notebook, um editor de texto e um compilador e me largassem por 10 anos, até onde eu conseguiria chegar? Em que ponto eu precisaria buscar informação concreta?”

• Os projetos apresentados aqui são realmente boas ideias, mas para mim nenhum deles é interessante. Nessas horas eu começo a me perguntar se eu realmente gostava de programar

  • Parece o oposto de mim. Achei a maioria dos projetos da lista interessante, e vários são coisas que eu gostaria de tentar ou que de fato já tentei. Na verdade, eu também vinha me fazendo essa pergunta até pouco tempo atrás; quando meu bebê nasceu e eu entrei em licença, comecei um projeto de programação “simples” só por diversão. Resolvi tirar todas as dependências e fazer tudo eu mesmo do zero, e isso acabou ficando muito mais complexo do que eu imaginava, mas justamente por isso aquelas poucas horas de programação passaram a ser muito aguardadas. De repente, programar voltou a ficar muito divertido. Talvez você esteja passando por burnout mesmo