Meus cards de projeto estavam se adiantando aos meus projetos

Os projetos em raioviajante.com não são todos reais do mesmo jeito.

Alguns são software funcionando.

Alguns são experimentos.

Alguns têm código, uma direção e uma enorme quantidade de espaço vazio entre os dois.

Alguns existem principalmente como trabalho de design e a crença teimosa de que um dia vou construir o resto.

Por mim, tudo bem.

Os cards de projeto estavam tendo um pouco mais de dificuldade em admitir isso.

01.Uma frase pode pular muito trabalho

Um card de projeto tem muito pouco espaço.

Ele precisa de um nome, uma descrição curta e contexto suficiente para alguém entender por que aquilo está ali.

Essa compressão torna extremamente fácil escrever sobre o destino em vez do lugar onde estou agora.

Eu sei no que quero que o projeto se transforme. Provavelmente já escrevi planos para ele, abri issues e imaginei a versão em que todas as partes interessantes funcionam.

Então a descrição compacta chega naturalmente:

Uma ferramenta que faz todas essas coisas úteis.

Enquanto isso, o repositório pode conter as duas primeiras dessas coisas, um documento descrevendo a terceira e um marco muito otimista para todo o resto.

A frase não é exatamente uma mentira.

É mais como se o tempo presente tivesse se adiantado à implementação.

Isso começou a me incomodar quando eu revisava os metadados do site principal.

O site deveria mostrar o que eu realmente estou construindo. Em alguns lugares, ele estava fazendo um trabalho melhor mostrando o que eu pretendia ter construído mais tarde.

01.1Tudo quer parecer terminado

Existe uma pressão estranha em torno dos projetos de desenvolvedores para que todo repositório pareça deliberado e completo.

O README precisa de uma descrição confiante.

O card do projeto precisa de uma frase limpa.

A lista de funcionalidades mistura em silêncio o comportamento que funciona com a direção futura, porque cinco itens parecem mais substanciais do que dois.

Até um projeto de aprendizado começa a soar como um anúncio de produto se eu tirar incerteza suficiente da redação.

Entendo a tentação.

“Estou experimentando isto e várias partes importantes ainda não existem” não é o discurso de vendas mais forte possível.

Mas eu não estou vendendo a maioria dessas coisas.

Estou tentando manter um registro útil de trabalhos em estágios bem diferentes.

Fazer um projeto inacabado soar terminado não melhora o projeto. Só deixa o site menos preciso.

Também tira a parte interessante.

O Orbit ser um agendador que já agenda coisas soaria mais impressionante do que o Orbit ser um projeto em que modelei execuções antes de implementar o agendador.

A segunda descrição é verdadeira.

Também é uma explicação muito melhor de por que estou construindo isso.

01.2Deixe as coisas inacabadas parecerem inacabadas

Tenho corrigido os metadados dos projetos com uma regra mais simples.

Se algo é um experimento, chame de experimento.

Se é principalmente um design, não pegue emprestados os verbos da implementação futura.

Se uma parte funciona e outra é planejada, mantenha essas afirmações separadas.

Isso não significa colocar uma etiqueta de aviso em todo repositório inacabado.

Significa deixar o estado atual bastar.

O site principal já descreve os projetos como “coisas que sobreviveram tempo suficiente para merecer um nome”.

Sobreviver tempo suficiente para merecer um nome não é o mesmo que estar pronto.

Isso é útil porque quase nada do que me importo em construir está pronto no sentido permanente, de qualquer forma. O Sweep pode organizar mais tipos de arquivos. O Orbit pode, com o tempo, executar as execuções que modela. A Yanawa tem um problema inteiro em forma de compilador esperando por ela.

O site não precisa fingir o contrário.

Ainda quero que as descrições sejam concisas.

Ainda quero que os projetos soem interessantes quando forem interessantes.

Só não quero que um card atravesse a distância entre intenção e implementação em nome do projeto.

O código pode chegar lá primeiro.