Dactilografia para programadores: símbolos, números e a velocidade que importa

Porque é que as WPM em texto são um mau indicador para código

O código difere do texto em três aspetos, e um teste de escrita feito com palavras comuns do inglês não mede nenhum deles.

O primeiro é a mistura de caracteres. Contámos. Nos primeiros dez artigos deste blogue, cerca de 93 em cada 100 caracteres que não são espaços são letras, 5 são pontuação e 2 são algarismos. No código JavaScript da ferramenta de linha de comandos do npm, as letras descem para cerca de 80 e os símbolos sobem para 19. Os módulos json e email do Python ficam entre 80 e 85 letras, e um script de compilação nosso, muito denso, nas 64, com um terço dos caracteres a serem símbolos. Portanto, o código tem cerca de três a sete vezes mais símbolos do que os nossos textos. A maioria fica na fila de cima ou precisa de Shift, o que significa o mindinho direito e os movimentos mais fracos. Os nossos testes de palavras em inglês são feitos com as 1000 palavras mais comuns de um corpus de legendas; o «{» não está entre elas.

O segundo é o ritmo. O texto escreve-se em sequências longas. O código escreve-se em rajadas curtas entre pausas para pensar, percorrer o ficheiro e ler. Os voluntários do estudo de Dhakal et al. de 2018, com 136 milhões de toques, que estavam a copiar frases, tinham em média cerca de 239 ms entre teclas. O dia de um programador está cheio de intervalos de vários segundos, e a velocidade de pico dentro das sequências curtas conta mais do que qualquer média.

O terceiro é o editor. O preenchimento automático, os snippets e os atalhos de teclado fazem com que um programador no ativo escreva uma fração dos caracteres que aparecem no ecrã. Nenhum teste de escrita consegue medir isso, e o nosso não finge que o faz.

A velocidade de escrita é importante para programar?

Menos do que se pensa, e num sítio diferente. Quando alguém pergunta se 60 WPM chegam para ser programador, a resposta é sim, com uma ressalva: se olha para baixo à procura de símbolos e números, não é a 60 WPM que escreve código. Conseguir escrever uma linha sem perder o fio ao pensamento conta mais do que a velocidade pura, e olhar para o teclado é o que o faz perder.

Como escrever símbolos mais depressa, e porque ninguém o ensina

Uma pergunta que aparece vezes sem conta nos fóruns de dactilografia: alguém consegue escrever as letras sem olhar a uma velocidade razoável, mas assim que começa a programar volta a procurar os símbolos, os números e até as maiúsculas, e quer uma forma gradual de os aprender, como aprendeu as letras, algumas teclas de cada vez.

Parte do que torna os símbolos difíceis é o Shift. No código do npm que contámos, cerca de 45% dos toques em símbolos eram caracteres com Shift, como ( ) { } : e $, perto de 9 em cada 100 caracteres que não são espaços, antes de contar uma única maiúscula. Por isso, corrija primeiro o hábito do Shift: carregue no Shift com a mão que não está a escrever o carácter. O ( e o ) ficam no 9 e no 0 da mão direita, por isso levam o Shift esquerdo; ! @ # $ ficam na mão esquerda, por isso levam o Shift direito. A maioria dos autodidatas usa o Shift esquerdo para tudo, e no ! isso obriga o mindinho esquerdo a carregar em duas teclas ao mesmo tempo. Verifique o seu hábito escrevendo uma linha com @ e $ e vendo que mindinho se mexe.

Os símbolos são difíceis de treinar isolados e aborrecidos de treinar de qualquer maneira: as letras vêm com palavras, os parênteses vêm com código, e código aleatório não tem interesse. A nossa resposta é treinar os símbolos em linhas de código reais, uma classe de cada vez.

Uma classe de cada vez

Esta é a ordem que usaríamos, e a ordem da sequência de símbolos que estamos a construir para a página de treino. Até estar disponível, pode fazer o mesmo colando código real no modo personalizado, uma classe de símbolos de cada vez, sem acrescentar a classe seguinte até a atual estar nos 95% de precisão:

• Algarismos. A fila dos números, com os dedos da fila central a esticar-se para cima. Vem primeiro porque é a classe não alfabética mais usada e porque quase toda a gente tem aqui um mau hábito, como o indicador a fazer o 4, o 5, o 6 e o 7. O teste de números é uma verificação rápida.
• Parênteses aos pares. Primeiro ( ), depois [ ], depois { }. Aos pares, porque quase nunca se escreve um sem o outro: nesse código do npm, o ( aparece 6195 vezes e o ) 6194. Treinar o movimento de abrir e fechar como uma unidade é o que o torna rápido. O parêntese de fecho é onde o ritmo da maioria das pessoas se quebra.
• Operadores. = + - * / e os sinais de menor e maior, mais as formas compostas (==, =>, +=, !=). Estão espalhados pela fila dos números e pelas teclas de pontuação da mão direita, e vários precisam de Shift na mesma mão, que é a parte incómoda.
• Aspas e pontuação. ' " ; : , . com o mindinho direito a fazer a maior parte do trabalho. Os pontos e vírgulas e os dois pontos são onde quem programa em linguagens da família do C e em Python mais difere, por isso treine com linhas da linguagem que usa.
• Shell e os estranhos. Barra vertical, barra invertida, til, acento grave, acento circunflexo, e comercial, cardinal, cifrão, arroba e a tecla _. O _ e o acento grave surpreendem a maioria das pessoas; o código em snake_case usa o _ constantemente, e a maioria das pessoas carrega nele com o dedo errado.

Cada classe leva à maioria das pessoas uma ou duas semanas de sessões de dez minutos, por isso a sequência completa demora dois a três meses. É mais lento do que aprender as letras, porque as teclas dos símbolos estão mais longe e os hábitos que está a substituir são mais antigos.

O que corre mal, pelo que vemos nas estatísticas por tecla: as pessoas aprendem o símbolo com o dedo certo e depois voltam atrás sob pressão, porque o movimento antigo é mais rápido durante algumas semanas. As estatísticas mostram-no como uma tecla cujo intervalo varia imenso, rápido quando chega lá corretamente e lento quando não. A solução é ficar nessa classe mais uma semana.

Pares de parênteses e fecho automático

Os editores fecham os parênteses automaticamente, o que levanta uma pergunta justa: porquê aprender a escrever o de fecho?

Por duas razões. O fecho automático é inconsistente: funciona nalguns sítios e noutros não, como num terminal ou numa janela de chat. Quem depende dele hesita sempre para confirmar se funcionou, e a hesitação custa mais do que o toque. E escrever por cima de um parêntese fechado automaticamente (carregar em «)» quando o editor já o inseriu) é em si um toque, por isso escreve o parêntese de fecho de qualquer forma.

