I'm a competitive typist. I'm also a programmer. The main positive that I see is that typing no longer requires thought. I think of the code I want to write and it's transcripted onto the computer.
I would say that it's more advantageous to type _accurately_ than quickly. Typing competitions generally require 100% accuracy, which gives me a great amount of belief that what I'm typing is correct, without having to look at it / check it over and get side tracked from the code itself.
I can't emphasise this enough.
Whenever I see even experienced programmers searching for the right keys or trying to correct their mistakes I just feel sad for all the lost productivity. It's also about not using the subconscious muscle memory which means a good chunk of conscious mental bandwidth is getting wasted on repeated task that could otherwise have been used for programming/creativity etc.,
By a sequence of happy coincidences I got trained as a touch typist before I could go anywhere near a computer. On a real mechanical typewriter. So by the time I was learning programming I was focused solely on learning it as opposed to fighting the keyboard. The benefit of touch-typing can't be emphasised enough, if it were up to me I'd make touch typing a mandatory skill training course.
I have the same mechanical background as you. It took me years to stop absolutely blasting the keys when typing though. It did speed up my word count doing that too.
For me having to stop and look for a key is a jarring thing. Usually because every manufacture wants their 'own touch' on the keyboard. Laptops being the biggest offender of this.
It's kind of a trite thing to say, but one of the most valuable classes I took in HS was typing. I won't say it was _the_ most valuable, there were plenty of other valuable classes, but typing was one of those classes that was considered a lazy elective but definitely should have been required (imo) and I consider myself lucky to have taken it.
It was more discipline than other typing jobs, but paid off. I also never think about typing unless I'm having to recreate emacs or vi commands on a weird touch-screen keyboard or that time I learned Dvorak for a while.
These synchronization errors have been the main source of my typos, unlike the kind of typo caused by individual finger imprecision, like accidentally hitting 'p' when meaning to type 'o'.
It occurs to me that because we use both hands, the way we type is inherently 'asynchronous'. For example, when trying to type('the'), the individual 'function calls', typechar('t'), typechar('h'), typechar('e') may be initiated (i.e. fingers begin moving towards their target keys) in that order, but there's no guarantee they are terminated (i.e. fingers hitting their target keys) in that order, because typechar('h') is performed with the right hand whereas typechar('e') is performed with left, so typechar('h') cannot "block" on typechar('e').
But if we were to make each typechar action wait for the previous one, it would be unacceptably slow as well. So it seems the only solution is to invest time in developing just the right muscle memory where everything is timed perfectly.
Practice did help too, but tbh, I practiced a _lot_ and it was frustrating seeing other players be so much more accurate than me while I had likely practiced just as much. Being healthy is just a competitive advantage.
I don't know, exactly, but I think I've got most of the common words and key-combinations up to about five characters into that state, and a few longer sequences as well. (I have one long and challenging password I type frequently which I cannot accurately type letter-by-letter, but do just fine when I stop thinking about letters at all.)
If I wanted to type faster (I do ~80wpm on online typing tests) I'd practice more sequences, but I can't seem to think any faster than that when I'm doing moderately complex work. Typing latency doesn't hold me back; brain latency does.
Anyway, that's how I've developed that muscle-memory that you mention.
It's definitely about getting to the point where you're not thinking about typing, you're thinking about words/sentences/lines of code (or higher.)
I particularly noticed this when going from perl to python - in perl you were typing fewer characters, in python you could use more mainline english typing and not care that you were using more keystrokes...
Perhaps I'm just overly sensitive but if the input latency from keypress to echoing is consciously perceptible then I consider that already unusably slow. I can't imagine using a setup like that regularly. Special case being something like a slow SSH connection, where I do have to just "feel" it and proactively correct mistakes, but I fortunately don't regularly have to connect to servers more than about 200 mi away.
Hmm? If anything a lot of modern software is worse even from 80s latency, from extra processing going on in the editor, all the way to inefficient polling and scan rate in keyboards, USB latency, monitor refresh latency (next frame, 60fps = ~16ms wait if you're unlucky and press towards the start of a previous refresh) and so on. And that's not even accounting for extra layers like Electron.
I did know a guy once who was one of our rockstar devs. While he was incredibly smart, I think his real superpower was how fast he typed. The words just appeared on the page. And if you were over his shoulder, his accuracy didn't decrease that much. When someone is watching me, I lose 50% accuracy.
Typing correctly when someone is watching us more about not not letting someone's possible judgment distract you. When you are manually typing, it's just not as fast.
We went to a tri-county competition that used computers instead. I was the only one from my school that realized we could correct our mistakes during the competition. I sacrificed a bit of speed to get 100% accuracy and won the whole shebang. Mistakes were heavily penalized in the scoring.
This. This is everything. Translating your thoughts to the computer efficiently is better than doing it quickly. It's not just for creating tons of code, it's for operating on your existing code without having to make space in your head for typing. Once typing happens automatically, your focus improves.
I wouldn't even say I'm a super proficient vim user, there are people who are way more immersed in it than I am and who can leap around files at phenomenal speeds, but even just the basics I know are a huge help in keeping in the flow of thinking about what I want to do rather than how I'm going to do it.
Have 2 minute sessions (2/4/6 minutes total) as a warmup routine with 10k English words to get my fingers moving in the morning.
I don't quite type as fast as I think, but as I type this, I'm considering my phrasing more than I'm considering how to put the phrasing into the text box, so I feel like I'm experiencing a slower version of what you're talking about.
100% agree! I actually studied the use of typing exercises in CS college students. Incidentally, the lowest performing students benefitted the most having those available.
You can always tell which people are comfortable writing their ideas down, versus those that don't, by how they express themselves in emails, issues, documentation, or comments in the code.
Note that good IDEs help with punctuation, and you can touch-type those, too.
What I find the most interesting in how I type (never really trained, it just "happened" over years), is that often when I make a typo I'm already correcting it before I register it with conscious thought. It's like the hand already noticed that something went wrong, so the backspace keypress has been dispatched autonomously without having to think about it or even observe the result.
This is why I've been using keyboards with nothing written on the keys since 2004. At the time, I was in high school and had no money to buy a professional keyboard, so I spray painted my cheap keyboard with black paint (fun fact: I'm still using that very keyboard to type this).
I've never looked at my keyboards ever since. I can type all letters and all symbols without thinking about it. As an IT person, I couldn't imagine how much brain energy I would waste if I were to look down and search for anything.
You can find downloads of the original game via Google.
Two years there was an event in the UK dedicated to typing. Last year the US. Virtual tournaments happen frequently throughout the year. The most famous one is likely the yearly event hosted by Keymash[0].
Octahedron is also a famous player in the scene. He hosts a Discord server for proficient typists and regularly puts on events.
That still doesn't stop us from having typing (as in writing) races at the office which is a fun thing.
My accuracy has only gotten worse as internet speeds have improved :)
> To be clear, at a steady state in a mature project, I get something like 125 lines of code into production per week.
I don’t think this is uncommon, but it’s wild to me that so many companies let their dev productivity degrade to this level. I work at a decent sized startup, 8 years old, fairly large codebase, and even junior devs who are pretty new to the company are averaging a couple hundred LOC/week shipped to prod, while the most productive devs are averaging ~1K LOC/week.
We spend plenty of time keeping the dev env fast, keeping CI (build, test and deploy) fast, minimizing risk even with minimal QA (strong test coverage, canary deploys with auto-rollback, strong alerting), and refactoring to reduce complexity. But even still, ~60% of overall dev time is spent on product stuff, and this other ~40% is SO worth it if it keeps devs ~10x as productive.
An environment where even strong devs only average ~125 LOC/week is just so, so unproductive, it’s crazy to me that companies let this become the norm. Prior to my current company (which I would consider very high productivity), I worked at a place where the productivity was more inline with 125 LOC/week (experienced, fully on-boarded devs were around 200 I’d guess), I can see how this happens, but it’s crazy to me that so many companies LET it happen.
I also think that this:
> There's a level of mature projects where you don't really do new features anymore.
Is fine for a product that’s basically “done”, but who’s paying you to work on those? More common is that the product would benefit a lot from improvements, but the company/dev team has basically lost so much velocity that they can no longer ship them.
I sort of regret that at times, because I think we could be just as productive (in terms of useful product) with many fewer LOC, but we are stuck with the constraints we live in.
OTOH, I've worked (incredibly frustrating) jobs where the infrastructure is dysfunctional such that the write-compile-test cycles are on the order of tens of minutes, and these have made my LOC/week plummet. In those cases, I've recommended to management that we fix the infrastructure to get down to sub-minute cycles (ideally a few seconds), but usually these have been shot down due to their extreme myopia.
Let's say you have 20 engineers now (low for 8 year old startup). That's 1M LOC/annum. Next year you add another 2M. Where does this go?
Wouldn't you expect LOC shipped to go down as level of impact (eg, size of customer base) goes up?
100 lines on GMail has a lot more impact than 100 lines on a homegrown accounts receivable engine for a small business.
Feels like it should be (LOC * weekly_executions) at least. And that's before we get into the efficiency of the code.
(Anyone who wants to discuss it can send me an email and I'll try to hook everyone up to the same email thread.)
My most productive recent change had a negative LOC count, and will have a big impact.
It's entirely impossible to make an assessment of whether or not 125 lines is good or bad in this instance without knowing more about the type of project etc., but that it is a mature project is already a strong indicator the number quite possibly should be fairly low.
Yes, I know there are audio calls, but with IM it's much easier to be doing more than one thing at once, and talking into each other isn't a problem.
All email is asynchronous, and some instant messaging channels can be treated asynchronously, but some of it is definitely live. If you are not treating some conversations that way, it is you who is being rude and forcing the way you like to communicate onto others.
Sometimes on a Slack thread with 10 people it becomes more like a traditional (synchronous) conversation, especially for a P1 or near a deadline. Typing fast helps me here.
(agree async comms have major benefits)
But I don't think this typing speed provides me the advantages the article professes - as others have noted, I am much more gated by the time I spend thinking before typing than I am the typing process itself. Dropping to 80wpm is going to influence the amount of garbage I throw out arguing with people on the internet far more than it would doing anything actually productive.
To the point of having to pause thought while typing, I don't find this to be particularly true. I'll still be thinking of how exactly I want to word something as I'm typing it, and will make minor adjustments on the fly.
I haven’t come across anything faster than sublime text so far.
But I think after reading that the argument was more akin to webpage load times. Sure, a few extra seconds isn't measurably a lot, but there's a feeling of responsiveness that matters to our psyche, even if according to wall time it's not a big deal. This I find more plausible. I've seen code. I know how damn lazy we can be. People seem to be willing to spend hours of pain to avoid writing tiny helper structs, or writing helper methods, or giving functions/variables names with multiple words.
Still, 80 wpm seems like a lot off hand. That's coming up on regular speaking speed. I wonder if I could test the difference on myself to see if it bothered me; maybe add something that slows my typing rate to 80?
That being said, I don't think I would code anywhere near that fast. Maybe years later when I'm far better at it than I am now. I probably type around 60-70wpm if I'm writing some basic SQL where I know what I'm looking for, I would guess.
When I was in college, it definitely was helpful being able to type quickly so that I could workshop ideas and phrase structures in papers more or less in real time. I honestly almost never wrote drafts, I'd just revise as I went along in that fashion.
Someone speaking at 80 words per minute would sound drunk to me. Or like the super. dynamic. guy. in. the. Ai. Pin. demo.
If you can type above ~80 WPM (which basically just means you can touch type), then using the proper tools your effective WPM is easily above 150 and thus totally irrelevant.
Or put in other words, once you can touch type, you are far better off improving your tools and workflows than practicing typing. In a competition you might train your legs, but in real life you get in a car.
Writing 125 lines is not the same as getting 125 lines of code into production
I often use the example of ".toString" being meaningful whereas ".tosling" is nonsense (unless you have defined it elsewhere). I'm not even sure if that's the correct capitalization of the to string method in JS, but I shouldn't have to care. If my tools can't tell me which one is valid to use in the current context, then the tools are bad and I should look for better tools. (This may not be universally applicable and maybe Lisp is the promised land etc etc. But raw text input speed is a silly metric to prioritize and leads to a local maxima in programming)
It's mentioned in the article, but I mostly think of it as: the faster one types, the shorter the iteration time. When you can type roughly as fast as you'd normally speak, it's a totally different experience than t-y-p-i-n-g each word of a sentence.
But, I don't think your claim is in tension with the article's claim that being able to type fast lowers a barrier (or provides a benefit) that's more than simply the "time it takes to literally type".
There's more there there.
I've got my editor setup with a very quick way to pick up suggestions (which I optimized to minimize both the number of keypresses needed to pick a suggestion and the finger travel distance [it's configured to use the "stronger" fingers first, no pinkies, and it's configured so that the most likely suggestion is on keys in the hands home position]).
Even that way, it's still typically faster to type the whole thing.
And don't get me started on slow as molasses IDEs that exhibit noticeable delays when showing suggestions.
To put it simply: even if you count auto-complete as a word, it's highly unlikely you'll be anywhere near close to 80 wpm (which ain't even that quick).
I remember the 90s and the 20s, when everything happened locally on the local hardware. It was quite easy to type fast, move the focus around in the various forms using tab and shift-tab, move from tabs and windows with ctrl/alt-tab; and there was keyboard shortcuts for most things. I remember being able to execute complex operations between multiple applications using only my keyboard and without having to use any brain power between each step.
Now most things are moved to cloud applications and we interact with them with web browsers. Keyboard shortcuts are (mostly) gone, and each click or operation triggers a request on the other side of the world with a high HTTP latency, and that prevents the brain from chaining them for free.
I remember being able to do almost everything using my keyboard. Now good luck interacting with a web console without switching back and forth from keyboard to mouse for 50% of the steps.
I guess that's also why many developers (including myself) still love the CLI environments.
I think there's a bit of rose tinted glasses here. You could literally see windows and icons being drawn on the screen in the 90s. Even text UI were slow to draw on screen. We have it good today.
Regarding keyboard shortcuts we are good too. I barely use a mouse nowadays. I use Vimium for Chrome to "click" on elements in pages, i3 keyboard shortcuts to jump to specific applications or workspaces, and the mouse emulator on my keyboard (olkb) to click or use the scrollwheel on the odd thing that doesn't want to work with a keyboard. Luckily many programs have adopted the command palete (most editors, vscode, gimp, etc) so it's easy to quickly invoke commands without memorizing arcane shortcuts.
Heck, each keystroke does this on a lot of websites, usually the culprit is some kind of overly ambitious search function. My biggest pet peeve is trying to type something via phone keyboard and losing half the word because it's ignoring inputs made while it's waiting on some http request. I notice the worst offenders are retailer websites (Menards, Target, Walmart, etc)
(Lack of) Typing speed has not hindered their career.
Like, I get it. This seems to be a low hanging fruit that you should consider. But it seems somewhat likely that you will draw the line below stenography. We don't even teach shorthand to people anymore, and that would fall into all of these arguments, as well.
Now, integrity of signal is obviously a problem there. If you have a problem in your mental execution, you are likely to miss it. So, you do have to do some physical experimentation. But, for prose and the like, you don't have to type as you think.
I guess to steelman it, it's like investing in a faster 3D printer so you can iterate on your CAD faster. There's some value there I suppose.
Typing fast won’t make you a better programmer. It will only encourage you to type before you think. It is amazing how much can be done with how little code if you give your brain a chance to actually process what you’re doing. I highly recommend it.
/swiped and autocompleted at ?? wpm
[0] https://www.urbandictionary.com/define.php?term=cheese%20str...
[1] https://www.google.com/search?q=thta+movei+abotu+bible+speeh...
I wish we had better consumers.
The headline here is misleading; it's supposed to be "The Benefit of Typing Fast is the reduced Latency, not the Throughput".
If you wanted high throughput, what you could do is type at 20 wpm, and do so continuously all day without taking a break: minute after minute, cranking out twenty new words.
Your daily throughput would be higher than that of many a 160 wpm typist who only wields that skill in short bursts throughout the day.
The benefit of typing fast is that in those moments when you need something banged up, you see the result faster: the latency from starting to type to completing the intended change is lower with faster typing.
I'm pretty good at typing, but not anything special, at around 90-95 words per minute. I type while thinking all the time, although usually the thinking is the slow part.
Other have mentioned speed and accuracy, but one thing that has been a huge advantage to me is being able to type confidently enough while not looking at the keyboard or screen (or only checking infrequently). It is pretty helpful to be able to have a conversation looking at the person while taking notes, rather than saying "let me write that down" every 5 seconds, interrupting the flow of the conversation.
Maybe for the author. I think best at the keyboard. As others have noted, once you reach the point where the typing is both quick and unconscious, words just kind of happen.
Obviously at a gross level one's typing speed isn't the bottleneck in coding; you need so little ASCII on screen vs. with prose. However, being able to get even "bad" out quickly can help you rough out an algorithm quickly. The ability to get the code onscreen at the speed of thought is very, very valuable.
So I'd agree, that you may write down things quickly or write a lot more in a minute. For coding this means you easily write comments, for messages or articles means you can write a lot more in one moment, which means you write a lot more elaborately.
Latency is about one second.
I consider myself a pretty good problem solver of contest problems, but often I have to type code the same way people use pencil and paper to go through drafts, so I can't relate that well.
The more skilled you are, the more of these tasks can be handled in parallel, for example typing and reading, thinking.
Or, for example, walking and chewing gum at the same time.
It's like how a learner driver needs to focus on the task fully, while an experienced driver only seldom needs conscious thought to execute the process.
Or a pianist sight-reading and playing the notes, while also interpreting the piece on a higher level. It's all about parallel processing
One sort of analogy we can give is driving a car with good response time, even if the car is not having a good top speed, the acceleration we get when we push the pedal is enough to think we are going fast.
But throughput can also have a dominating factor, but its reliant on other areas, like typing out an already prepared article.
For operations that require thought, latency is important
Training yourself to do less effort / having more fun while writing code is a good way to stay in the zone longer.
But it is not enough in itself, tooling (fast compiler especially) can break or improve the flow substantially.
I’d say that typing speed should only be seen as an optimisation target once the tooling is really smooth.
It’s such a frustrating experience that I’ve noticed my communication has gone down noticeably in the past two weeks.
[1] https://www.reddit.com/r/iOSBeta/comments/1774w2h/ios_171_db...
Then, just think about it, and not type it out like a caveman prematurely.
Also, no one on Earth has ever written continuously for 5 seconds outside of typing competitions. You don’t have 5 seconds of coherent text buffer available in your mind even for natural text, let alone codes. So that +3 seconds is complete nonsense.
