A mecanografía para programadores trata sobre todo das teclas que un curso normal de mecanografía se salta: díxitos, parénteses e chaves, operadores e as combinacións con Shift que os rodean. Un programador que escribe texto a 90 WPM pode ser lento escribindo código, e alguén que escribe texto a 50 WPM pode ser rápido con el. Démonos conta diso mentres pegabamos os nosos propios ficheiros de código no modo personalizado durante as probas. As velocidades baixaron un terzo ou máis en comparación co modo palabras, o mapa de calor por tecla acendeuse na fila dos números e no maimiño dereito, e as ráfagas máis lentas foron en elementos que levaban parénteses ou chaves.
Por que as WPM con texto son un mal indicador para escribir código
O código diferénciase do texto en tres cousas, e unha proba de mecanografía feita con palabras comúns do inglés non mide ningunha delas.
A primeira é a mestura de caracteres. Contámola. Nos dez primeiros artigos deste blog, uns 93 de cada 100 caracteres que non son espazos son letras, 5 son signos de puntuación e 2 son díxitos. No código fonte en JavaScript da ferramenta de liña de ordes de npm, as letras baixan a unhas 80 e os símbolos soben a 19. Os módulos json e email de Python dan entre 80 e 85 letras, e un denso script de compilación noso dá 64, cun terzo dos seus caracteres símbolos. Así que o código ten aproximadamente de tres a sete veces máis símbolos ca os nosos textos. A maioría están na fila superior ou necesitan Shift, o que implica o maimiño dereito e os estiróns máis débiles. As nosas probas de palabras en inglés están feitas coas 1.000 palabras máis comúns dun corpus de subtítulos; «{» non está entre elas.
A segunda é o ritmo. O texto escríbese en series longas. O código escríbese en ráfagas curtas entre pausas para pensar, desprazarse e ler. Os voluntarios do estudo de Dhakal et al. de 2018 sobre 136 millóns de pulsacións, que copiaban frases, fixeron unha media duns 239 ms entre teclas. A xornada dun programador está chea de ocos de varios segundos, e a velocidade de ráfaga dentro das series curtas importa máis ca calquera media.
A terceira é o editor. O autocompletado, os fragmentos de código e os atallos de teclado fan que un programador en activo escriba unha fracción dos caracteres que hai na pantalla. Ningunha proba de mecanografía pode medir iso, e a nosa non o finxe.
É importante a velocidade de escritura para programar?
Menos do que a xente pensa, e noutro sitio. Cando alguén pregunta se 60 WPM abondan para ser programador, a resposta é que si, cun matiz: se miras para abaixo para buscar símbolos e números, non escribes código a 60 WPM. Poder escribir unha liña sen perder o fío do pensamento importa máis ca a velocidade bruta, e mirar o teclado é o que o fai perder.
Como escribir símbolos máis rápido, e por que ninguén o ensina
Unha pregunta que aparece unha e outra vez nos foros de mecanografía: alguén escribe as letras sen mirar a unha velocidade decente, pero en canto se pon a programar volve buscar os símbolos, os números e ata as maiúsculas, e quere unha forma gradual de aprendelos, igual que aprendeu as letras, unhas poucas teclas de cada vez.
Parte do que fai difíciles os símbolos é o Shift. No código de npm que contamos, arredor do 45 % das pulsacións de símbolos eran caracteres con Shift como ( ) { } : e $, preto de 9 de cada 100 caracteres que non son espazos, antes de contar unha soa maiúscula. Así que corrixe primeiro o hábito do Shift: preme Shift coa man que non escribe o carácter. ( e ) están no 9 e no 0 da man dereita, así que levan o Shift esquerdo; ! @ # $ están na man esquerda, así que levan o Shift dereito. A maioría das persoas autodidactas manteñen o Shift esquerdo para todo, e para ! iso obriga o maimiño esquerdo a premer dúas teclas á vez. Comproba o teu propio hábito escribindo unha liña con @ e $ e fixándote en que maimiño se move.
Os símbolos son difíciles de practicar illados e aburridos de practicar en xeral: as letras veñen coas palabras, as parénteses veñen co código, e o código aleatorio non ten interese. A nosa resposta é practicar os símbolos con liñas de código reais, unha clase de cada vez.
Unha clase de cada vez
Esta é a orde que seguiriamos, e a orde do itinerario de símbolos que estamos preparando para a páxina de práctica. Mentres non estea publicado, podes facer o mesmo pegando código real no modo personalizado, unha clase de símbolos de cada vez, e sen engadir a seguinte clase ata que a actual estea nun 95 % de precisión:
- Díxitos. A fila dos números, cos dedos da fila guía estirándose cara arriba. Vai primeiro porque é a clase de non letras máis usada e porque case todo o mundo ten aquí un mal hábito, como que o índice prema 4, 5, 6 e 7. A proba de números é unha comprobación rápida.
- Parénteses e chaves como pares. Primeiro ( ), despois [ ] e despois { }. Por pares, porque case nunca escribes un sen o outro: nese código de npm, ( aparece 6.195 veces e ) 6.194. Adestrar o movemento de abrir e pechar como unha unidade é o que o fai rápido. O de peche é onde se lle rompe o ritmo á maioría da xente.
- Operadores. = + - * / e os signos de menor e maior, máis as formas compostas (==, =>, +=, !=). Están repartidos pola fila dos números e polas teclas de puntuación da man dereita, e varios necesitan Shift na mesma man, que é a parte incómoda.
- Comiñas e puntuación. ' " ; : , . co maimiño dereito facendo a maior parte do traballo. O punto e coma e os dous puntos son onde máis se diferencian quen escribe en linguaxes da familia C e quen escribe en Python, así que practica con liñas da linguaxe que usas.
- Shell e os raros. Barra vertical, barra invertida, til, acento grave, circunflexo, «e» comercial, cancelo, dólar, arroba e a tecla _. O _ e o acento grave sorprenden á maioría; o código en snake_case usa _ constantemente, e a maioría de mecanógrafos prémeno co dedo equivocado.
Cada clase lévalle á maioría da xente unha ou dúas semanas de sesións de dez minutos, así que o itinerario completo son dous ou tres meses. É máis lento ca aprender as letras, porque as teclas de símbolos están máis lonxe e os hábitos que substitúes son máis vellos.
O que sae mal, segundo vemos nas estatísticas por tecla: a xente aprende o símbolo co dedo correcto e despois volve ao vello cando ten présa, porque o movemento antigo é máis rápido durante unhas semanas. As estatísticas móstrano como unha tecla cun intervalo moi variable, rápido cando chegas ben e lento cando non. A solución é quedar nesa clase outra semana máis.
Pares de parénteses e peche automático
Os editores pechan automaticamente as parénteses, o que suscita unha pregunta xusta: por que aprender a escribir a de peche?
Por dous motivos. O peche automático é inconsistente: actúa nalgúns sitios e noutros non, como nun terminal ou nunha xanela de chat. Quen depende del dubida cada vez para comprobar se actuou, e esa dúbida custa máis ca a pulsación. E escribir por riba dunha paréntese pechada automaticamente (premer «)» cando o editor xa a inseriu) é en si mesmo unha pulsación, así que escribes a paréntese de peche de todos os xeitos.
Cando pegas código no modo personalizado deste sitio, o texto divídese polos espazos en branco, así que a sangría desaparece e cada elemento convértese nunha palabra. Iso é á vez unha limitación e unha comodidade: non escribes catro espazos ao comezo de cada liña de Python, pero tampouco os practicas. Un modo de código de verdade, que trate a sangría e os pares pechados automaticamente como o fai un editor, está na nosa lista, e é máis difícil do que parece.
Velocidade con código fronte a velocidade con texto
Non temos resultados dabondo do modo de código para publicar percentís, e preferimos esperar antes ca inventalos. Nas nosas propias probas, a velocidade con código nun fragmento realista estivo entre a metade e dous terzos da velocidade con texto da mesma persoa, e a proporción mellora máis coa práctica de símbolos ca coa práctica xeral.
O número que si se traslada é a precisión. Un programador que escribe texto cun 97 % de precisión e código cun 90 % ten un problema cos símbolos, e o mapa de calor por tecla mostra exactamente con cales. Un programador cun 97 % nos dous só necesita escribir máis código. A nosa metodoloxía de puntuación explica como conta a precisión os erros corrixidos.
Como referencia estándar, a proba de puntuación cos números activados é o máis parecido ao código entre os nosos modos habituais. Non terá chaves, pero introduce a tecla Shift e a fila dos números, e para a maioría da xente esa é a carencia.
Opcións de teclado que axudan
Os consellos sobre teclados que reciben os programadores tratan sobre todo dos interruptores, e a maior parte non veñen ao caso.
A distribución importa máis ca o interruptor. Dvorak sobe as parénteses e chaves á fila dos números e cambia de sitio a maior parte da puntuación. Colemak e Workman manteñen as parénteses onde as ten QWERTY, pero as dúas moven o punto e coma ao sitio onde QWERTY ten o P, algo que notarán quen programa en linguaxes da familia C. O artigo sobre distribucións ten a versión longa.
Unha capa de símbolos é mellor ca un teclado máis grande. Moitos teclados partidos e compactos permiten poñer parénteses e operadores baixo os dedos da fila guía nunha capa que se activa mantendo unha tecla co polgar. De todos os cambios de hardware que describen os programadores, este é o que probariamos primeiro, porque significa que nunca máis miras para abaixo para buscar un símbolo.
ISO fronte a ANSI. Nos teclados ISO (Reino Unido e a maior parte de Europa), a tecla extra xunto ao Shift esquerdo e a tecla Intro alta cambian o sitio da barra invertida e da barra vertical. Se practicas nun e traballas no outro, o maimiño fallará. Por iso a nosa emulación inclúe as dúas variantes de Colemak-DH.
Os interruptores apenas importan para a velocidade. Os interruptores lineais, táctiles e de clic diferéncianse no tacto e no son, e o rexistro de pulsacións non sabe cal premiches. O noso artigo sobre teclados mecánicos repasa os números.
O son axuda a algunhas persoas como resposta: o son de erro avísate de que un símbolo estaba mal sen que teñas que mirar para abaixo. Actívao mentres aprendes os símbolos.
Unha sesión de dez minutos para programadores
O que fariamos cada día durante os dous ou tres meses que leva o itinerario de símbolos:
- Dous minutos: unha proba de palabras de 30 segundos para quecer, cun 97 % de precisión.
- Seis minutos: a clase de símbolos actual, con texto personalizado pegado do teu propio código. Para ao primeiro sinal de volver ao dedo antigo.
- Dous minutos: un fragmento de código na linguaxe que máis usas. Despois mira o mapa de calor por tecla, non as WPM.
Os días que non teñas dez minutos, escribe ti mesmo a paréntese de peche. É o hábito máis pequeno deste artigo e normalmente o primeiro que dá froito.
Preguntas frecuentes
Que é unha boa velocidade de escritura para programadores?
Calquera cousa a partir dunhas 40 WPM serve se escribes sen mirar os símbolos e os números. Por riba diso, o pescozo de botella é pensar, ler e dominar o editor, non a velocidade dos dedos.
Como aprendo a escribir os números sen mirar?
Practica a fila dos números por separado ata que a precisión se manteña nun 95 %, usando o dedo que está xusto debaixo de cada díxito na fila guía, e despois mestura números con texto normal.