Mecanografía al tacto para programadores: símbolos, números y la velocidad que importa

Por qué las WPM con texto normal reflejan mal la escritura de código

El código se diferencia del texto en tres cosas, y un test de mecanografía hecho con palabras comunes del inglés no mide ninguna de ellas.

La primera es la mezcla de caracteres. Lo contamos. En los diez primeros artículos de este blog, unos 93 de cada 100 caracteres que no son espacios son letras, 5 son signos de puntuación y 2 son dígitos. En el código JavaScript de la herramienta de línea de comandos de npm, las letras bajan a unas 80 y los símbolos suben a 19. Los módulos json y email de Python dan entre 80 y 85 letras, y uno de nuestros scripts de compilación, muy denso, 64, con un tercio de sus caracteres en símbolos. Así que el código tiene aproximadamente entre tres y siete veces más símbolos que nuestros textos. La mayoría están en la fila superior o necesitan Shift, lo que significa el meñique derecho y los desplazamientos más débiles. Nuestros tests de palabras en inglés se construyen con las 1.000 palabras más comunes de un corpus de subtítulos; "{" no está entre ellas.

La segunda es el ritmo. El texto se escribe en tiradas largas. El código se escribe en ráfagas cortas entre pausas para pensar, desplazarse y leer. Los voluntarios del estudio de 2018 de Dhakal y sus colegas sobre 136 millones de pulsaciones, que copiaban frases, tardaban de media unos 239 ms entre tecla y tecla. La jornada de un programador está llena de huecos de varios segundos, y la velocidad dentro de las ráfagas cortas importa más que cualquier media.

La tercera es el editor. El autocompletado, los fragmentos de código y los atajos de teclado hacen que un programador en activo escriba solo una parte de los caracteres que aparecen en pantalla. Ningún test de mecanografía puede medir eso, y el nuestro no finge hacerlo.

¿Es importante la velocidad de escritura para programar?

Menos de lo que se cree, y en otro sitio. Cuando alguien pregunta si 60 WPM bastan para ser programador, la respuesta es que sí, con un matiz: si bajas la vista para buscar símbolos y números, no escribes código a 60 WPM. Poder escribir una línea sin perder el hilo del pensamiento importa más que la velocidad bruta, y bajar la vista al teclado es justo lo que lo rompe.

Cómo escribir símbolos más rápido, y por qué nadie lo enseña

Una pregunta que aparece una y otra vez en los foros de mecanografía: alguien escribe las letras al tacto a una velocidad decente, pero en cuanto empieza a programar vuelve a buscar con la vista los símbolos, los números e incluso las mayúsculas, y quiere una forma gradual de aprenderlos, como aprendió las letras, unas pocas teclas cada vez.

Parte de lo que hace difíciles los símbolos es Shift. En el código de npm que contamos, cerca del 45 % de las pulsaciones de símbolos eran caracteres con Shift como ( ) { } : y $, casi 9 de cada 100 caracteres que no son espacios antes de contar una sola mayúscula. Así que corrige primero el hábito del Shift: pulsa Shift con la mano que no escribe el carácter. ( y ) están en el 9 y el 0 de la mano derecha, así que van con el Shift izquierdo; ! @ # $ están en la mano izquierda, así que van con el Shift derecho. La mayoría de los mecanógrafos autodidactas usan el Shift izquierdo para todo, y con ! eso obliga al meñique izquierdo a pulsar dos teclas a la vez. Comprueba tu propio hábito escribiendo una línea con @ y $ y fijándote en qué meñique se mueve.

Los símbolos son difíciles de practicar aislados y aburridos de practicar de cualquier forma: las letras vienen con palabras, los corchetes vienen con código, y el código aleatorio no tiene interés. Nuestra respuesta es practicar los símbolos con líneas de código reales, un grupo cada vez.

Un grupo cada vez

Este es el orden que seguiríamos, y el orden de la serie de símbolos que estamos preparando para la página de práctica. Mientras no esté disponible, puedes hacer lo mismo pegando código real en el modo personalizado, un grupo de símbolos cada vez, sin añadir el siguiente grupo hasta que el actual llegue al 95 % de precisión:

• Dígitos. La fila de números, con los dedos de la fila guía subiendo a por ellos. Va primero porque es el grupo que no son letras más usado y porque casi todo el mundo tiene aquí algún mal hábito, como hacer el 4, el 5, el 6 y el 7 con el índice. El test de números es una comprobación rápida.
• Los corchetes por parejas. Primero ( ), luego [ ] y luego { }. Por parejas, porque casi nunca escribes uno sin el otro: en ese código de npm, ( aparece 6.195 veces y ) 6.194. Entrenar el movimiento de abrir y cerrar como una sola unidad es lo que lo hace rápido. El corchete de cierre es donde se le rompe el ritmo a la mayoría.
• Operadores. = + - * / y los signos de mayor y menor, más las formas compuestas (==, =>, +=, !=). Están repartidos entre la fila de números y las teclas de puntuación de la mano derecha, y varios necesitan Shift con la misma mano, que es lo incómodo.
• Comillas y puntuación. ' " ; : , . con el meñique derecho haciendo la mayor parte del trabajo. El punto y coma y los dos puntos son donde más se diferencian quienes programan en lenguajes de la familia C y en Python, así que practica con líneas del lenguaje que uses.
• La shell y los raros. La barra vertical, la barra invertida, la virgulilla, el acento grave, el circunflejo, el ampersand, la almohadilla, el dólar, la arroba y la tecla _. El _ y el acento grave sorprenden a la mayoría; el código en snake_case usa _ constantemente, y casi todos lo pulsan con el dedo equivocado.

