Ti-fingersystemet for programmører: hvorfor kodehastighed ikke kun er WPM
En hurtig skriver kan stadig være en langsom koder
Det er en almindelig overraskelse: Én, der tester 90+ WPM på almindelige engelske ord, sætter sig til at skrive kode og føler sig ikke hurtigere end en skriver på 50 WPM. Årsagen er enkel — en standard skrivetest består næsten udelukkende af små bogstaver og mellemrum. Kode gør ikke. En typisk linje JavaScript eller Python er pakket med tegn, som en ordbaseret test næsten ikke rører: parenteser, firkantede og tuborgklammer, understregninger, anførselstegn, lighedstegn, kolon — plus konstante skift mellem små og store bogstaver til camelCase og rækning efter talrækken til symboler.
Hver eneste af dem er en lille forsinkelse. Gang det med tusindvis af linjer om ugen, og det summerer sig til et reelt hul mellem »hurtig skriver« og »hurtig koder«.
De tegn, der faktisk bremser dig
- Parenteser og klammer —
()[]{}— ligger i kanten af talrækken og kræver på et dansk tastatur AltGr til de firkantede og tuborgklammerne — akavet for lillefingre, der sjældent kommer dertil i almindelig prosa. - Symboler med Shift —
_=+:"— kræver en holdt modifikatortast, hvilket er en anden bevægelse end at skrive et almindeligt bogstav. - camelCase og snake_case — konstante mikroskift mellem store og små bogstaver (eller rækning efter understregningen), som almindelige ordtests aldrig træner.
- Indrykning — to eller fire indledende mellemrum pr. linje, skrevet korrekt og ensartet, hvilket et flydende afsnit med ord aldrig beder dig om.
Ingen af disse er svære enkeltvis. Det, der mangler, er gentagelse — de fleste har simpelthen aldrig trænet dem, som de trænede alfabetet i skolen.
Hvorfor en almindelig skrivetest ikke løser det
Ordbaserede skrivetests trækker fra en bank af almindelige ord — nyttigt til rå hastighed og nøjagtighed, men ordbankerne er pr. design mest almindelig tekst med små bogstaver. Du kunne maksimere dit WPM på en og stadig fumle hver gang, du skriver !== eller rækker efter en lukkende tuborgklamme tre linjer nede. Færdigheden er virkelig en anden, og den kræver sin egen øvelse.
At øve kodeskrivning specifikt
Det er netop det hul, Code Typing-spillet er bygget til — det trækker rigtige JavaScript- og Python-linjer, ikke tilfældige ord, og det skelner mellem store og små bogstaver og er følsomt over for mellemrum, ligesom en rigtig editor. Nogle måder at få mest ud af det:
- Spring ikke indrykningen over. De indledende mellemrum er en del af linjen og en del af øvelsen — at skrive dem korrekt, hver gang, er halvdelen af pointen.
- Læs, før du skriver. Kode har forudsigelige former — en
(indebærer næsten altid en)på vej, en{indebærer en}. At forudse dem skærer de små pauser ned, der lægger sig sammen. - Lad lillefingeren lære tastaturets kanter. Parenteser og symboler samler sig ved de yderste kanter af de øverste rækker; bevidst øvelse er det, der flytter dem fra »lede efter den« til muskelhukommelse.
- Øv begge sprog, hvis du bruger begge. Pythons kolon-og-indrykning-stil og JavaScripts klamme-og-semikolon-stil træner lidt forskellige reflekser.
Det lægger sig oven på det grundlæggende
Symboløvelser virker bedst oven på et solidt fundament — leder du stadig efter bogstavtasterne, så start med lektionerne i ti-fingersystemet først, herunder den særskilte lektion om programmeringssymboler, der dækker klammer, parenteser og sammenligningsoperatorer specifikt. Når det grundlæggende er automatisk, er kodespecifik øvelse det, der lukker resten af hullet mellem dit WPM-resultat og, hvor hurtigt du faktisk føler dig, når du skriver rigtig kode.