Scrivere con dieci dita per programmatori: simboli, numeri e la velocità che conta

Perché i WPM sul testo dicono poco su come scrivi codice

Il codice è diverso dal testo in tre modi, e un test di velocità di scrittura costruito con parole inglesi comuni non ne misura nessuno.

Il primo è la composizione dei caratteri. Li abbiamo contati. Nei primi dieci articoli di questo blog, circa 93 caratteri non di spazio su 100 sono lettere, 5 sono punteggiatura e 2 sono cifre. Nel sorgente JavaScript dello strumento da riga di comando di npm le lettere scendono a circa 80 e i simboli salgono a 19. I moduli json ed email di Python arrivano a 80-85 lettere, e un nostro script di build piuttosto denso a 64, con un terzo dei caratteri fatto di simboli. Quindi il codice ha all'incirca da tre a sette volte i simboli del nostro testo. Quasi tutti stanno sulla riga superiore o richiedono Shift, cioè il mignolo destro e gli allungamenti più deboli. I nostri test di parole inglesi sono costruiti con le 1.000 parole più comuni di un corpus di sottotitoli; "{" non è tra queste.

Il secondo è il ritmo. Il testo si scrive in lunghe sequenze. Il codice si scrive a brevi raffiche, tra una pausa e l'altra per pensare, scorrere e leggere. I volontari dello studio di Dhakal e colleghi del 2018 su 136 milioni di battute, che ricopiavano frasi, avevano in media circa 239 ms tra un tasto e l'altro. La giornata di un programmatore è piena di pause di diversi secondi, e la velocità di picco nelle brevi sequenze conta più di qualsiasi media.

Il terzo è l'editor. Completamento automatico, snippet e scorciatoie da tastiera fanno sì che un programmatore al lavoro digiti solo una parte dei caratteri che vede sullo schermo. Nessun test di battitura può misurarlo, e il nostro non fa finta di farlo.

La velocità di battitura conta per programmare?

Meno di quanto si pensi, e in un punto diverso. Quando qualcuno chiede se 60 WPM bastano per fare il programmatore, la risposta è sì, con una riserva: se abbassi lo sguardo per cercare simboli e numeri, 60 WPM non è la velocità con cui scrivi codice. Riuscire a scrivere una riga senza perdere il filo del ragionamento conta più della velocità pura, ed è proprio guardare la tastiera a fartelo perdere.

Come scrivere più veloce i simboli, e perché nessuno lo insegna

Una domanda che torna di continuo sui forum di dattilografia: qualcuno scrive le lettere a dieci dita a una velocità discreta, ma appena inizia a programmare torna a cercare con gli occhi simboli, numeri e persino le maiuscole, e vorrebbe un modo graduale per impararli, come ha fatto con le lettere, pochi tasti alla volta.

Parte della difficoltà dei simboli viene da Shift. Nel sorgente di npm che abbiamo contato, circa il 45% delle battute di simboli erano caratteri con Shift come ( ) { } : e $, quasi 9 ogni 100 caratteri non di spazio, prima ancora di contare una sola maiuscola. Quindi correggi prima l'abitudine con Shift: premi Shift con la mano che non sta scrivendo il carattere. ( e ) stanno sul 9 e sullo 0 della mano destra, quindi vogliono lo Shift sinistro; ! @ # $ stanno sulla mano sinistra, quindi vogliono lo Shift destro. Quasi tutti gli autodidatti tengono lo Shift sinistro per tutto, e per ! questo chiede al mignolo sinistro di premere due tasti insieme. Verifica la tua abitudine scrivendo una riga con @ e $ e guardando quale mignolo si muove.

I simboli sono difficili da esercitare isolati e noiosi da esercitare in generale: le lettere arrivano con le parole, le parentesi arrivano con il codice, e il codice casuale non è interessante. La nostra risposta è esercitare i simboli su righe di codice vero, una classe alla volta.

Una classe alla volta

Questo è l'ordine che useremmo, ed è l'ordine del percorso sui simboli che stiamo costruendo per la pagina di allenamento. Finché non sarà pronto, puoi fare lo stesso incollando codice vero nella modalità Personalizzato, una classe di simboli alla volta, senza aggiungere la classe successiva finché quella attuale non è al 95% di precisione:

• Cifre. La riga dei numeri, con le dita della riga base che si allungano verso l'alto. Viene per prima perché è la classe non alfabetica più usata e perché quasi tutti qui hanno una cattiva abitudine, come l'indice che fa 4, 5, 6 e 7. Il test dei numeri è una verifica rapida.
• Parentesi a coppie. Prima ( ), poi [ ], poi { }. A coppie, perché non ne scrivi quasi mai una senza l'altra: in quel sorgente di npm, ( compare 6.195 volte e ) 6.194. Allenare il movimento apri-chiudi come un'unica unità è ciò che lo rende veloce. La parentesi di chiusura è dove il ritmo di quasi tutti si rompe.
• Operatori. = + - * / e le parentesi angolari, più le forme composte (==, =>, +=, !=). Sono sparsi tra la riga dei numeri e i tasti di punteggiatura della mano destra, e diversi richiedono Shift sulla stessa mano, che è la parte scomoda.
• Virgolette e punteggiatura. ' " ; : , . con il mignolo destro che fa quasi tutto il lavoro. Punto e virgola e due punti sono il punto in cui chi scrive in linguaggi della famiglia del C e chi scrive in Python differiscono di più, quindi allenati su righe del linguaggio che usi.
• Shell e simboli strani. Barra verticale, backslash, tilde, backtick, accento circonflesso, e commerciale, cancelletto, dollaro, chiocciola e il tasto _. Il _ e il backtick sorprendono quasi tutti; il codice in snake_case usa _ di continuo, e quasi tutti lo premono con il dito sbagliato.

