A quantidade sempre supera a qualidade

Nathan Bowers me indicou o seguinte entrada do Cool Tools de cinco anos atrás sobre o livro Arte e Medo.

Art & Fear: Observations On the Perils (and Rewards) of Artmaking (Arte e Medo: Observações sobre os perigos (e recompensas) da produção de arte)

Embora eu não esteja pronto para chamar o desenvolvimento de software de “arte” – talvez “artesanato” seja mais apropriado, ou “engenharia”, se o senhor estiver se sentindo generoso -, os paralelos entre alguns dos conselhos oferecidos aqui e minha experiência ao escrever software são profundos.

No dia da abertura, o professor de cerâmica anunciou que estava dividindo a turma em dois grupos. Todos os alunos do lado esquerdo do estúdio, disse ele, seriam avaliados apenas pela quantidade de trabalho que produzissem, e os do lado direito, apenas pela qualidade. Seu procedimento era simples: no último dia de aula, ele trazia sua balança de banheiro e pesava o trabalho do grupo da “quantidade”: cinquenta quilos de vasos eram classificados como “A”, quarenta quilos como “B” e assim por diante. Os que estavam sendo avaliados pela “qualidade”, no entanto, precisavam produzir apenas um vaso – ainda que perfeito – para obter um “A”.

Bem, chegou a hora da classificação e surgiu um fato curioso: os trabalhos de maior qualidade foram todos produzidos pelo grupo que estava sendo avaliado quanto à quantidade. Parece que, enquanto o grupo da “quantidade” estava ocupado produzindo pilhas de trabalho e aprendendo com seus erros, o grupo da “qualidade” estava sentado teorizando sobre a perfeição e, no final, tinha pouco mais a mostrar por seus esforços do que teorias grandiosas e uma pilha de argila morta.

Onde já ouvi isso antes?

  1. Pare de teorizar.
  2. Escreva muitos softwares.
  3. Aprenda com seus erros.

A quantidade sempre supera a qualidade. É por isso que o único conselho que sempre dou aos aspirantes a blogueiros é escolher um cronograma e cumpri-lo. Esse é o único conselho que importa, porque até que o senhor se comprometa mentalmente a fazer isso repetidamente, não vai melhorar. O senhor não pode.

Quando se trata de software, a mesma regra se aplica. Se o senhor não estiver criando, não estará aprendendo. Em vez de se preocupar se o senhor está criando a coisa certa, simplesmente crie. E se esse não funcionar, continue construindo até que o senhor consiga um que o faça.