Blindskrift for programmører handler mest om de taster, et almindeligt kursus i maskinskrivning springer over: cifre, parenteser, operatorer og Shift-kombinationerne omkring dem. En programmør, der skriver prosa med 90 WPM, kan være langsom til kode, og en, der skriver prosa med 50 WPM, kan være hurtig til det. Vi lagde mærke til det, da vi under testningen indsatte vores egne kildefiler i tilstanden Egen tekst. Hastighederne faldt med en tredjedel eller mere i forhold til tilstanden Ord, varmekortet pr. tast lyste op på talrækken og højre lillefinger, og de langsomste spurter var på tokens med parenteser i.
Hvorfor WPM på prosa er et dårligt mål for at skrive kode
Kode adskiller sig fra tekst på tre måder, og en skrivetest bygget af almindelige engelske ord måler ingen af dem.
Den første er tegnfordelingen. Vi talte efter. I de første ti indlæg på denne blog er omkring 93 ud af hver 100 tegn, der ikke er mellemrum, bogstaver, 5 er tegnsætning og 2 er cifre. I JavaScript-kildekoden til npm's kommandolinjeværktøj falder bogstaverne til omkring 80, og symbolerne stiger til 19. Pythons json- og email-moduler ender på 80 til 85 bogstaver og et af vores egne tætte build-scripts på 64, hvor en tredjedel af tegnene er symboler. Kode har altså cirka tre til syv gange så mange symboler som vores prosa. De fleste af dem ligger i øverste række eller kræver Shift, hvilket betyder højre lillefinger og de svagere strækninger. Vores engelske ordtests er bygget af de 1.000 mest almindelige ord i et korpus af undertekster; "{" er ikke blandt dem.
Den anden er rytmen. Prosa skrives i lange forløb. Kode skrives i korte spurter mellem pauser til at tænke, scrolle og læse. De frivillige i Dhakal m.fl.'s studie fra 2018 af 136 millioner tastetryk, som skrev sætninger af, havde i gennemsnit omkring 239 ms mellem tasterne. En programmørs dag er fuld af huller på flere sekunder, og spurthastigheden i de korte forløb betyder mere end noget gennemsnit.
Den tredje er editoren. Autofuldførelse, snippets og tastaturgenveje betyder, at en arbejdende programmør kun skriver en brøkdel af tegnene på skærmen. Det kan ingen skrivetest måle, og vores lader ikke som om.
Er skrivehastighed vigtig for programmering?
Mindre, end folk tror, og et andet sted. Når nogen spørger, om 60 WPM er nok til at være programmør, er svaret ja, med et forbehold: Hvis du kigger ned efter symboler og tal, er 60 WPM ikke den hastighed, du skriver kode med. At kunne skrive en linje uden at miste tankegangen betyder mere end rå hastighed, og det er blikket ned på tastaturet, der får dig til at miste den.
Sådan skriver du symboler hurtigere, og hvorfor ingen lærer dig det
Et spørgsmål, der dukker op igen og igen i fora om maskinskrivning: Nogen kan skrive bogstaver blindt med en anstændig hastighed, men i samme øjeblik de begynder at kode, er de tilbage ved at lede efter symboler, tal og endda store bogstaver, og de vil gerne have en gradvis måde at lære dem på, sådan som de lærte bogstaverne, et par taster ad gangen.
En del af det, der gør symboler svære, er Shift. I den npm-kildekode, vi talte i, var omkring 45 % af tastetrykkene for symboler Shift-tegn som ( ) { } : og $, tæt på 9 ud af hver 100 tegn, der ikke er mellemrum, før man tæller et eneste stort bogstav. Så ret først Shift-vanen: Tryk på Shift med den hånd, der ikke skriver tegnet. ( og ) ligger på højre hånds 9 og 0, så de tager venstre Shift; ! @ # $ ligger på venstre hånd, så de tager højre Shift. De fleste selvlærte skrivere holder venstre Shift til alt, og ved ! kræver det, at venstre lillefinger trykker på to taster på én gang. Tjek din egen vane ved at skrive en linje med @ og $ i og se, hvilken lillefinger der bevæger sig.
Symboler er svære at træne isoleret og kedelige at træne overhovedet: Bogstaver kommer med ord, parenteser kommer med kode, og tilfældig kode er ikke interessant. Vores svar er at træne symboler på rigtige kodelinjer, én klasse ad gangen.
Én klasse ad gangen
Det her er den rækkefølge, vi ville bruge, og rækkefølgen i det symbolforløb, vi er ved at bygge til øvelsessiden. Indtil det er klar, kan du gøre det samme ved at indsætte rigtig kode i tilstanden Egen tekst, én symbolklasse ad gangen, og ikke tage den næste klasse med, før den nuværende ligger på 95 % nøjagtighed:
- Cifre. Talrækken, hvor grundrækkens fingre rækker op. Den kommer først, fordi det er den mest brugte klasse uden bogstaver, og fordi næsten alle har en dårlig vane her, for eksempel at pegefingeren tager 4, 5, 6 og 7. Taltesten er et hurtigt tjek.
- Parenteser i par. Først ( ), så [ ], så { }. I par, fordi du næsten aldrig skriver den ene uden den anden: I den npm-kildekode optræder ( 6.195 gange og ) 6.194. Det er træningen af åbne-lukke-bevægelsen som én enhed, der gør den hurtig. Den lukkende parentes er der, hvor de flestes rytme brydes.
- Operatorer. = + - * / og vinkelparenteserne plus de sammensatte former (==, =>, +=, !=). De er spredt over talrækken og tegnsætningstasterne i højre side, og flere af dem kræver Shift med samme hånd, hvilket er det akavede.
- Anførselstegn og tegnsætning. ' " ; : , . hvor højre lillefinger gør det meste af arbejdet. Semikolon og kolon er der, hvor skrivere i C-familien og i Python adskiller sig mest, så øv dig på linjer fra det sprog, du bruger.
- Shell og de sære. Lodret streg, backslash, tilde, backtick, cirkumfleks, og-tegn, havelåge, dollar, snabel-a og _-tasten. _ og backtick overrasker de fleste; snake_case-kode bruger _ hele tiden, og de fleste rammer den med den forkerte finger.
Hver klasse tager for de flestes vedkommende en uge eller to med sessioner på ti minutter, så hele forløbet tager to til tre måneder. Det er langsommere end at lære bogstaverne, fordi symboltasterne ligger længere væk, og de vaner, du erstatter, er ældre.
Hvad der går galt, ud fra statistikken pr. tast: Folk lærer symbolet med den rigtige finger og falder så tilbage under pres, fordi den gamle bevægelse er hurtigere i et par uger. Statistikken viser det som en tast, hvis interval svinger voldsomt, hurtig når du rækker rigtigt, og langsom når du ikke gør. Løsningen er at blive ved den klasse en uge mere.
Parentespar og automatisk lukning
Editorer lukker parenteser automatisk, hvilket rejser et rimeligt spørgsmål: Hvorfor lære at skrive den lukkende?
Af to grunde. Automatisk lukning er inkonsekvent: Den slår til nogle steder og ikke andre, for eksempel i en terminal eller et chatvindue. En skriver, der regner med den, tøver hver gang for at tjekke, om den slog til, og tøven koster mere end tastetrykket. Og at skrive hen over en automatisk lukket parentes (trykke på ")", når editoren allerede har indsat en) er i sig selv et tastetryk, så du skriver den lukkende parentes under alle omstændigheder.
Når du indsætter kode i tilstanden Egen tekst her, bliver teksten delt ved mellemrum og linjeskift, så indrykning forsvinder, og hvert token bliver et ord. Det er en begrænsning og en bekvemmelighed på én gang: Du skriver ikke fire mellemrum i starten af hver Python-linje, men du øver dem heller ikke. En ordentlig kodetilstand, der håndterer indrykning og automatisk lukkede par, som en editor gør, er på vores liste, og den er sværere, end den lyder.
Hastighed på kode kontra prosa
Vi har ikke nok resultater i kodetilstand til at offentliggøre percentiler, og vi vil hellere vente end at opfinde dem. I vores egne runder har hastigheden på kode på et realistisk kodestykke ligget et sted mellem halvdelen og to tredjedele af den samme persons hastighed på prosa, og forholdet forbedres mere med symboltræning end med almindelig træning.
Det tal, der faktisk kan overføres, er nøjagtigheden. En programmør, der skriver prosa med 97 % nøjagtighed og kode med 90 %, har et symbolproblem, og varmekortet pr. tast viser præcis hvilke symboler. En programmør med 97 % på begge skal bare skrive mere kode. Vores beskrivelse af pointberegningen forklarer, hvordan nøjagtigheden tæller rettede fejl.
Som standardbenchmark er tegnsætningstesten med tal slået til den af vores almindelige tilstande, der ligger tættest på kode. Den har ikke krøllede parenteser, men den tager Shift-tasten og talrækken med, og for de fleste er det dér, hullet er.
Tastaturvalg, der hjælper
De tastaturråd, programmører får, handler mest om kontakter og er mest ved siden af.
Layoutet betyder mere end kontakten. Dvorak flytter parenteserne op i talrækken og flytter det meste tegnsætning. Colemak og Workman beholder parenteserne, hvor QWERTY har dem, men begge flytter semikolon derhen, hvor QWERTY har P, hvilket programmører i C-familien vil mærke. Artiklen om layouts har den lange version.
Et symbollag slår et større tastatur. Mange delte og kompakte tastaturer lader dig lægge parenteser og operatorer under grundrækkens fingre på et lag, der holdes med en tommelfingertast. Af alle de hardwareændringer, programmører beskriver, er det den, vi ville prøve først, fordi det betyder, at du aldrig mere skal kigge ned efter et symbol.
ISO kontra ANSI. På ISO-tastaturer (Storbritannien og det meste af Europa) ændrer den ekstra tast ved siden af venstre Shift og den høje Enter-tast, hvor backslash og lodret streg ligger. Hvis du øver dig på det ene og arbejder på det andet, vil din lillefinger ramme forkert. Vores emulering har begge varianter af Colemak-DH af den grund.
Kontakter betyder knap nok noget for hastigheden. Lineære, taktile og klikkende kontakter er forskellige i følelse og lyd, og tasteloggen ved ikke, hvilken du trykkede på. Vores artikel om mekaniske tastaturer gennemgår tallene.
Lyd hjælper nogle med feedback: Fejllyden fortæller dig, at et symbol var forkert, uden at du kigger ned. Slå den til, mens du lærer symboler.
En session på ti minutter for programmører
Det her ville vi gøre dagligt i de to eller tre måneder, symbolforløbet tager:
- To minutter: en ordtest på 30 sekunder som opvarmning, nøjagtighed på 97 %.
- Seks minutter: den nuværende symbolklasse, på egen tekst indsat fra din egen kode. Stop ved første tegn på, at du falder tilbage til den gamle finger.
- To minutter: et kodestykke i det sprog, du bruger mest. Se bagefter på varmekortet pr. tast, ikke på WPM.
På de dage, hvor du ikke har ti minutter, så skriv selv den lukkende parentes. Det er den mindste vane i denne artikel og som regel den første, der betaler sig.
Ofte stillede spørgsmål
Hvad er en god skrivehastighed for programmører?
Alt fra omkring 40 WPM og op er brugbart, hvis du skriver symboler og tal blindt. Derover er flaskehalsen tænkning, læsning og færdighed i editoren, ikke fingrenes hastighed.
Hvordan lærer jeg at skrive tal blindt?
Øv talrækken for sig selv, indtil nøjagtigheden holder på 95 %, med den finger, der ligger lige under hvert ciffer i grundrækken, og bland derefter tal ind i almindelig tekst.