A quasi tutti ogni classe richiede una o due settimane di sessioni da dieci minuti, quindi l'intero percorso dura da due a tre mesi. È più lento che imparare le lettere, perché i tasti dei simboli sono più lontani e le abitudini che stai sostituendo sono più vecchie.

Cosa va storto, a giudicare dalle statistiche per tasto: le persone imparano il simbolo con il dito corretto e poi, sotto pressione, tornano indietro, perché per qualche settimana il vecchio movimento è più veloce. Nelle statistiche si vede come un tasto con intervalli molto variabili, veloce quando ti allunghi correttamente e lento quando non lo fai. Il rimedio è restare su quella classe un'altra settimana.

Coppie di parentesi e chiusura automatica

Gli editor chiudono le parentesi da soli, e questo pone una domanda legittima: perché imparare a scrivere quella di chiusura?

Per due motivi. La chiusura automatica non è coerente: scatta in alcuni posti e non in altri, come un terminale o una finestra di chat. Chi ci fa affidamento esita ogni volta per controllare se è scattata, e l'esitazione costa più della battuta. E scrivere sopra una parentesi chiusa in automatico (premere ")" quando l'editor ne ha già inserita una) è comunque una battuta, quindi la parentesi di chiusura la scrivi in ogni caso.

Quando qui incolli codice nella modalità Personalizzato, il testo viene diviso sugli spazi, quindi il rientro sparisce e ogni token diventa una parola. È un limite e una comodità insieme: non digiti quattro spazi all'inizio di ogni riga di Python, ma non li alleni nemmeno. Una vera modalità per il codice che gestisca il rientro e le coppie chiuse in automatico come fa un editor è nella nostra lista, ed è più difficile di quanto sembri.

Velocità sul codice e velocità sul testo

Non abbiamo abbastanza risultati in modalità codice per pubblicare percentili, e preferiamo aspettare piuttosto che inventarli. Nelle nostre prove, la velocità sul codice su uno snippet realistico è stata più o meno tra la metà e i due terzi della velocità della stessa persona sul testo, e il rapporto migliora più con l'esercizio sui simboli che con l'allenamento generico.

Il numero che invece si trasferisce è la precisione. Un programmatore che scrive testo con il 97% di precisione e codice al 90% ha un problema con i simboli, e la mappa di calore dei tasti mostra esattamente quali. Un programmatore al 97% su entrambi deve solo scrivere più codice. La nostra metodologia di calcolo spiega come la precisione conta gli errori corretti.

Come riferimento standard, il test con punteggiatura con i numeri attivi è, tra le nostre modalità normali, quella più vicina al codice. Non avrà parentesi graffe, ma introduce il tasto Shift e la riga dei numeri, e per quasi tutti la lacuna è proprio lì.

Scelte di tastiera che aiutano

I consigli sulle tastiere che ricevono i programmatori riguardano soprattutto gli switch, e quasi sempre non c'entrano.

Il layout conta più dello switch. Dvorak sposta le parentesi sulla riga dei numeri e ricolloca quasi tutta la punteggiatura. Colemak e Workman lasciano le parentesi dove le ha la QWERTY, ma entrambi spostano il punto e virgola dove la QWERTY ha la P, e chi programma in linguaggi della famiglia del C se ne accorgerà. L'articolo sui layout ha la versione lunga.

Un layer per i simboli batte una tastiera più grande. Molte tastiere split e compatte ti permettono di mettere parentesi e operatori sotto le dita della riga base, su un layer attivato tenendo premuto un tasto con il pollice. Di tutti i cambi di hardware che descrivono i programmatori, è quello che proveremmo per primo, perché significa non abbassare mai più lo sguardo per un simbolo.

ISO o ANSI. Sulle tastiere ISO (Regno Unito e quasi tutta l'Europa, Italia compresa), il tasto in più accanto allo Shift sinistro e il tasto Invio alto cambiano la posizione di backslash e barra verticale. Se ti alleni su una e lavori sull'altra, il mignolo sbaglierà. Per questo la nostra emulazione include entrambe le varianti di Colemak-DH.

Gli switch contano pochissimo per la velocità. Lineari, tattili e clicky cambiano nella sensazione e nel suono, e il registro dei tasti non sa quale hai premuto. Il nostro articolo sulle tastiere meccaniche passa in rassegna i numeri.

Il suono aiuta alcune persone come riscontro: il suono di errore ti dice che un simbolo era sbagliato senza dover guardare in basso. Attivalo mentre impari i simboli.

Una sessione da dieci minuti per programmatori

Quello che faremmo ogni giorno per i due o tre mesi del percorso sui simboli:

• Due minuti: un test di parole da 30 secondi come riscaldamento, con precisione al 97%.
• Sei minuti: la classe di simboli attuale, su un testo personalizzato incollato dal tuo codice. Fermati al primo segno di ritorno al vecchio dito.
• Due minuti: uno snippet di codice nel linguaggio che usi di più. Dopo, guarda la mappa di calore dei tasti, non i WPM.

Nei giorni in cui non hai dieci minuti, scrivi da solo la parentesi di chiusura. È l'abitudine più piccola di questo articolo e di solito la prima a ripagare.

Domande frequenti

Qual è una buona velocità di battitura per un programmatore?

Da circa 40 WPM in su si lavora bene, se scrivi simboli e numeri a dieci dita. Oltre quella soglia, il collo di bottiglia è pensare, leggere e saper usare l'editor, non la velocità delle dita.

Come si impara a scrivere i numeri a dieci dita?

Esercita la riga dei numeri da sola finché la precisione non tiene al 95%, usando il dito che sta sotto ciascuna cifra sulla riga base, poi mescola i numeri nel testo normale.