Escreva mais software “inútil”
(ntietz.com)- Software inútil é uma brincadeira que recupera o prazer da computação ao escapar da pressão por resultados práticos, e o Hurl também foi um experimento que começou como uma “piada”
- Quem trabalha com tecnologia costuma passar muito tempo em ambientes onde precisa produzir resultados úteis, o que pode enfraquecer a faísca de diversão que levou a pessoa a começar a programar
- Em projetos lúdicos, você mesmo define testes, issue tracker e critérios de conclusão, e pode parar a qualquer momento quando já tiver aprendido o suficiente ou quando a diversão acabar
- Um motor de xadrez, um armazenamento chave-valor que implementa parte da API do Redis, um utilitário Wake-on-LAN, uma visualização de xadrez e um banco de dados de xadrez foram experimentos para aprender sobre GUI, sistemas, redes e internals de banco de dados
- Tratar o computador com menos seriedade e tentar criar algo que “parece inútil” é uma forma realista de aprender e se divertir ao mesmo tempo
A liberdade que o “inútil” traz
- Perguntaram por que o Hurl foi criado, e a resposta curta é: por uma piada
- A resposta mais longa é que software inútil permite experimentar a alegria e a exploração da computação
- Em geral, quem trabalha com tecnologia está preso à ideia de criar coisas úteis
- Engenheiros de software escrevem código para resolver problemas reais
- Cientistas da computação estudam problemas para produzir resultados novos e práticos
- Redatores técnicos lidam com tecnologia e documentação reais
- Muitas pessoas que começaram a programar sentiram diversão nesse trabalho de algum modo, e essa sensação pode ter influenciado parcialmente a escolha da carreira
- Quando se passa o dia inteiro fazendo coisas úteis, é fácil perder o interesse
- O que precisa ser feito vem com obrigações e pressão
- Toda atividade acaba ligada ao trabalho em si
- Nesse processo, é fácil perder o importante elemento lúdico
- Software inútil é uma forma de escapar dessas obrigações
- Você pode decidir por conta própria o que quer tirar do projeto
- Pode parar a qualquer momento
- Se não quiser escrever testes, pode simplesmente não escrever
- Se não quiser usar um issue tracker, pode descartá-lo
- Se já aprendeu o que queria aprender e a diversão acabou, pode encerrar o projeto
Projetos feitos por diversão
- Um motor de xadrez horrível com UI tinha muitos bugs, mas serviu para entender mais a fundo programação de GUI, desenvolvimento de jogos e como motores de xadrez funcionam
- Um armazenamento chave-valor foi usado para aprender programação de sistemas e escrever código mais eficiente enquanto implementava parte da API do Redis
- Um utilitário Wake-on-LAN foi um projeto para aprender como WOL funciona e como fazer programação de rede em Rust
- Uma visualização de partidas de xadrez permitiu experimentar maneiras de criar arte com código e visualizar um jogo de que a pessoa gosta
- Um banco de dados de xadrez ensinou bastante sobre bitmaps e estruturas internas de bancos de dados
- Também foi criada uma ferramenta baseada em LLM que faz “mansplain” do que um comando executa
- Uma implementação do lado do servidor do protocolo POP3 ficou inacabada, mas foi divertida para aprender o protocolo e imaginar como seria um app baseado em POP3
- Seguir “Crafting Interpreters” em Rust ensinou muito sobre interpretadores e compiladores, e o objetivo não era terminar, mas se divertir
- “Mazes for Programmers” foi levado até mais ou menos a metade em Rust e depois abandonado porque começou a parecer trabalho, sem vontade de continuar
- Pequenos scripts também foram escritos para brincar com ideias e conceitos e fazer experimentos
- O Hurl também é uma forma desse tipo de brincadeira, e mesmo que não seja útil, ainda é possível aprender algo e se divertir no processo de criar
1 comentários
Comentários no Hacker News
Gosto de criar software inútil. Só neste ano fiz o uncolouring book em https://lines.potato.horse, o MeatGPT em https://meat-gpt.sonnet.io, o Medieval Content Farm em https://tidings.potato.horse, o You deserve butter em https://butter.sonnet.io, o Mrr em https://mrr.sonnet.io e o Mrr fisicamente correto em https://mrrr.sonnet.io
Alguns deles, na verdade, são mais como posts de blog elaborados; foram exageradamente construídos porque é mais fácil me expressar brincando com código do que resolvendo problemas reais. Há uma lista mais longa em https://sonnet.io./projects
Meu filho de 8 anos mexe no Scratch todos os dias e eu frequentemente ajudo quando ele tem dúvidas; foi bem divertido fazer, só por diversão, um projeto bobo com até animações inúteis. Graças a isso, “Hurry to love! Hurry to love!” virou bordão aqui em casa
Eu realmente tinha esquecido de muitas coisas ali
Concordo totalmente. Recentemente fui para uma escola de palhaços e percebi que eu vinha ficando obcecado demais em fazer projetos do jeito “certo” ou “bem-feito”
A vida é para ser vivida, e tentar fazer software de um jeito “correto” demais acaba espremendo toda a diversão. Então, ultimamente, tenho tentado escrever código com mais prazer; com isso, também passei a escrever muito mais código, e ele flui com muito mais facilidade. Recentemente, para testar ideias de evolução de schema, criei do zero uma biblioteca de serialização binária no estilo protobuf, e agora estou fazendo um banco de dados local-first baseado em CRDTs. Ontem consegui a primeira sincronização de dados e fiquei muito empolgado. Ao longo dos anos, escrevi muito código para resolver Serious Problems e muito código por impulso, mas, ironicamente, o código de que mais me orgulho é o que fiz por diversão. Projetos divertidos fazem com que eu continue voltando para manter e melhorar; já projetos sérios muitas vezes murchavam e morriam quando eu saía
Em vez de entrar no fluxo do jogo e confiar no processo, as pessoas começam a ler guias para criar o personagem mais forte, maximizar atributos e buscar 100% de conclusão. No fim, desaparece o prazer da exploração e dos encontros fortuitos que tornavam o jogo bom, e você passa o tempo maximizando atributos como se fossem rolagens aleatórias de dados. Outras atividades são parecidas: enquanto você tenta maximizar alguma coisa, seja riqueza ou qualidade de código, somem o senso de maravilha e o “vou só tentar”
https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html
Mas, quando caí na otimização, de repente virou um jogo com uma única resposta certa, e toda a diversão sumiu da noite para o dia. Muitas vezes se aprende mais fazendo algo horrível por arrogância e capricho. A ideia de “quão difícil pode ser?” me levou várias vezes a profundidades que eu não conseguia dar conta, mas, no processo de sair delas, sempre aprendi muito e também encontrei diversão
Qualquer ofício (craft) tem um lado contraintuitivo. Se você simplesmente fizer mais, em geral, no fim acaba melhorando. Escreva contos ruins, faça cerâmicas feias, pinte paisagens tortas
Pode haver um efeito de prática, mas também há uma forte tendência de desistirmos das ideias por conta própria quando não conseguimos enxergar claramente, na cabeça, um produto final digno de nossas expectativas. Para pessoas especialmente analíticas, isso parece uma decisão inteligente para reduzir tempo desperdiçado, mas também é uma forma garantida de não criar nada. Muitos projetos de software “inúteis” continuaram inúteis, mas em alguns encontrei uma utilidade maior durante o processo de criá-los. No fim, isso leva ao clichê de que “você erra 100% dos arremessos que não tenta”, mas dá para entender a ideia
Isso não é só sobre escrever software “inútil”, mas também acaba sendo um argumento para evitar as chamadas boas práticas em projetos pequenos
Criei um gerador de site estático para um catálogo de itens, e o catálogo é simples e não muda com frequência. Fiquei pensando em qual banco de dados usar e, no fim, decidi colocar tudo em um array estático dentro da codebase. Foi uma dependência a menos para me preocupar, e serviu perfeitamente para o meu objetivo
Não sei se isso de fato foi alterado, mas desde então essa sempre virou a primeira pergunta que faço quando alguém diz “precisamos de um banco de dados”
Como eu já trago todos os dados para a memória para rodar algoritmos de grafo, percebi que fazia pouco sentido armazenar dados somente leitura em um banco de dados. Não tenho absolutamente nenhuma intenção de implementar Bellman-Ford em SQL
Aprendi isso programando com um amigo que eu achava ser um péssimo coder
A gente se dava bem e fez muitos projetos divertidos juntos, mas ele realmente parecia não saber o que estava fazendo. Copiava e colava por todo lado, sem arquitetura, sem design, nomes ruins, e metade do tempo nem parecia ter certeza do que o código realmente fazia. Só que funcionava. No fim, percebi que ele tinha feito mais coisas do que eu. Ele não ficava preso a detalhes pequenos e trabalhava muito mais. Não escrevia testes unitários, mas ficava brincando com o resultado como uma criança e testando manualmente o tempo todo. Acabei aceitando essa mentalidade. Eu não encontrava um software de contatos que fizesse o que eu queria, então tentei criar o meu, mas em vez de tentar fazer uma UI sofisticada, usei o django-admin e dei por encerrado. Uso aquele conjunto horrível de formulários há 10 anos, e ele faz o serviço. Na época em que não havia CLI para TOTP, fiz uma em Python e despejei as seeds em TOML em texto puro. Levei 5 anos para adicionar criptografia, porque criar um symlink para o arquivo dentro de um contêiner Veracrypt era suficiente e dava menos trabalho. Dois meses atrás, eu queria um timer em que fazer exercício aumentasse meu orçamento de tempo e jogar videogame o consumisse, então fiz um (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...). Colei um monte de Tailwind cuspido pelo ChatGPT e controlei tudo com HTMX, e isso foi suficiente. Mostrei a amigos, 4 pediram uma conta, e um pediu um teste para médicos em um programa de dependência. Nem formulário de cadastro havia, então fiz hardcoded. Gostaria de dizer ao meu eu mais jovem para parar com a obsessão de fazer as coisas do jeito certo ou só trabalhar em problemas importantes. De qualquer forma, nunca cheguei ao “certo” na vida inteira
Depois que comecei a deixar o nome que a IDE atribui até o projeto provar que é interessante, minha taxa de sucesso parece ter aumentado. Parece estar ligado ao mesmo princípio fundamental
Especialmente ao limpar código dos outros, há uma lógica curiosa nisso. Você xinga e pensa “que diabos essa pessoa estava pensando?”, mas ao mesmo tempo existe o fato de que ela pelo menos colocou a coisa para andar
Mas ele ganhava 100 dólares por hora em um país de salários baixos. Comprava domínio e conteúdo, refazia o software, fazia coisas como otimização para mecanismos de busca e, depois de 3 meses, vendia por 10 vezes o preço pago. Cerca de 7000 dólares de lucro por 3 meses de trabalho não é ruim, e é bem possível que nem fosse em tempo integral
Mas minha conclusão foi esta. Primeiro, elas falham com tanta frequência quanto têm sucesso, é impossível prever qual dos dois vai acontecer, e corrigir depois é mais difícil do que não fazer assim desde o início, então parece uma aposta de valor esperado negativo. Segundo, pessoalmente detesto trabalhar desse jeito. Terceiro, por isso não quero gastar tempo em trabalhos nos quais esse método poderia plausivelmente dar certo. Essa experiência me levou a procurar projetos mais profundos e maiores, em vez de uma sequência de tarefas pequenas e triviais. Em compensação, hoje aceito com muito mais tranquilidade que outras pessoas possam ter preferências diferentes das minhas. Penso mais no método que funciona para mim do que no método correto de criar software
Mesmo assim, funciona. É difícil, mas produtivo, e estou aprendendo muito no processo. Sei como limpar, refinar e tornar algo manutenível e extensível depois, então farei isso quando tiver algo que realmente funcione. Especialmente ao tentar algo novo, essa abordagem já foi bastante produtiva para mim no passado, então eu a apoio totalmente
A Apple já recusou um app meu no passado porque ele era inútil. A equipe de análise de apps me ligou pessoalmente para dizer que o app era inútil e que não seria aprovado na Mac App Store
Cerca de 12 anos depois, aquele app pequeno e inútil, o KeyboardCleanTool, foi usado por milhares de pessoas. É um app gratuito minúsculo que bloqueia todas as entradas do teclado e da Touch Bar, e as pessoas o usaram de formas que eu nunca teria imaginado. Por exemplo, para deixar uma criança pequena bater à vontade no teclado, ou deixar um gato dormir em cima do notebook. O que é útil é realmente subjetivo
Depois de mais umas dez buscas, só entendi quando vi um artigo sobre boas formas de limpar o teclado recomendando o app porque ele permitia travar o teclado. No fim, baixei, e para um app “inútil” ele foi bem útil
Quando eu era criança, minha mãe ligou sem querer nosso Mac IIsi enquanto limpava, e consegui usar isso como pretexto para convencê-la de que precisávamos do protetor de tela After Dark. Logo apareceram torradeiras voando pela tela. Dá nostalgia
Para ver a poeira que poderia riscar a tela durante a limpeza, a tela do MacBook e os monitores precisavam ficar completamente pretos, e o trackpad também precisava ser desativado. A combinação de teclas para desligar o modo de limpeza precisava ser difícil de acionar por acidente e fácil de lembrar, então defini que seria pressionar a tecla Command pelo menos 8 vezes seguidas. As práticas de análise de apps da Apple são sempre irritantes. Não sei por que eles tentam decidir, em nome dos usuários, o que é útil. Isso sem falar nos apps fraudulentos que passam pela análise e sobrevivem por meses na App Store
Gosto de usar software expressivo e divertido. É para aprender e explorar, e foi isso que me atraiu para a programação e continua me mantendo nela
Infelizmente, a necessidade se intromete. Sob a ameaça da fome, é preciso ser produtivo. Eu me importo com as pessoas com quem produzo e me sinto culpado quando não consigo produzir. Isso acaba sugando até a motivação do tempo pessoal. É surpreendente que tanta gente tenha estabilidade e liberdade para se expressar. Tenho inveja, mas também fico feliz, das pessoas que podem ir ao Recurse Center, das que têm inúmeros posts em blogs cheios de projetos pessoais e relatos de aventuras. A maioria provavelmente trabalhou duro para chegar a uma posição em que pudesse construir esse tipo de vida. Eu também quero fazer isso. Mas, para isso, parece que preciso queimar mais da vida na produtividade. Se eu queimar anos suficientes em sacrifício, talvez a sorte me conceda o direito de aproveitar a vida. É engraçado. Depois disso, vou gostar ainda mais de software inútil
Antes eu achava que criar software útil era a marca de um desenvolvedor de software competente, e não gastava tempo com coisas que não fossem obviamente úteis de uma forma fácil de explicar
Essa é uma ótima maneira de transformar software em tarefa chata. Hoje me sinto à vontade criando coisas inúteis, e é divertido. Refaço ideias que já existem de novas formas e não me importo se alguém já fez. Se é só por diversão, dá para fazer do mesmo jeito que se faz cover da música de outra pessoa. Você aprende, se diverte, e isso tem valor por si só. Às vezes também acaba encontrando maneiras de melhorar. Aprendi isso quando comecei a escrever firmware. A pressão de sempre precisar ser útil era grande demais, e tive que baixar o ego e sair da frente. Descobri que escrever código tosco para fazer coisas idiotas é incrivelmente divertido, e virou uma ótima forma de aprender com pouca pressão e experimentar ideias com prazer. Além disso, coisas inúteis às vezes se tornam surpreendentemente úteis. Todas as coisas inúteis que criei nos últimos anos acabaram levando a código útil, insights ou conhecimentos inesperados
Há muito tempo eu organizava um grupo chamado Houston Recreational Computer Programming Group. Era um encontro quase inteiramente dedicado a mostrar projetos de software inúteis e divertidos, e era muito prazeroso
Agora me mudei, e nem sei se a cidade onde moro hoje é grande o suficiente para criar um encontro desses, nem se eu teria energia para organizá-lo de novo. Para mim, a parte boa era que, uma vez por mês, eu precisava criar um projetinho para mostrar caso ninguém levasse nada. Em cerca de 2 anos, isso aconteceu só algumas vezes, mas um deles[1] ficou bem legal e tenho orgulho dele. Também não é totalmente inútil. [1] https://github.com/smcameron/gaseous-giganticus
Acabei de terminar um software inútil há poucos minutos, então este texto veio em ótima hora
CFR Brackets: https://susam.net/cfr.html
Demo: https://susam.net/cfr.html#3
Source: https://github.com/susam/cfr
É uma linguagem de desenho bem pequena que aceita apenas 5 comandos: C(mudar cor), F(avançar), R(girar), [(início de bloco), ](repetir bloco). Os comandos foram levemente inspirados na linguagem de programação Logo, e o minimalismo foi inspirado em P′′. Ao contrário de ambas, porém, ela não é Turing-completa. Não foi pensada para uso prático; fiz por diversão. Pretendo brincar mais desenhando formas interessantes enquanto mantenho o código de entrada o menor possível. “Acredito que é extremamente importante manter a diversão da computação na ciência da computação.” — Alan J. Perlis