Quando cola código no modo personalizado aqui, o texto é dividido pelos espaços em branco, por isso a indentação desaparece e cada elemento passa a ser uma palavra. Isso é ao mesmo tempo uma limitação e uma comodidade: não escreve quatro espaços no início de cada linha de Python, mas também não os treina. Um verdadeiro modo de código que trate a indentação e os pares fechados automaticamente como um editor está na nossa lista, e é mais difícil do que parece.

Velocidade em código e em texto

Não temos resultados suficientes do modo de código para publicar percentis, e preferimos esperar a inventá-los. Nos nossos próprios testes, a velocidade em código num excerto realista tem andado entre metade e dois terços da velocidade da mesma pessoa em texto, e a proporção melhora mais com treino de símbolos do que com treino geral.

O número que se transfere é a precisão. Um programador que escreve texto com 97% de precisão e código com 90% tem um problema com os símbolos, e o mapa de calor das teclas mostra exatamente quais. Um programador com 97% nos dois só precisa de escrever mais código. A nossa metodologia de pontuação explica como a precisão conta os erros corrigidos.

Como referência padrão, o teste de pontuação com os números ligados é, dos nossos modos normais, o mais próximo do código. Não terá chavetas, mas traz a tecla Shift e a fila dos números, e para a maioria das pessoas é aí que está a lacuna.

Escolhas de teclado que ajudam

Os conselhos sobre teclados que os programadores recebem são sobretudo sobre interruptores, e sobretudo ao lado da questão.

O esquema importa mais do que o interruptor. O Dvorak sobe os parênteses retos para a fila dos números e muda de sítio a maior parte da pontuação. O Colemak e o Workman mantêm os parênteses onde o QWERTY os tem, mas ambos põem o ponto e vírgula onde o QWERTY tem o P, o que quem programa em linguagens da família do C vai sentir. O artigo sobre esquemas tem a versão longa.

Uma camada de símbolos vale mais do que um teclado maior. Muitos teclados divididos e compactos permitem pôr parênteses e operadores debaixo dos dedos da fila central, numa camada ativada por uma tecla do polegar. De todas as mudanças de hardware que os programadores descrevem, é a que experimentaríamos primeiro, porque significa nunca mais olhar para baixo à procura de um símbolo.

ISO ou ANSI. Nos teclados ISO (Reino Unido e a maior parte da Europa), a tecla extra ao lado do Shift esquerdo e a tecla Enter alta mudam o sítio da barra invertida e da barra vertical. Se treinar num e trabalhar no outro, o mindinho vai falhar. É por isso que a nossa emulação inclui as duas variantes do Colemak-DH.

Os interruptores quase não contam para a velocidade. Os interruptores lineares, táteis e com clique diferem no toque e no som, e o registo de teclas não sabe em qual carregou. O nosso artigo sobre teclados mecânicos analisa os números.

O som ajuda algumas pessoas a ter feedback: o som de erro diz-lhe que um símbolo saiu errado sem olhar para baixo. Ligue-o enquanto aprende os símbolos.

Uma sessão de dez minutos para programadores

O que faríamos todos os dias durante os dois ou três meses que a sequência de símbolos leva:

• Dois minutos: um teste de palavras de 30 segundos para aquecer, com 97% de precisão.
• Seis minutos: a classe de símbolos atual, em texto personalizado colado do seu próprio código. Pare ao primeiro sinal de voltar ao dedo antigo.
• Dois minutos: um excerto de código na linguagem que mais usa. Veja depois o mapa de calor das teclas, não as WPM.

Nos dias em que não tem dez minutos, escreva o parêntese de fecho à mão. É o hábito mais pequeno deste artigo e normalmente o primeiro a compensar.

Perguntas frequentes

Qual é uma boa velocidade de escrita para programadores?

Qualquer coisa a partir de cerca de 40 WPM serve, se escrever os símbolos e os números sem olhar. A partir daí, o gargalo é pensar, ler e dominar o editor, não a velocidade dos dedos.

Como aprendo a escrever os números sem olhar?

Treine a fila dos números sozinha até a precisão se manter nos 95%, usando o dedo que fica diretamente abaixo de cada algarismo na fila central, e depois misture números em texto normal.