Digitação por toque para programadores: símbolos, números e a velocidade que importa

Por que o WPM em texto comum é um mau indicador para código

Código difere de texto em três aspectos, e um teste de digitação feito com palavras comuns do inglês não mede nenhum deles.

O primeiro é a mistura de caracteres. Nós contamos. Nos dez primeiros textos deste blog, de cada 100 caracteres que não são espaço, cerca de 93 são letras, 5 são pontuação e 2 são dígitos. No código-fonte JavaScript da ferramenta de linha de comando do npm, as letras caem 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 build nosso, bem denso, em 64, com um terço dos caracteres sendo símbolos. Ou seja, código tem cerca de três a sete vezes mais símbolos que os nossos textos. A maioria fica na fileira de cima ou precisa de Shift, o que significa o mínimo direito e os alcances mais fracos. Nossos testes de palavras em inglês são feitos com as 1.000 palavras mais comuns de um corpus de legendas; "{" não está entre elas.

O segundo é o ritmo. Texto é digitado em sequências longas. Código é digitado em rajadas curtas entre pausas para pensar, rolar a tela e ler. Os voluntários do estudo de Dhakal et al. de 2018, com 136 milhões de toques, que copiavam frases, tiveram média de cerca de 239 ms entre uma tecla e outra. O dia de um programador é cheio de intervalos de vários segundos, e a velocidade dentro das rajadas curtas importa mais do que qualquer média.

O terceiro é o editor. Autocompletar, snippets e atalhos de teclado fazem com que um programador em atividade digite só uma fração dos caracteres que aparecem na tela. Nenhum teste de digitação consegue medir isso, e o nosso não finge que mede.

A velocidade de digitação é importante para programar?

Menos do que as pessoas pensam, e em outro ponto. Quando alguém pergunta se 60 WPM bastam para ser programador, a resposta é sim, com uma ressalva: se você olha para baixo para achar símbolos e números, não é a 60 WPM que você digita código. Conseguir digitar uma linha sem perder o fio do raciocínio importa mais do que a velocidade bruta, e olhar para o teclado é o que corta esse fio.

Como digitar símbolos mais rápido, e por que ninguém ensina isso

Uma pergunta que aparece o tempo todo em fóruns de digitação: a pessoa digita letras por toque numa velocidade razoável, mas, assim que começa a programar, volta a catar símbolos, números e até maiúsculas, e quer um jeito gradual de aprender essas teclas, como aprendeu as letras, poucas de cada vez.

Parte do que torna os símbolos difíceis é o Shift. No código do npm que contamos, cerca de 45% dos toques de símbolos eram caracteres com Shift, como ( ) { } : e $, perto de 9 em cada 100 caracteres que não são espaço, antes de contar uma única maiúscula. Então corrija primeiro o hábito do Shift: aperte o Shift com a mão que não está digitando o caractere. ( e ) ficam no 9 e no 0 da mão direita, então usam o Shift esquerdo; ! @ # $ ficam na mão esquerda, então usam o Shift direito. A maioria de quem aprendeu sozinho segura o Shift esquerdo para tudo, e para o ! isso obriga o mínimo esquerdo a apertar duas teclas ao mesmo tempo. Confira o seu hábito digitando uma linha com @ e $ e observando qual mínimo se mexe.

Símbolos são difíceis de treinar isoladamente e chatos de treinar de qualquer jeito: letras vêm com palavras, colchetes vêm com código, e código aleatório não tem graça. Nossa resposta é treinar símbolos em linhas reais de código, uma classe de cada vez.

Uma classe de cada vez

Esta é a ordem que usaríamos, e a ordem da trilha de símbolos que estamos montando para a página de prática. Até ela sair, você pode fazer o mesmo colando código real no modo personalizado, uma classe de símbolos por vez, sem passar para a próxima classe até a atual estar em 95% de precisão:

• Dígitos. A fileira dos números, com os dedos da fileira inicial subindo até ela. Vem primeiro porque é a classe de não letras mais usada e porque quase todo mundo tem um mau hábito aqui, como o indicador cuidando do 4, 5, 6 e 7. O teste de números é uma checagem rápida.
• Colchetes, chaves e parênteses em pares. ( ) primeiro, depois [ ], depois { }. Em pares, porque você quase nunca digita um sem o outro: naquele código do npm, ( aparece 6.195 vezes e ) 6.194. Treinar o movimento de abrir e fechar como uma unidade é o que o torna rápido. O fechamento é onde o ritmo da maioria das pessoas quebra.
• Operadores. = + - * / e os sinais de menor e maior, além das formas compostas (==, =>, +=, !=). Eles ficam espalhados pela fileira 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 desconfortável.
• Aspas e pontuação. ' " ; : , . com o mínimo direito fazendo a maior parte do trabalho. Ponto e vírgula e dois-pontos são onde quem programa em linguagens da família C e quem programa em Python mais diferem, então pratique com linhas da linguagem que você usa.
• Shell e os esquisitos. Barra vertical, barra invertida, til, crase, circunflexo, e comercial, cerquilha, cifrão, arroba e a tecla _. O _ e a crase surpreendem a maioria; código em snake_case usa _ o tempo todo, e quase todo mundo aperta essa tecla com o dedo errado.