Cada grupo le lleva a la mayoría una o dos semanas de sesiones de diez minutos, así que la serie completa son dos o tres meses. Es más lento que aprender las letras, porque las teclas de símbolos están más lejos y los hábitos que sustituyes son más antiguos.

Lo que sale mal, según lo que vemos en las estadísticas por tecla: la gente aprende el símbolo con el dedo correcto y luego vuelve al viejo bajo presión, porque durante unas semanas el movimiento antiguo es más rápido. Las estadísticas lo muestran como una tecla cuyo intervalo varía muchísimo: rápido cuando llegas correctamente y lento cuando no. La solución es quedarse en ese grupo una semana más.

Parejas de corchetes y cierre automático

Los editores cierran los corchetes automáticamente, lo que plantea una pregunta razonable: ¿para qué aprender a escribir el de cierre?

Por dos motivos. El cierre automático es irregular: funciona en unos sitios y no en otros, como una terminal o una ventana de chat. Quien depende de él duda cada vez para comprobar si se ha activado, y esa duda cuesta más que la pulsación. Además, escribir encima de un corchete cerrado automáticamente (pulsar ")" cuando el editor ya ha insertado uno) es en sí una pulsación, así que escribes el corchete de cierre de todas formas.

Cuando pegas código en el modo personalizado de este sitio, el texto se divide por los espacios en blanco, así que la sangría desaparece y cada token se convierte en una palabra. Es a la vez una limitación y una comodidad: no escribes cuatro espacios al principio de cada línea de Python, pero tampoco los practicas. Un modo de código de verdad, que trate la sangría y las parejas cerradas automáticamente como lo hace un editor, está en nuestra lista, y es más difícil de lo que parece.

Velocidad con código frente a velocidad con texto

No tenemos suficientes resultados del modo de código para publicar percentiles, y preferimos esperar antes que inventarlos. En nuestras propias pruebas, la velocidad con un fragmento de código realista ha rondado entre la mitad y dos tercios de la velocidad con texto de la misma persona, y la proporción mejora más con práctica de símbolos que con práctica general.

La cifra que sí se traslada es la precisión. Un programador que escribe texto con un 97 % de precisión y código con un 90 % tiene un problema con los símbolos, y el mapa de calor por tecla muestra exactamente con cuáles. Un programador con un 97 % en ambos solo necesita escribir más código. Nuestra metodología de puntuación explica cómo cuenta la precisión los errores corregidos.

Como referencia estándar, el test de puntuación con los números activados es, de nuestros modos habituales, el más parecido al código. No tendrá llaves, pero introduce la tecla Shift y la fila de números, y para la mayoría ahí está la diferencia.

Elecciones de teclado que ayudan

Los consejos sobre teclados que reciben los programadores tratan sobre todo de los interruptores, y casi siempre no vienen al caso.

La distribución importa más que el interruptor. Dvorak sube los corchetes a la fila de números y cambia de sitio la mayoría de los signos de puntuación. Colemak y Workman dejan los corchetes donde los tiene QWERTY, pero ambas mueven el punto y coma a donde QWERTY tiene la P, algo que notarán los programadores de lenguajes de la familia C. El artículo sobre distribuciones tiene la versión larga.

Una capa de símbolos es mejor que un teclado más grande. Muchos teclados partidos y compactos te permiten poner los corchetes y los operadores bajo los dedos de la fila guía en una capa que se activa manteniendo una tecla de pulgar. De todos los cambios de hardware que cuentan los programadores, es el que probaríamos primero, porque significa no volver a bajar la vista para buscar un símbolo.

ISO frente a ANSI. En los teclados ISO (Reino Unido y la mayor parte de Europa), la tecla extra junto al Shift izquierdo y la tecla Enter alta cambian el sitio de la barra invertida y la barra vertical. Si practicas con uno y trabajas con el otro, tu meñique fallará. Por eso nuestra emulación incluye las dos variantes de Colemak-DH.

Los interruptores apenas influyen en la velocidad. Los lineales, táctiles y clicky se diferencian en tacto y sonido, y el registro de pulsaciones no sabe cuál pulsaste. Nuestro artículo sobre teclados mecánicos repasa las cifras.

El sonido ayuda a algunas personas como respuesta: el sonido de error te dice que un símbolo estaba mal sin bajar la vista. Actívalo mientras aprendes los símbolos.

Una sesión de diez minutos para programadores

Lo que haríamos cada día durante los dos o tres meses que dura la serie de símbolos:

• Dos minutos: un test de palabras de 30 segundos como calentamiento, con precisión del 97 %.
• Seis minutos: el grupo de símbolos en el que estés, con texto personalizado pegado de tu propio código. Para a la primera señal de que vuelves al dedo antiguo.
• Dos minutos: un fragmento de código del lenguaje que más uses. Después mira el mapa de calor por tecla, no las WPM.

Los días que no tengas diez minutos, escribe tú el corchete de cierre. Es el hábito más pequeño de este artículo y normalmente el primero que da resultado.

Preguntas frecuentes

¿Qué es una buena velocidad de escritura para un programador?

Cualquier cosa a partir de unas 40 WPM sirve si escribes al tacto los símbolos y los números. Por encima de eso, el cuello de botella es pensar, leer y manejar el editor, no la velocidad de los dedos.

¿Cómo aprendo a escribir los números al tacto?

Practica la fila de números por separado hasta que la precisión se mantenga en el 95 %, usando el dedo que queda justo debajo de cada dígito en la fila guía, y después mezcla números con texto normal.