If you want my unsolicited 2 cents to help speed up (if you care!)

1. put your fingers on home row keys with pointer fingers feeling the bumps on F and J

2. DONT move your wrists all around, try to keep them still and let your fingers do all the work. try to keep your entire palms as still as possible, they really shouldnt move. I rest mine on my laptop surface.

3. dont look at the keys. use https://www.typing.com to help you if you cant do that

4. relax your hands as much as possible

Typing.com is better IMO if you don't know how to type fast, and monkeytype.com is way more fun when you do (the interface is just way more fun)

Thanks for the advice - I do 1 & 3 and I think I do 2 & 4 although that's less true when writing things with symbols (such as code), or when navigating text (I don't use vim). According to monkeytype.com, my typing speed is ~40wpm, which is apparently around average (not average for monkeytype users).

Thinking time definitely dominates, I'm hesitant to write something unless I'm confident in it, which I feel serves me well when writing code, but less well in other contexts (except perhaps HN, which has an unusually high fondness for accurate rebuttals of minor technical points). I spent ~20 minutes writing each of my 3 replies to you (longer on this one now that I've finished it). Perhaps being able to type at the speed I could talk would deny me the chance to think about it while waiting to finish typing, speeding me up indirectly.

You definitely hit the nail on something you said, which is when I'm forced to type on my phone, my replies are always MUCH more succinct, clear, as I can only type like 30 WPM probably on my phone.

I don't know how it is working on large teams, but for my daily work working alone I usually write maybe 10-15 emails, I issue a dozen or more commits, I outline specs (a vague word I'm using which could mean writing documentation, writing technical explanations to clients, writing comments, commits, boilerplate, talking about technical things to my peers via chat).

The entire technical burden of all things fall on me, so I suspect I'm editing code a good 6-8 hours of the day, and the other 3-4 hours at the computer are spent communicating of some form. I wish I knew how many words I typed per day but it must be seriously 10's of thousands. Maybe 5000-15,000 depending on the day. Now I imagine doing that.......... 3 times slower. That gives me excrutiating physical pain.

If I sat in a vaccum, with no outside communication, and nothing else dependent on me whatsoever, and I was basically given a single task to produce a 50 line file by the end of the day, and the other 7 hours was spent deep in thought, then i could see typing not being important.

My point was intended to be with regard to code specifically, I don't dispute that typing speed is beneficial for other communication. My recent coding experiences have been much closer to your last paragraph than your first (talking to peers about technical things has often been via audio).

I think it matters a great deal too, and not just for typing code but for reading it too, and this goes beyond simply typing fast but also writing short concise code, especially for parts of the code that are closer to defining program architect than implementing the details: it's better to have everything fit in one page of code rather than being dispersed throughout multiple files.

The reason for that is that a codebase will condition the complexity and thus time it takes to add features to it, in a way that is similar to algorithmic complexity and big o notation, except we as human can't even afford polynomial complexity and constant factors matter a lot.

Imagine you're developing an API, both server and client. You can cut your time in half by automatically deriving the client code from the server side specs. Of course you may have to develop that tool yourself and it takes time. The point is that the time invested developing it will be repaid each time you implement a new endpoint in your API, cutting development time in half:

n * (t(s) + t(c)) versus n * (t(s))