Cada classe leva, para a maioria das pessoas, uma ou duas semanas de sessões de dez minutos, então a trilha inteira dura de dois a três meses. É mais lento que aprender as letras, porque as teclas de símbolos ficam mais longe e os hábitos que você está substituindo são mais antigos.

O que dá errado, pelo que vemos nas estatísticas por tecla: a pessoa aprende o símbolo com o dedo certo e depois volta ao antigo sob pressão, porque o movimento velho é mais rápido por algumas semanas. As estatísticas mostram isso como uma tecla cujo intervalo varia muito, rápido quando você alcança do jeito certo e lento quando não. A solução é ficar mais uma semana nessa classe.

Pares de colchetes e fechamento automático

Os editores fecham colchetes automaticamente, o que levanta uma pergunta justa: por que aprender a digitar o de fechamento?

Dois motivos. O fechamento automático é inconsistente: funciona em alguns lugares e em outros não, como num terminal ou numa janela de chat. Quem depende dele hesita toda vez para conferir se ele funcionou, e a hesitação custa mais que o toque. E digitar por cima de um colchete fechado automaticamente (apertar ")" quando o editor já inseriu um) também é um toque, então você digita o fechamento de qualquer jeito.

Quando você cola código no modo personalizado aqui, o texto é dividido nos espaços em branco, então a indentação some e cada trecho vira uma palavra. Isso é uma limitação e uma conveniência ao mesmo tempo: você não digita quatro espaços no começo de cada linha de Python, e também não os treina. Um modo de código de verdade, que trate a indentação e os pares fechados automaticamente como um editor faz, está na nossa lista, e é mais difícil do que parece.

Velocidade em código versus em texto

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

O número que se transfere é a precisão. Um programador que digita texto com 97% de precisão e código com 90% tem um problema com símbolos, e o mapa de calor por tecla mostra exatamente quais. Um programador com 97% nos dois só precisa digitar mais código. 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 números ativados é o mais próximo de código entre os nossos modos regulares. Não tem chaves, mas traz a tecla Shift e a fileira dos números, e para a maioria das pessoas é aí que está a diferença.

Escolhas de teclado que ajudam

Os conselhos sobre teclado que programadores recebem tratam quase sempre de switches, e quase sempre fogem do ponto.

O layout importa mais que o switch. O Dvorak leva os colchetes para a fileira dos números e muda de lugar a maior parte da pontuação. O Colemak e o Workman mantêm os colchetes onde o QWERTY os coloca, mas os dois levam o ponto e vírgula para onde o QWERTY tem o P, e quem programa em linguagens da família C vai sentir. O artigo sobre layouts tem a versão longa.

Uma camada de símbolos vale mais que um teclado maior. Muitos teclados divididos e compactos permitem colocar colchetes e operadores sob os dedos da fileira inicial, numa camada ativada por uma tecla de polegar. De todas as mudanças de hardware que programadores descrevem, é esta que testaríamos primeiro, porque com ela você nunca mais olha para baixo atrás de um símbolo.

ISO versus ANSI. Nos teclados ISO (Reino Unido e a maior parte da Europa), a tecla extra ao lado do Shift esquerdo e o Enter alto mudam o lugar da barra invertida e da barra vertical. Se você treina num e trabalha no outro, seu mínimo vai errar. É por isso que a nossa emulação traz as duas variantes do Colemak-DH.

Os switches quase não importam para a velocidade. Switches lineares, táteis e clicky diferem na sensação e no som, e o registro de toques não sabe qual você apertou. Nosso artigo sobre teclados mecânicos passa pelos números.

O som ajuda algumas pessoas com o retorno: o som de erro avisa que um símbolo saiu errado sem você olhar para baixo. Ative-o enquanto estiver aprendendo 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 trilha de símbolos leva:

• Dois minutos: um teste de palavras de 30 segundos como aquecimento, com precisão de 97%.
• Seis minutos: a classe de símbolos atual, num texto personalizado colado do seu próprio código. Pare ao primeiro sinal de voltar ao dedo antigo.
• Dois minutos: um trecho de código na linguagem que você mais usa. Olhe o mapa de calor por tecla depois, não o WPM.

Nos dias em que você não tiver dez minutos, digite você mesmo o colchete de fechamento. É o menor hábito deste artigo e normalmente o primeiro a dar retorno.

Perguntas frequentes

Qual é uma boa velocidade de digitação para programadores?

Qualquer coisa a partir de uns 40 WPM é viável se você digita símbolos e números por toque. Acima disso, o gargalo é pensar, ler e dominar o editor, não a velocidade dos dedos.

Como aprender a digitar números sem olhar?

Pratique a fileira dos números sozinha até a precisão se manter em 95%, usando o dedo que fica logo abaixo de cada dígito na fileira inicial, e depois misture números no texto normal.