Bij blind typen voor programmeurs draait het vooral om de toetsen die een gewone typcursus overslaat: cijfers, haakjes, operatoren en de Shift-combinaties eromheen. Een programmeur die gewone tekst typt op 90 WPM kan traag zijn in code, en iemand die op 50 WPM tekst typt kan er juist snel in zijn. We merkten dit toen we tijdens het testen onze eigen broncode in de modus Eigen tekst plakten. De snelheden vielen met een derde of meer terug ten opzichte van de woordenmodus, de heatmap per toets kleurde op de cijferrij en bij de rechterpink, en de traagste bursts zaten op tokens met haakjes erin.
Waarom WPM op gewone tekst een slechte graadmeter is voor code typen
Code verschilt op drie punten van gewone tekst, en een typtest die is opgebouwd uit veelgebruikte Engelse woorden meet geen van drie.
Het eerste is de tekenmix. We hebben geteld. In de eerste tien stukken op deze blog zijn van elke 100 tekens die geen spatie zijn er ongeveer 93 letters, 5 leestekens en 2 cijfers. In de JavaScript-broncode van de opdrachtregeltool van npm zakt het aandeel letters naar ongeveer 80 en stijgen de symbolen naar 19. De modules json en email van Python komen uit op 80 tot 85 letters, en een compact buildscript van ons op 64, met een derde van de tekens als symbool. Code heeft dus ruwweg drie tot zeven keer zoveel symbolen als onze tekst. De meeste staan op de bovenste rij of vragen om Shift, en dat betekent de rechterpink en de zwakkere reikbewegingen. Onze Engelse woordtests zijn gebouwd uit de 1.000 meest voorkomende woorden in een ondertitelcorpus; "{" zit daar niet bij.
Het tweede is het ritme. Tekst typ je in lange stukken. Code typ je in korte uitbarstingen tussen pauzes om na te denken, te scrollen en te lezen. De vrijwilligers in de studie van Dhakal et al. uit 2018 naar 136 miljoen toetsaanslagen, die zinnen overtypten, zaten gemiddeld ongeveer 239 ms tussen twee toetsen. De dag van een programmeur zit vol gaten van een paar seconden, en de burstsnelheid binnen de korte stukken telt meer dan welk gemiddelde ook.
Het derde is de editor. Door autocomplete, snippets en sneltoetsen typt een programmeur aan het werk maar een fractie van de tekens die op het scherm staan. Geen typtest kan dat meten, en de onze doet ook niet alsof.
Is typesnelheid belangrijk bij programmeren?
Minder dan mensen denken, en op een andere plek. Vraagt iemand of 60 WPM genoeg is om programmeur te zijn, dan is het antwoord ja, met een kanttekening: als je naar beneden kijkt voor symbolen en cijfers, typ je code niet op 60 WPM. Een regel kunnen typen zonder je gedachtegang te onderbreken is belangrijker dan pure snelheid, en naar het toetsenbord kijken is precies wat die gedachtegang onderbreekt.
Hoe je symbolen sneller typt, en waarom niemand het je leert
Een vraag die op typforums steeds terugkomt: iemand typt letters blind op een redelijke snelheid, maar zodra hij gaat programmeren zoekt hij weer naar symbolen, cijfers en zelfs hoofdletters, en hij wil een geleidelijke manier om die te leren, zoals hij de letters leerde, een paar toetsen tegelijk.
Een deel van wat symbolen lastig maakt, is Shift. In de npm-broncode die we telden, was ongeveer 45% van de symboolaanslagen een teken met Shift, zoals ( ) { } : en $, bijna 9 op elke 100 tekens die geen spatie zijn, nog voordat je één hoofdletter meetelt. Pak dus eerst de Shift-gewoonte aan: druk Shift in met de hand die het teken niet typt. ( en ) zitten op de 9 en 0 van de rechterhand, dus die gaan met de linker Shift; ! @ # $ zitten aan de linkerhand, dus die gaan met de rechter Shift. De meeste zelflerende typisten gebruiken voor alles de linker Shift, en bij ! moet de linkerpink dan twee toetsen tegelijk indrukken. Controleer je eigen gewoonte door een regel met @ en $ te typen en te kijken welke pink beweegt.
Symbolen zijn lastig los te oefenen en saai om überhaupt te oefenen: letters komen met woorden, haakjes komen met code, en willekeurige code is niet interessant. Ons antwoord is symbolen oefenen op echte regels code, één groep tegelijk.
Eén groep tegelijk
Dit is de volgorde die wij zouden aanhouden, en de volgorde van het symbolentraject dat we bouwen voor de oefenpagina. Tot dat er is, kun je hetzelfde doen door echte code in de modus Eigen tekst te plakken, één groep symbolen tegelijk, en pas aan de volgende groep te beginnen als de huidige op 95% nauwkeurigheid zit:
- Cijfers. De cijferrij, waarbij de vingers van de thuisrij omhoog reiken. Dit komt eerst, omdat het de meest gebruikte groep tekens naast letters is en omdat bijna iedereen hier een slechte gewoonte heeft, zoals de wijsvinger die 4, 5, 6 en 7 doet. De cijfertest is een snelle controle.
- Haakjes als paren. Eerst ( ), dan [ ], dan { }. Als paren, omdat je bijna nooit het ene typt zonder het andere: in die npm-broncode komt ( 6.195 keer voor en ) 6.194 keer. De openen-sluiten-beweging als één geheel trainen is wat het snel maakt. Bij het sluitende haakje breekt bij de meeste mensen het ritme.
- Operatoren. = + - * / en de punthaken, plus de samengestelde vormen (==, =>, +=, !=). Die liggen verspreid over de cijferrij en de leestekentoetsen van de rechterhand, en een aantal vraagt Shift aan dezelfde hand. Dat is het lastige deel.
- Aanhalingstekens en leestekens. ' " ; : , . waarbij de rechterpink het meeste werk doet. Bij puntkomma's en dubbelepunten verschillen typisten in C-achtige talen en Python het meest, dus oefen met regels uit de taal die je gebruikt.
- Shell en de vreemde eenden. Pipe, backslash, tilde, backtick, caret, ampersand, hekje, dollar, apenstaartje en de _-toets. De _ en de backtick verrassen de meeste mensen; code in snake_case gebruikt _ voortdurend, en de meeste typisten raken hem met de verkeerde vinger.
Elke groep kost de meeste mensen een week of twee aan sessies van tien minuten, dus het hele traject duurt twee tot drie maanden. Dat is langzamer dan de letters leren, omdat de symbooltoetsen verder weg liggen en de gewoonten die je vervangt ouder zijn.
Wat er misgaat, zo zien we aan de statistieken per toets: mensen leren het symbool met de juiste vinger en vallen onder druk terug, omdat de oude beweging een paar weken lang sneller is. In de statistieken zie je dat als een toets waarvan de tussentijd wild schommelt: snel als je goed reikt, traag als je dat niet doet. De oplossing is nog een week bij die groep blijven.
Haakjesparen en automatisch sluiten
Editors sluiten haakjes automatisch, en dat roept een terechte vraag op: waarom zou je leren het sluitende haakje te typen?
Twee redenen. Automatisch sluiten werkt niet overal hetzelfde: op sommige plekken wel en op andere niet, zoals in een terminal of een chatvenster. Een typist die erop leunt, aarzelt elke keer om te kijken of het gebeurd is, en die aarzeling kost meer dan de aanslag. En over een automatisch gesloten haakje heen typen (op ")" drukken als de editor er al een heeft ingevoegd) is zelf ook een aanslag, dus je typt het sluitende haakje hoe dan ook.
Als je hier code in de modus Eigen tekst plakt, wordt de tekst op witruimte gesplitst, zodat inspringing verdwijnt en elk token een woord wordt. Dat is een beperking en een gemak tegelijk: je typt geen vier spaties aan het begin van elke Python-regel, maar je oefent ze ook niet. Een echte codemodus die inspringing en automatisch gesloten paren afhandelt zoals een editor dat doet, staat op onze lijst, en die is lastiger dan hij klinkt.
Snelheid in code tegenover gewone tekst
We hebben niet genoeg resultaten in codemodus om percentielen te publiceren, en we wachten liever dan dat we ze verzinnen. In onze eigen runs lag de snelheid op een realistisch stuk code ergens tussen de helft en twee derde van de tekstsnelheid van dezelfde persoon, en die verhouding verbetert meer met symbooloefening dan met algemene oefening.
Het getal dat wél overdraagbaar is, is nauwkeurigheid. Een programmeur die tekst typt met 97% nauwkeurigheid en code met 90% heeft een symboolprobleem, en de heatmap per toets laat precies zien welke symbolen. Een programmeur die op beide 97% haalt, moet gewoon meer code typen. Onze scoringsmethode legt uit hoe nauwkeurigheid verbeterde fouten meetelt.
Als standaardmaatstaf komt de leestekentest met cijfers aan van onze gewone modi het dichtst bij code. Accolades zitten er niet in, maar hij brengt de Shift-toets en de cijferrij in het spel, en voor de meeste mensen zit daar het gat.
Toetsenbordkeuzes die helpen
Het toetsenbordadvies dat programmeurs krijgen, gaat vooral over switches, en schiet daarmee vooral naast het doel.
De indeling telt meer dan de switch. Dvorak verplaatst de haakjes naar de cijferrij en zet de meeste leestekens ergens anders. Colemak en Workman laten de haakjes staan waar QWERTY ze heeft, maar verplaatsen allebei de puntkomma naar de plek van de P op QWERTY, en dat merken programmeurs in C-achtige talen. Het artikel over indelingen heeft de lange versie.
Een symboollaag is beter dan een groter toetsenbord. Veel gesplitste en compacte toetsenborden laten je haakjes en operatoren onder de vingers van de thuisrij zetten, op een laag die je met een duimtoets vasthoudt. Van alle hardwareveranderingen die programmeurs beschrijven, zouden we deze als eerste proberen, omdat je dan nooit meer naar beneden hoeft te kijken voor een symbool.
ISO tegenover ANSI. Op ISO-toetsenborden (Verenigd Koninkrijk en het grootste deel van Europa) veranderen de extra toets naast de linker Shift en de hoge Enter-toets de plek van backslash en pipe. Oefen je op het ene en werk je op het andere, dan mist je pink. Om die reden levert onze emulatie beide varianten van Colemak-DH.
Switches maken voor snelheid nauwelijks uit. Lineaire, tactiele en klikkende switches verschillen in gevoel en geluid, en het logboek van je toetsaanslagen weet niet welke je indrukte. Ons artikel over mechanische toetsenborden loopt de getallen langs.
Geluid helpt sommige mensen met feedback: het foutgeluid vertelt je dat een symbool fout was zonder dat je naar beneden kijkt. Zet het aan terwijl je symbolen leert.
Een sessie van tien minuten voor programmeurs
Wat we dagelijks zouden doen gedurende de twee of drie maanden die het symbolentraject duurt:
- Twee minuten: een woordentest van 30 seconden als opwarmer, nauwkeurigheid op 97%.
- Zes minuten: de huidige symboolgroep, op eigen tekst die je uit je eigen code plakt. Stop bij het eerste teken dat je terugvalt naar de oude vinger.
- Twee minuten: één stuk code in de taal die je het meest gebruikt. Kijk daarna naar de heatmap per toets, niet naar de WPM.
Op dagen dat je geen tien minuten hebt: typ het sluitende haakje zelf. Het is de kleinste gewoonte in dit artikel en meestal de eerste die iets oplevert.
Veelgestelde vragen
Wat is een goede typesnelheid voor programmeurs?
Alles vanaf ongeveer 40 WPM is werkbaar als je symbolen en cijfers blind typt. Daarboven zit het knelpunt in denken, lezen en vaardigheid met je editor, niet in de snelheid van je vingers.
Hoe leer ik cijfers blind te typen?
Oefen de cijferrij apart tot je nauwkeurigheid op 95% blijft, met de vinger die op de thuisrij direct onder elk cijfer ligt, en meng daarna cijfers door gewone tekst.