Typing fast is about latency, not throughput
two-wrongs.com
two-wrongs.com
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 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.
What sometimes gets me though - I think one word, but type another. It's almost always the same starting letter or letters though. It's like the muscle memory kicks in, but takes the wrong fork in the road or something. Very odd.
I also realize how much of what I use all the time is actually “ctrl-r <first few characters of commonly used one liner>” and have to go double check that when working with others. A blend of muscle memory and a search index of commands.
> "us" more about not...
I did type the same. So I did not really type what was in my head (my "inner voice" read "is").
Humans are weird.
After touch typing it through muscle memory for 6 or so months one day I misentered it a few times in a row, and I realized I had no idea what I actually had been typing the whole time (I knew the dictionary words, but the combination of numbers and where they appeared was the issue). Spent a while trying to zone out and let the muscle memory take over again but didn't work and finally gave up and asked for it to be reset.
Very strange experience....
When people see it they sometimes ask me what keyboard shortcut that was, but no, I just typed them and backed into them.
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.
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.
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.
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.
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.
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 think the NEO and NEO2 layouts were designed with a variety of languages in mind.
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.
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.
My accuracy has only gotten worse as internet speeds have improved :)
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.
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.
That still doesn't stop us from having typing (as in writing) races at the office which is a fun thing.
The way I see it, they're juniors because they need guidance and to gain understanding. You cant do that with a computer writing code for you.
Showing someone how to use column edit, or macros, or automated method refactor, will change their productivity dramatically. It’s the role of leaders to teach and empower.
The article makes a good point about how little of software development consists of typing. This matches with my experience also, over several decades. There are so many things to optimize before "code input speed".
20 years ago, one of our guys hurt his arm and had his arm in a sling. The customer asked for a 50% discount on his rate - it was clear they saw software development as "fancy typing" rather than a process of turning business requirements into functional software.
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.
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.
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.
You can find downloads of the original game via Google.
> 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.
Most companies that are actually profitable. There's a massive amount of space in between "done" and startup level expansion. There are good, mature projects which need some improvements and TLC, without expanding their scope every day.
And because they're already large and most of the simple issues have been addressed, you start getting the interesting problems that take many more times as long to investigate and understand as they take to fix.
Lots of others have basically stopped shipping new products, new features, performance improvements, UX improvements, etc. But I think that’s frequently an undesirable state the company has gotten into, they’d love to be productive but have lost the ability.
I'd dispute that in general. And definitely if you mean amount of innovation per employee. They try random new things that either lives in its little corner, or gets killed in a couple of years. They sure have lots of churn and likely lots of lines of code flying around, but innovation...? There's two projects from Apple from the last decade that I'd call innovation. Amazon marketplace is static and AWS just gains new features that are mostly expected / business as usual. Google kills as much as it creates all the time.
I really don't think those are great examples of moving fast.
You can add features / value by only removing code.
[1] https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
To me this belief is a big red flag. The most productive developers I've worked with have all been among those on the team with the lowest LOC count. Writing lots of code is easy: Ignore good practices, don't think through how to generalize components, and reducing boilerplate, and in the process of doing so create a codebase where getting anything done without high LOC changes becomes progressively harder.
In my last job, I spent many weeks on a component that ended up at ~2KLOC. In the same time period, we had several people writing thousands of lines of code each of views and controllers for a number of database tables.
Once my component was done, it dynamically synthesized the starting point for 10x the number of tables let us cut weeks of developer time off the work involved for each model where we now just had to fill in some config and write the occasional custom component to make things nicer. It also let me spend the following week deleting many thousands of LOC of code the rest of the team had written that had been rendered entirely redundant, so my average LOC produced for that period was net negative and cut months off our delivery timeline.
Sustained high LOC count is to me a warning sign. If the code is easy enough to write that you can churn it out at high tempo, odds are there are patterns that can be generalised and wrapped up in higher-leverage components that you're ignoring.
> if over the long term the most productive devs at a company are only shipping on the order of 100 LOC/week, progress is gonna be really slow.
And that is what I took issue with. It's specifically talking specifically about the most productive devs, and about shipping code.
I was not talking about per feature or per project. I was talking in general.
(Anyone who wants to discuss it can send me an email and I'll try to hook everyone up to the same email thread.)
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.
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.
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?
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.
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.
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.
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.
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.
Hi, this is me. I can communicate better over text due to my being autistic. I prefer text for this reason. I type at 150wpm.
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)
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)
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)
[0] https://www.urbandictionary.com/define.php?term=cheese%20str...
[1] https://www.google.com/search?q=thta+movei+abotu+bible+speeh...
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 wish we had better consumers.
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.
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.
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.
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.
(Lack of) Typing speed has not hindered their career.
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
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.
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.
I haven’t come across anything faster than sublime text so far.
/swiped and autocompleted at ?? wpm
- Different keyboard layouts have very little effect on speed. Querty vs Dvorak vs a completely random layout will have little difference in typing speed after learning it for a reasonable amount of time.
- Learning time is probably reduced by using a more intuitive keyboard layout. This was one of the key points in August Dvorak's studies while researching the layout, and found that Dvorak was significantly easier to learn for new typists.
- Hand and finger movement is reduced by placing more commonly used (mostly optimised for english) keys on the home row. More words can be typed using only the home row keys on Dvorak and especially Colemak than on Querty, which also likely reduces rate of misspelling. This can also be an improvement for typists with RSI or other injuries.
Different layouts have different goals, as you've said Dvorak has a great approach for altering between left and right hands for commonly used letter pairs. Colemak optimises for inward finger rolls, which I might learn as they're very satisfying to type in the rare occasions they appear on my default of Dvorak. Layouts like Engram aim to reduce use of the middle column between the left and right hands.
While I can't unequivocally recommend alternate keyboard layouts to every person that types regularly, one thing I can say is beneficial for any layout is simply to remap Caps lock to Backspace for reduced finger movement. Think about how often you use Caps lock and then realise it's wasting valuable space on the home row, while usually requiring the typist to move one hand off the keyboard every time they want to correct a mistake.
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...
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).
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.