I will tell you, that if you are in a job interview with a live-coding portion, if you don't type fast, the interviewer will probably think you are dumb.
And if you don't know all the hot keys they know, then they will probably think you are ignorant. It's unfair, but happens.
There's a story of Donald Knuth and the programming contest:
“In the early days of Silicon Valley, there was an annual programming contest on Memorial Day. When Donald Knuth (the world’s greatest programmer) entered, they gave him an old batch computer to work on. He had to carry punch cards back and forth. The others, great programmers of the time like Alan Kay, John McCarthy; got the ‘modern’ time-sharing systems.
“Donald Knuth had that old, punch card computer, but finished his program an hour before anyone else, and his algorithm was the fastest executing. They asked him how he did it so well, and he said, `With that kind of computer, you think carefully before typing. You don’t want to make mistakes, like carving in stone.”
Sounds like your old programming friend has learned that lesson.
Programming is more like modelling clay rather than carving stone.
You can, and you should, always slowly reshape your creation until you are satisfied with the result.
If you are carving stone there is no way that you can change it without destroying everything and starting again.
You may be faster just using a lot of time thinking before writing the code, but you will never see the real essence that is revealed only while you are continuously moulding your creation.
To me it always happens that after days or weeks or even months that I don't look at some part of my code I find a better way of doing it.
One way that would have never been apparent without the code being in that current form.
It depends on whether the interviewee is using a piece of software that they claim to know. If they're calling themselves a senior dev and they use the mouse to select "save" instead of using ctrl+s, then I probably won't hire them. On the other hand, if they're doing a coding test in Linux and they claim no CLI experience, they won't lose any marks at all for asking how to launch a text editor.
Maybe it's just because I'm a C programmer, but I don't think my typing-to-thinking ratio has ever been above 1:2 and is more like 1:10 when actually programming. And very little of that is actually words.
In Visual Studio C# land, long identifiers are compensated by really good autocomplete. Most of the characters on screen aren't hand-typed. Frankly, if we're going to have computer-aided-software-engineering then the computer can damn well do the typing too.
For me, it's not the fast part that's useful as much as the ability to type braces, square brackets, underscores, = signs, left/right arrowheads without having to look down to locate the key.
Yes, it's detrimental because it's distracting. It interrupts my concentration when I make typing mistakes, or can't get the code written down fast enough. I want to write it down fast, because I can only hold so much in my head, and the faster I can write down an idea, the faster I can move on to the next one. Once everything is down, it's much easier for me to look at the whole, and edit it (refactor, etc.).
Mistakes derail me much more when I'm sharing my screen or pairing. Once I make one, my confidence is somewhat shaken and I spend an inordinate amount of time on accuracy rather than the task at hand. Stupid, I know.
I agree that typing speed is not very important. I managed a measly 12 wpm on the two snippets I tried and would still call myself a professional.
On the other hand, if I can make typing less of a strain, my brain will find better things to do, like thinking ahead. I'll try working without looking down for a few weeks to lose my habit of looking at the keyboard. I've had partial success in the past, but with some keys I never gained the motor skill. The most annoying for me are the keys 9 and 0. I always fumble on these when I try to reach them.
That's why you use good tools. You select a region of code then reindent the entire region, right? Not line by line? You refactor a variable name in all places with one command, not individually.
It's possible that typing is a bottleneck, but I bet if you calculated your actual keystrokes, you'd find that it's very few words per minute.
You don't type most of the time, but once you identify a few lines that need to be written or rewritten, it's useful to be able to at least type without conscious thought, so you can keep focus on the high level structure.
> Code is typed. Typing it slowly slows you down. Just like a slow compiler does or a slow IDE or even a slow computer with spotty internet.
There is a different side of this coin, actually. Having a compiler that takes
a really long time to compile the code gives a different type of friction
than a compiler that works blazing fast. The former makes the programmer want
to avoid unnecessary compilation, which works amazingly well for some types of
people (I am this type, so I speak from experience).
Though this doesn't work for a text editor, I believe. Editor should be as
powerful and fast as possible, and I wouldn't trade my Vim for anything else
(maybe Emacs, but I'm too deep to go back and invest in learning it, only to
discover that I got no further than with my current setup).
Edit: Spotty internet connection has its good side, too. One learns to read
locally stored documentation instead of relying on StackOverflow, which is
a big gain in the long run. Similarly slow desktop computer: if the
program runs acceptably on my (slow) machine, it will be so much faster on
something better. (Though I only write command line tools and network daemons,
so I may be biased here.) All boils down to friction profile, which bubbles
different things up to the surface.
In my current job, I have a docker-compose file that starts four docker containers that are interdependent, two of which frequently need to be rebuilt when I compile. I've found that my code usually compiles the first time even after changing several functions now, since I've gotten in the habit of proofreading more before compiling as a result of the incurred slowdown. Probably some of it is also the decent static analysis tools available for writing Go code, since syntax and type errors are obvious while I'm editing, but I've found I make fewer errors than I used to even when not constrained by the docker slowdown
Typing can be the bottleneck because your thoughts get too far ahead of your fingers. You can only hold so much in your head, so getting the code out into the editor as quickly as possible allows you to free up some short-term memory.
A pen and paper works wonders for me. If I have a moderately complex algorithm then I usually write / draw a diagram representing how it works before trying to code it.
You've hit with the point you should be thinking while typing. For me I know someone is a good typist not if they're quick, but if they're able to type notes on a conversation they're having while still engaging with the conversation. It's a similar thing to the point when learning to drive that gear shifts go from being a conscious thought to a subconscious reaction to your situation.
An IDE does greatly reduce typing. What we need next is some advanced voice input added to our editors. This "John Henry" mentality that developers have about typing never seems to go away. We should be building smarter tools. We're getting closer with voice.
Better predictive typing would also be useful. Computer languages often greatly narrow what you probably want to type next, because of scope, for example.
I didn't say that typing would be completely replaced with dictation.
You still want predictive typing, for example. If I want to refactor a variable name, indent a region, or create a class from a template, having a smart assistant that could be invoked with voice would be helpful.
As for people being able to type faster than voice recognition, I think voice recognition at 100 won would be fine for most people:
Usually the "help" given by IDEs can greatly reduce your typing speed. At least those that use point and click, or at require reading a list of options.
If you know you want to type "for.bar(new Baz(qux))" and you have to wait for a menu after ".", after "new" and after "Baz(", the line mat take 6 seconds rather than one.
Even if this is not an issue, most IDEs require you to know lots of keyboard shortcuts by muscle memory to be efficient anyway.
I doubt there's a very significant productivity advantage to typing fast. But there seem to be a couple of advantages to practising fluid touch-typing: (1) the more automatically you type, the more your thinking as you type is in chunks larger than mere characters. To me at least this feels like text input is less of an interruption to the thinking I had been doing just before typing (2) I find it to be quite a handy warm-up exercise, particularly if my mind feels mushy or reluctant. It's close enough to what I'm doing when actually coding to kind of shoehorn me into the whole process, but easy enough to avoid mental baulking.
About 25 (sigh) years ago, I worked alongside a former journalist. Listening to him type was awe-inspiring. I could type reasonably fast, but where I typed in words, he typed in complete sentences. Machine-gun.
I think there's something to the idea that typing faster could help you think faster when it comes to text, but not sure it applies to software development.
Perhaps, but that's not what I meant. It's not the speed, it's the automaticity. The more automatic the typing, the less of a mental context switch there is when moving from merely thinking to thinking + entering text.
I wouldn't want to over egg this. It's a small thing, but a little focused practise seems to keep my typing more automatic and thus out of my way.
1. I have found, when you know what the next word is, that there is a typing-speed line that if you are above, just typing the thing is faster than using IDE autocomplete. It also disrupts your flow less.
I am convinced, although only based on anecdotal evidence, that a lot of the vim/other-editor vs IDE debate is significantly based on how fast you can type.
2. There are a significant number of programming tasks where the typing-to-thought ratio is relatively high. Refactoring is one. Debugging is another. UI code, or anything with a tight feedback loop to something visual, and particularly CSS, is another. In my experience, the faster you can type, the more likely you are to solve these problems by trying things, rather than attempting to guess what is happening in your head. IMO the former is radically more productive.
3. Slower typers tend to look for GUI tools for things that are probably best used from the command line (git is the paradigm example here).
I am passionate enough about this that I have gone as far as organizing typing speed competitions on my team.
Obviously there are exceptions to the rule. I have also worked with excellent programmers who can barely touch type, although they still suffered from some of the above issues.
> There are a significant number of programming tasks where the typing-to-thought ratio is relatively high. Refactoring is one. Debugging is another.
I might agree for a few cases of repetitive refactoring, but debugging? Definitely not, that's really something where you spend 99% of your time observing, conjecturing, thinking.
Edit: Oh, I had not read the following sentence with care:
> In my experience, the faster you can type, the more likely you are to solve these problems by trying things, rather than attempting to guess what is happening in your head.
That's not debugging. It's just trial and error until the output randomly happens to be the expected thing. That's a terrible way of doing. Gee... if you don't understand what is going on, you cannot consider the bug is fixed. You may even have introduced more problems than you corrected. What's wrong with thinking to sort the problem out once and for all, instead of rushing anywhere like a headless chicken?
But it seems to be the current method, especially in web development. It probably explains a lot of things about the sad state of those applications.
I find most of the 'tedious, mechanical' refactoring tasks are mostly limited by the speed of getting the curser in the correct locations, not in typing out the changes.
That typing-speed line is pretty darn high unless you use exceptionally terse identifiers. My English typing speed is around 85wpm and a good IDE's autocomplete is still significantly faster than typing out identifiers longhand.
I have always disagreed with the rationales given for why typing speed doesn't matter for coding. Maybe it just depends on how your brain works.
I can't really think about a problem while I'm typing. I can think, or I can type what I've already decided to type. Worse, the longer I'm not thinking about the problem, the more I lose my place. So for me, typing speed is critical. I need to get the part I'm working on out as fast as possible, so I can get back to thinking about the problem.
Now that said, we tend to justify the abilities we have, and discount the abilities we don't. I'm a very fast typist, so I do have some skin in the game to think typing is important. I suspect that people who are not fast typists also have some impetus to think that typing speed is unimportant.
Nonetheless, I do think what I said above is a factor, at least for some people.
This is a really cool idea! But I found myself instinctively hitting [Tab] to activate autocomplete on most of the longer symbols, as every IDE / Code Editor I use supports this in some form.
Good question. I don't type code as I type a letter. When "coding", I edit structured text. So what's important for productivity is things like jumping with accuracy (word, corresponding bracket, file...), cut/paste, other IDE shortcuts to rename, refactor, etc.
I switched to a variation on Colemak because I had used qwerty so long touch typing with left hand and pointer/ring only on the right that it was uncomfortable trying to learn to touch type from the home row.
I can still type just as fast as I could before I switched on qwerty keyboards. I left my laptop keyboard qwerty and just switched my external keyboard to Colemak so I swap somewhat frequently depending on if I'm at my desk or on the couch/out of the house.
Colemak changes relatively few keys from qwerty, especially compared to Dvorak. I use colemak full time and can still touch type qwerty reasonably fast.
I switched from QWERTY to Colemak about two years ago. When I had first gotten fully adapted to Colemak, and my typing speed in Colemak got up close to where my QWERTY speed had formerly been, my QWERTY speed took a big hit (down from 80 WPM to around 20 WPM). But now, two years on, I can touch-type QWERTY fast-enough (around 60 WPM). I kind of have to establish for myself a QWERTY context by starting to type while looking at the keyboard.
He makes good points: Programmers need to communicate (often by text) and wrote documentation and comments. If you can't type fast, this is either going to slow you down, or you are going to do less of it.
Nice idea. This is great for devs wanting to learn to touch type better. You could look into adding alternative layouts (DVORAK, COLEMAK, perhaps other language layouts such as German).
I have a new split keyboard (Kinesis Advantage) lying around that needs some breaking in, so I'll definitely try this.
Telefondinleme7.com Telefon dinleme telefon takip casus programlari ile casus yazilimi dinleme cihazlari CASUS TELEFON DİNLEME, TELEFON TAKIP PROGRAMI
Cep telefon takip programi, Cep telefonu nasil dinlenir, Casus yazilim, Telefon dinleme, telefon dinlemesi, telefon dinlemek, telefon dinleme cihazlari, telefon dinleme uygulamasi, bilgisayardan telefon dinleme, Casus program,Kullanimahazir casus telefon programlari ile kullanimahazir telefon takip, telefon takip sitesi, telefon takip cihazi, telefon takip izleme, Akilli telefon dinleme, telefon dinleme cihazi, telefon dinleme programi, telefon dinleme yazilimi, android telefon dinleme, cep telefonu dinleme, bilgisayardan telefon takip etmek, telefon takip sistemleri, akilli telefon takip programi, Casus cep telefon dinleme cihazi yazilimi ve programi, Android Casus telefon dinleme programi, akilli telefon dinleme programi, cep telefonu dinleme programi, en iyi en ucuz telefon dinleme programi,
iletisim
0 850 840 5 211
0 232 332 0 325
0 212 909 1 438
spyphoneturkey@gmail.com
http://www.telefondinleme7.com
I wouldn't say it is. For the past couple of years i've been using heavy IDEs (jetbrains stuff) for very verbose languages like java, and lightweight ones for more concise languages like js or haskell. Learning multiple IDE-s can sound stupid, but i feel that it helps me a lot.
In my opinion there's no better practice than playing Typing of the Dead. If losing in a game irks you even a little you'll definitely improve your typing speed by playing if your current speed is slow.
I've been toying with the idea of making a spiritual successor to this for years, always been too busy with work though. It's one of my favourite games of all time!
Maybe there's some artists/developers here that would want to collaborate to reduce the time burden a bit? :P
I used to make my babysitter play while I watched, because I was astounded she could do so well on hard. Now I play on X-Treme and see if I can make it to the end.
I remember when I was a kid X-Treme seemed impossible, I thought the developer put the difficulty in as a joke.
Nowadays I load the game up once every few months and I tend to beat X-Treme first shot every time, unless I get unlucky with the toxic sharks. It seems you need around 110-120wpm and decent reaction times to finish it.
And make sure I don't hit the wrong letter to start a new fish! That always manages to trip me up. That makes sense, my range is usually around 110. Damn I hate those toxic sharks!
There was in fact an OS X version of TotD, called "Typing Of The Dead: Typing Lariat", and it was an universal binary too; I think I still had it on my mac a few months ago.
I don't think it's sold anywhere anymore; you should be able to find it on some abandonware website, with a bit of googling.
The menus are in japanese but the text to type is all either in english or at least uses english characters. If you want the proper english version you could try with wine, the tests on winehq seem to report decent compatibility.
Epistory: Typing Chronicles is another fairly recently released great indie typing game that even runs on Linux and supports layouts other than QWERTY such as COLEMAK and DVORAK.
What blew my mind with the site in the post, and what Typing of the Dead lacks, is that it shows you which fingers to use to type. I never before realized that in all my 15 years of typing, I only use my index and middle fingers. I'm going to use this site to train myself to type using all my fingers instead, which I'm fairly confident will lead to a speed and accuracy boost.
Is typing speed really the bottleneck when programming? For me, it's definitely either the speed of thought or the time it takes to look up names, interfaces, etc.
No, what you experience is normal. Typing speed is never the bottleneck, unless you write some boilerplate code - which, frankly, is something you should avoid and automate anyway. As a rough estimate, I spend more than half of my time drafting, either with pen and paper or in my head, and then half of the remaining time researching. Only a tiny fraction of time is pure typing.
I love the idea. typing.io's $10/month is a bit steep. Nice to see someone else in the area. It would be really nice if I could turn off the keyboard highlights. It's basically a strobe light when typing and gets distracting.
I've been using it for a few months. Around ten minutes per day, five days a week. It has a few small issues, but overall I would definitely recommend both the site and the habit.
For anybody learning to touch type, I highly recommend looking at alternative keyboard layouts. I use QFMLWY, which reduces typing effort by 43% in comparison to QWERTY (for some measure of "effort") [1]. It greatly reduced my wrist pain, and just feels much "lighter" to type.
I feel like learning a non-qwerty layout would make it difficult to switch between computers. What has your experience been? Is QFMLWY supported on pretty much every device? How does it compare to Dvorak?
That's a valid point. I now can't touch type on QWERTY keyboards anymore (but mostly because I never have to). Setting up QFMLWY requires special setup that is more difficult than "select the layout from the System Preferences". I'm certain it outperforms Dvorak, but I'm not sure by how much.
I used left-handed dvorak for a while while my right hand was broken, and used colemak at home, but I reverted to QWERTY after realising I have to work with other people. Other people use my computers, and I use other peoples computers. Having to remember to switch maps before letting someone start typing at my computer, or having to cognitively switch back and forth between layouts whenever I used anothers wore thin, and I gave up.
If I did lose the use of a hand permanently, I would probably try making a custom map with chording, there's definitely a payoff there.
I'd say it would be worth learning alternative keyboard maps if:
A) you work remotely and have a single computer or set of computers you can permanently configure with your preferred layout.
B) You're a wordsmith/writer and produce large amounts of textual input as fast as you can type.
I think getting a base touch-typing competency matters far more than optimised layouts, even though the latter can improve comfort/accuracy/speed even further.
In comparison, the text-input methods for smartphones and portable devices need to improve drastically. I find myself getting frustrated whenever I need to input more than a single sentence of text into a smartphone. Using terminal emulators or trying to write technical code/information is a nightmare.
I'd be delighted to just have a querty with a Swedish layout, but with some English mappings for \[]{}, all of which require AltGr on a Swedish layout. Having those available on a better (or no) modifier would save my wrists a lot of pain.
I would recommend that you just use the US layout when coding. It's not like you need åäö when writing source code. The only time I use the Swedish layout is when writing emails or chatting, and a keyboard shortcut to change layouts quickly solves that for me.
If I type more, I make more bugs. But my mom made me take a typing course, the summer before high school, i.e., in 1978. It has had an unexpected benefit, years later:
I suffer from eyestrain headaches when I stare at a computer screen for a long time. I can type very fast, including all of the numbers and symbols, but if I slow down just a tiny bit, then I can type quite accurately. As a result, I can type long stretches of text or code without looking at the screen for mistakes.
Because of that kind of eyestrain, IDE's don't really help me. Having all of that info on the screen and requiring me to look at it, just makes it more painful sooner. So I code in a plain text editor. Stackoverflow is my IDE. ;-)
Have you considered using a screen reader?
As far as I know, most of the major IDEs have at least basic support for them and there are plenty of blind programmers out there so there's definitely software for it.
(Obvious suggestions like making sure you brightness is set as low as possible etc aside)
It may do you a world of good to see an optometrist and get a pair of single vision (not progressive) prescription lenses adjusted so you see clearly at the distance to your computer screen.
If you use a laptop, bring it with you. If you use a desktop with external monitor, measure the distance from your eyes to the screen.
But if you are currently doing something like getting up close to the display and squinting so you can see it better, don't do that. Instead, pick a distance that would be comfortable if you could see clearly at that distance.
For typical laptop use, this is probably around 20". Maybe a couple of inches farther for a desktop monitor, but measure to be sure. If you use both, maybe stick with the laptop distance since you can position your desktop monitor at the same distance.
Don't ask for a "reading" prescription: that is typically around 16", much too close for most computer use.
Once you know the distance, your optometrist can make a prescription adjusted perfectly for that distance, and you can try out the prescription on the spot with their collection of test lenses.
I avoided doing this for years. I thought I just wasn't the kind of person who needed glasses. Turned out I was, and it was such a relief for my eyes when I could see my screen with no strain.
Thanks. That's a good idea. I've been planning on doing it for reading sheet music, but an additional prescription for computer reading is definitely worth a try. Right now I wear bifocals, and the problem is that I have to tip my head back to read stuff, which aggravates my neck. So a single vision prescription might just be the thing.
Programming is a unique field: if you're doing it right, it should never be dull. Frustrating? Draining? Rage-inducing? Sometimes. But not mind-numbing. Why? Because we can build our own tools. If we find ourselves doing repetitive work, we can build a tool to automate that work. This automation is itself likely at least somewhat interesting. What isn't repetitive and that can't be automated should be interesting as well.
If you find yourself bottlenecked on typing while programming, it's a signal that you should stop what you're doing and write some automation or abstraction. Sometimes you can just structure a program so that it requires less typing --- almost always a good thing.
In the rare cases where you need to be verbose in source code, you can use build-time source code generation, or failing that, an editor snippet library. I like yasnippet for that purpose.
Back at Microsoft, NT kernel style requires a big doc-comment before each major function. (These comments are extremely helpful --- but that's beside the point.) The doc comment's style is a bit more complex than Javadoc; there are multiple sections (e.g., description, arguments) and specific indentation requirements within each section.
I found it very annoying to write and format these comments. Instead of just cursing doc comment writing all day, I took a week and solved the problem. I taught Emacs to highlight and indent these comments. I taught M-q to reformat paragraphs exactly as needed. I added code to automatically generate a skeleton description from the function prototype. And after all that, I was never bothered by the doc comment stuff again.
(Incidentally, in a big monolithic IDE, I think the barrier to this kind of extension would have too high to bother with, and I'd have been left cursing this code.)
I see where you're coming from, but this tool is still valuable in a number of cases that I don't think you're considering.
I recently got a new mechanical keyboard, which had special "layers" for punctuation. "Common" punctuation like periods and commas are still there, but other punctuation like curly braces, brackets, etc. require new key combos. [1]
I agree with you that a lot of the time programming requires modifying rather than composing, but not all the time. In particular, I blog in Markdown, which requires a certain amount of extra symbols that I wouldn't normally be typing. (Goes hand in hand with the previous point).
[1] You might be wondering, "Why get a new keyboard, if you're typing slower with it?" The new one is easier on my hands, wrists, and fingers, as well as being an actual pleasure to use.
I built a Planck, and as much as I appreciate the ortholinear layout, I'm having a hard time finding/configuring a keymap that has the necessary symbols somewhere that feels intuitive. I'll spend a couple hours acclimating to a keymap on typing.io, but if I need to an ANSI staggered KB, even for a couple hours, it seems to wipe my muscle memory. Guess I need to buy another Planck!
I use a special dialect of Dvorak, called Svorak A5 [1]. I think it is somewhat similar to what you describe. It is really liberating to have special characters on the home row.
This is why no matter how much sense it makes to use something like vim or emacs as your primary development editor, I could never justify the amount of time it would take me to actually be totally comfortable and start seeing benefits (beyond just using it for small quick edits at the command line).
Typing speed is never the bottleneck. You could double most developers' typing speed when they code and it'd probably have a negligible impact on their overall productivity.
There are benefits, but do they really outweigh the benefits of those same hours spent studying a data structure or design pattern or trying new tech?
I agree this things like typing speed and a good editor should not matter but in reality I think it does. I think the state of programming flow is very hard to get into, and very easy to fall out of. In fact the easiest way I find myself getting out of state of flow is if I find myself doing something mundane. Anything that allows you to do more while you are in the flow, or lessens the chance of breaking out of it is valuable in my opinion. Will share an anecdote here - before I started using clang-format for formatting my code, I expected that adopting it would merely save me the time I spent formatting. On the contrary what happened was that it has almost completely changed the way I write code when I am in flow since I now no longer have to worry about having to make it look good. In retrospect I now find that in the past I would often spend crucial parts of my programming flow doing mechanical indentation of code and doing such a mechanical activity was often a ripe target for me to fall out of flow.
My typing speed and accuracy are both pretty low, when and if I correct that, I hope to have a similar efficiency gain as I did when I adopted clang-format since I won't be falling out of flow for mundane things like typos.
Not every moment spent programming is equal, and in my humble opinion it really helps to invest in making your "special moments" more productive.
If you don't think vim or emacs is worth it then fine, but you're setting up a strange false equivalency between learning new concepts and learning new tools. The fact is, you can't program without tools, and practice will make you better with the ones you choose. If you only ever learn new patterns and algorithms and just type your code into Notepad then you will be handicapped as a working developer.
Personally I choose vim for the exact reason you choose not to: that is I want the ability to edit files in any language on any system I touch with maximum efficiency. This accelerates my ability to try new languages because I don't need to rely on language-specific tooling. Also, vim has more longevity than many design patterns which are susceptible to obsolescence by new language features, and new languages themselves which have a half-life proportional to their age.
It doesn't take much time to be equally comfortable with vim/emacs as you are with your normal editor. Anything you learn after that is a bonus. It's hard to say how much faster I am using vim than a normal editor, but I'm a hell of a lot more efficient and comfortable doing it.
Wha, what? vim and emacs aren't about typing speed, they're about action speed. 99% of the reason I love using vim is because I can do exactly what I can do with a combination of mouse and keyboard actions, but without leaving the keyboard. And many IDEs have, for example, vim extensions so you can get the best of vim without manually building up your vim environment and extensions (although learning e.g. PyCharm is no different than learning and building my own vim env -- I use both).
Being able to type quickly and accurately is enjoyable. It lets my brain stay focused on what I'm writing rather than how I'm writing it. No context switches necessary, no mistake every 10th key; typing should be fluid and easy. I highly recommend improving your keyboard skills if you struggle with touch typing.
That said I agree that "Typing Practice for Programmers" on "SpeedCoder.net" is a little silly. Just learn to use a keyboard (and learn to spell, that helps too).
Honestly I believe that a programming specific typing practice program such as this one does serve a purpose as even though I can type well in a normal setting, I am much slower with many of the special characters as they just aren't used as much outside of the programming environment.
Those generally complete identifiers, not the various symbols like "->" "*" "&" "{" etc... So I think the parent's point is still valid. If anything autocompletion increases the symbol-to-letter typing ratio.
I encourage you to drink heavily. A friend of mine learned to touch-type because he came in to work hung over too many times, and felt queasy switching between looking at keyboard and screen... so it made him learn to touch-type...
Sure but the more you do this, the more tools/commands/libraries/modules have to ideally both document and remember, realistically neither..
Cognitive overload. Shell commands with their args ... core syntaxes for half a dozen languages ... a couple base class libraries and 0-2 frameworks for each ... plus all your own abstraction/automation stuff on top? Admittedly this all used to be quite a bit simpler back in a sole "Win32-app world": VisualStudio+MSDN=done, no shell to speak of, no web layer / stack, One GUI Way, etc. But 15-20-years-ago ain't coming back for at least another decade.
From the preface of The Productive Programmer[0] by Neal Ford:
"Many years ago, I taught training classes for experienced
developers who were learning new technologies (like Java). The
disparity between the productivity of the students always struck
me: some were orders of magnitude more effective. And I don’t
mean in the tool they were using: I mean in their general
interaction with the computer. I used to make a joke to a few
of my colleagues that some of the people in the class weren’t
running their computers, they were walking them. Following a
logical conclusion, that made me question my own productivity. Am
I getting the most efficient use out of the computer I’m running
(or walking)?"
Cutler Normal Form! I love it, use it exclusively now on all my projects.
_Use_decl_annotations_
PVOID
TraceStoreAllocateRecordsWithTimestamp(
PTRACE_CONTEXT TraceContext,
PTRACE_STORE TraceStore,
ULONG_PTR NumberOfRecords,
ULONG_PTR RecordSize,
PLARGE_INTEGER TimestampPointer
)
/*++
Routine Description:
This routine allocates records from a trace store. It can be considered
the TraceStore-equivalent of a calloc()-type interface, in that the record
size and number of records are specified rather than the total size.
The memory to satisfy the total size is sourced from the trace store's
active memory map. If sufficient space is available, allocation is simply
a matter of adjusting the relevant pointers and returning.
If the required size can't be satisfied by the remaining memory in the
map, this routine consumes the "next" memory map that has been prepared
asynchronously in a threadpool if one is available. If the prepared map
is not yet available, the allocation fails and NULL is returned.
N.B. This routine should be called indirectly through the TraceStore's
AllocationRoutine function pointer.
The total size that can be allocated is limited to the maximum size of the
memory map. The allocator is geared more toward lots of small allocations
versus larger ones.
Arguments:
TraceContext - Supplies a pointer to a TRACE_CONTEXT structure.
TraceStore - Supplies a pointer to a TRACE_STORE structure that the memory
is to be allocated from.
NumberOfRecords - Supplies the number of records to allocate. The total
size is derived by multiplying RecordSize with NumberOfRecords.
RecordSize - Supplies the size of the record to allocate.
TimestampPointer - Optionally supplies a pointer to a timestamp value to
associate with the allocation. When non-NULL, the 64-bit integer
pointed to by the variable will be written to the allocation timestamp
metadata store. This should be NULL if the trace store is a metadata
store, or if the trace store's traits indicates that it is a linked
store (implying that allocation timestamp information will be provided
elsewhere).
Return Value:
A pointer to the base memory address satisfying the total requested size
if the memory could be obtained successfully, NULL otherwise.
--*/
I'm definitely on-board these days with the typedef-everything approach used by NT. Every public function gets a typedef with SAL annotations exposed in the module's public header file, e.g. in this case, TraceStore.h has:
Basically I've resigned to living with the ugliest possible function typedefs, complete with SAL annotations and whatnot, at the benefit of much cleaner interaction elsewhere in the code, e.g. to call it I'd just do:
Oh, sure. I miss SAL terribly. The consensus outside Microsoft seems to be that we need annotation-less static analysis because developers will never add annotations --- annotation-less static analysis, IME, has a much higher false positive rate than prefast. Windows is proof that extremely robust static analysis works.
Back when I was in Windows, the system was so robust that if the static analyzer reported on your code, it was yourcode that had the problem, not the analyzer. It did bounds checking, nullability analysis, and tons of useful stuff. It's fantastic.
The thing about NT-style pointer typedefs is that they discourage const-correctness: it's enough of a pain to make a PFOO. You want a PCFOO too? That said, I'd be more than happy to live with poiner typedefs if I got SAL back.
BTW, I also used a hacked-up cc-mode that understood all the SAL annotations and fontified them using font-lock-keyword-face. It worked great.
Ah, yeah, const-correctness definitely gets way more tedious, but eh, just like the ugly as sin typedefs, I think it's a net win.
I've been contemplating doing a little project that scans all the SDK/DDK headers for SAL annotations in use and making a big cross-reference where you can, like, click on the #defines in <sal.h> and see all the places where there are real examples of it being used.
Some of the complex uses are really hard to grok just from MSDN documentation alone; I've found looking around at the WDK/DDK headers much more useful.
Unrelated question: why'd you leave Microsoft? Were you doing NT kernel development there? Is that what you've done in the past?
This test is a bit..silly to me. I am an enthusiast of mechanical keyboards, own a few, and have enjoyed typing for as long as I can remember. On top of that, I can type quite fast - depending on which keyboard I am using as it does affect me a bit I reach about 720cpm on my mx blues (ducky keyboard) and about 670cpm on my KBP keyboard with Matias Quiet Click switches, which is my slowest board. (on the 10 fast fingers typing tests)
Which is quite a good speed for typing, and I have _never_ found that to really help me at all when coding. Usually when coding you are still thinking about what to write and the speed at which you write code is never actually hindered by the typing speed that you have.
There are a few exceptions to this, as I like doing live-coding when giving presentations it does help me write the code faster, but I already know what I am going to write to a large degree and people seem to like the live coding.
But for day-to-day programming, I don't feel like this matters..
I have thought of getting a mechanical keyboard, but I don't think I need it. I have been typing a lot on a standard Acer keyboard for a couple years, until the W key dome was gone, making it really hard to use with gaming. After that, I switched to the light Logitech K700 keyboard with flat keys. Typing on it feels good and I don't need to type fast, I want to type accurately. And in the end they are pretty quiet :).
Once you get one, it is really hard to go back to a non-mechanical keyboard. And quietness is quite important for anyone working together with other people. That is why at work I use a keyboard with Matias Quiet Click switches. They are not that much louder than a regular rubberdome keyboard :-)
Agreed,if the bottleneck is CPM/WPM ,you probably need better tooling in the form of scaffolding/boilerplate. But for those who can't touch type this could reduce the cognitive load of hunting-pecking. I need something like this (or typing.io) that will let me configure auto-complete so that it matches Sublime.
You should check out typera.net for in my opinion, more realistic typing tests. I just tried the 10 fast fingers test and got 750 on my first try on a cheap keyboard (I maxed out at a tad over 700 on typerA where it uses random sentences albeit much more difficult generally).
Thank you for the recommendation, I will surely check that one out! And you got a nice score, congratz!
A more expensive keyboard does not make you type better in my opinion, but it does improve the comfort of typing for a longer time. It also depends on what you are used to.
Another one that is fun is typeracer, it let's you race against others by finishing a typing test as fast as possible. These are fragments from literature that you are typing and thus adds some difficulty as well compared to 10-fast-fingers, as you need to keep in mind punctuation :-)
It matters just for saving you the annoyance of looking at your keyboard searching for a specific key. The less you look at what you write, the more prone to error you become.
For me, it's not really about typing fast, it is more about typing without making mistakes. I find hitting the delete key too often is frustrating and it interrupts my flow. Unfortunately I never mastered that skill, I can type quite fast, but most of it is errorsome. (eg, I made three mistakes alone typing the word unfortunately..)
Of course typing is not the bottleneck to any mildly interesting programming effort. If you're doing repetitive stuff, you should have your editor do it for you.
But the thing is that typing fast and accurately feels wonderful. Conversely, it's incredibly frustrating to be constrained by a different layout or hardware.
I can be reasonably fast/accurate on my preferred keyboard, but I can't touch type very well and I envy the fluidity when I watch someone do it.
I have tried a few times to learn it, but the process is infuriating. I'd love to find something a bit more tolerable.
> Of course typing is not the bottleneck to any mildly interesting programming effort.
I would agree with that to some degree, but I think typing faster can help the thought process, in the sense that you can write down your ideas faster, so that you can free them from your memory and keep moving forward with your thoughts.
Agreed - people in this thread are too down on typing skill. It's not the only thing, but it is important.
Think -> decide that you need to extract a method -> using the keyboard, and your editor, do that -> think again.
The step w/ the keyboard will involve your custom editor environment, and typing. If you get it done, you can shorten the cycle from Think -> Decide -> Act -> Think, and get into a smoother workflow. If your keyboard and tools need your active thought on how to succeed, you get derailed in that Act step, and have to restart your thinking about the real problem.
171 comments
[ 4.9 ms ] story [ 310 ms ] threadIsn't there a saying "weeks of programming can save hours of planning".
Plus a decent IDE will eliminate the need for this type of thing.
And if you don't know all the hot keys they know, then they will probably think you are ignorant. It's unfair, but happens.
“In the early days of Silicon Valley, there was an annual programming contest on Memorial Day. When Donald Knuth (the world’s greatest programmer) entered, they gave him an old batch computer to work on. He had to carry punch cards back and forth. The others, great programmers of the time like Alan Kay, John McCarthy; got the ‘modern’ time-sharing systems.
“Donald Knuth had that old, punch card computer, but finished his program an hour before anyone else, and his algorithm was the fastest executing. They asked him how he did it so well, and he said, `With that kind of computer, you think carefully before typing. You don’t want to make mistakes, like carving in stone.”
Sounds like your old programming friend has learned that lesson.
Pretty sure he meant it the other way. He doesn't want to work with people who would judge him for typing slowly.
In Visual Studio C# land, long identifiers are compensated by really good autocomplete. Most of the characters on screen aren't hand-typed. Frankly, if we're going to have computer-aided-software-engineering then the computer can damn well do the typing too.
On the other hand, if I can make typing less of a strain, my brain will find better things to do, like thinking ahead. I'll try working without looking down for a few weeks to lose my habit of looking at the keyboard. I've had partial success in the past, but with some keys I never gained the motor skill. The most annoying for me are the keys 9 and 0. I always fumble on these when I try to reach them.
Could someone like Steph Curry or Kobe Bryant be an effective basketball player if dribbling the ball took conscious effort? Probably not.
Code is typed. Typing it slowly slows you down. Just like a slow compiler does or a slow IDE or even a slow computer with spotty internet.
Remove bottlenecks until speed of thought and imagination is the bottleneck.
It's possible that typing is a bottleneck, but I bet if you calculated your actual keystrokes, you'd find that it's very few words per minute.
The point is that you shouldn't need to be particularly fast.
There is a different side of this coin, actually. Having a compiler that takes a really long time to compile the code gives a different type of friction than a compiler that works blazing fast. The former makes the programmer want to avoid unnecessary compilation, which works amazingly well for some types of people (I am this type, so I speak from experience).
Though this doesn't work for a text editor, I believe. Editor should be as powerful and fast as possible, and I wouldn't trade my Vim for anything else (maybe Emacs, but I'm too deep to go back and invest in learning it, only to discover that I got no further than with my current setup).
Edit: Spotty internet connection has its good side, too. One learns to read locally stored documentation instead of relying on StackOverflow, which is a big gain in the long run. Similarly slow desktop computer: if the program runs acceptably on my (slow) machine, it will be so much faster on something better. (Though I only write command line tools and network daemons, so I may be biased here.) All boils down to friction profile, which bubbles different things up to the surface.
Slow typing doesn't capture your attention, if you touch-type. Your hands are typing while you go on thinking.
If you get to the point where typing is the bottleneck you are not thinking enough and you should be working on some more difficult problem instead.
Building simple things that solve real problems pays really really well.
VimSpeak: https://www.youtube.com/watch?v=TEBMlXRjhZY
Using Dragon: http://ergoemacs.org/emacs/using_voice_to_code.html
Using Kaldi: https://www.reddit.com/r/speechrecognition/comments/5p3uxb/p...
This toolkit seems to be the most widely used: https://github.com/dictation-toolbox
Better predictive typing would also be useful. Computer languages often greatly narrow what you probably want to type next, because of scope, for example.
You still want predictive typing, for example. If I want to refactor a variable name, indent a region, or create a class from a template, having a smart assistant that could be invoked with voice would be helpful.
As for people being able to type faster than voice recognition, I think voice recognition at 100 won would be fine for most people:
https://www.ncbi.nlm.nih.gov/pubmed/10166812
It certainly would be nice on my iPad.
If you know you want to type "for.bar(new Baz(qux))" and you have to wait for a menu after ".", after "new" and after "Baz(", the line mat take 6 seconds rather than one.
Even if this is not an issue, most IDEs require you to know lots of keyboard shortcuts by muscle memory to be efficient anyway.
I think there's something to the idea that typing faster could help you think faster when it comes to text, but not sure it applies to software development.
I am convinced, although only based on anecdotal evidence, that a lot of the vim/other-editor vs IDE debate is significantly based on how fast you can type.
2. There are a significant number of programming tasks where the typing-to-thought ratio is relatively high. Refactoring is one. Debugging is another. UI code, or anything with a tight feedback loop to something visual, and particularly CSS, is another. In my experience, the faster you can type, the more likely you are to solve these problems by trying things, rather than attempting to guess what is happening in your head. IMO the former is radically more productive.
3. Slower typers tend to look for GUI tools for things that are probably best used from the command line (git is the paradigm example here).
I am passionate enough about this that I have gone as far as organizing typing speed competitions on my team.
Obviously there are exceptions to the rule. I have also worked with excellent programmers who can barely touch type, although they still suffered from some of the above issues.
There are numerous ways to achieve results here, and typing speed falls behind simple automation in many cases.
Getting a habit to automate away repetitive tasks is, in my eyes, the number two skill a programmer should develop and rely on.
(Number one being relentless improvement of skills.)
I might agree for a few cases of repetitive refactoring, but debugging? Definitely not, that's really something where you spend 99% of your time observing, conjecturing, thinking.
Edit: Oh, I had not read the following sentence with care:
> In my experience, the faster you can type, the more likely you are to solve these problems by trying things, rather than attempting to guess what is happening in your head.
That's not debugging. It's just trial and error until the output randomly happens to be the expected thing. That's a terrible way of doing. Gee... if you don't understand what is going on, you cannot consider the bug is fixed. You may even have introduced more problems than you corrected. What's wrong with thinking to sort the problem out once and for all, instead of rushing anywhere like a headless chicken?
But it seems to be the current method, especially in web development. It probably explains a lot of things about the sad state of those applications.
I can't really think about a problem while I'm typing. I can think, or I can type what I've already decided to type. Worse, the longer I'm not thinking about the problem, the more I lose my place. So for me, typing speed is critical. I need to get the part I'm working on out as fast as possible, so I can get back to thinking about the problem.
Now that said, we tend to justify the abilities we have, and discount the abilities we don't. I'm a very fast typist, so I do have some skin in the game to think typing is important. I suspect that people who are not fast typists also have some impetus to think that typing speed is unimportant.
Nonetheless, I do think what I said above is a factor, at least for some people.
But despite that I still managed about 60 wpm and 95% accuracy on the snippets I tried.
I have a new split keyboard (Kinesis Advantage) lying around that needs some breaking in, so I'll definitely try this.
https://www.youtube.com/watch?v=jslf5hJMtvs
I wish there was a modern sequel so deeply!
http://store.steampowered.com/app/3450/ https://www.youtube.com/watch?v=4Hr6drzeFgs
Maybe there's some artists/developers here that would want to collaborate to reduce the time burden a bit? :P
Nowadays I load the game up once every few months and I tend to beat X-Treme first shot every time, unless I get unlucky with the toxic sharks. It seems you need around 110-120wpm and decent reaction times to finish it.
I ended up switching to Speedtype on Emacs, which I've found to be far more useful, and very easy to add exercise and drills.
https://github.com/parkouss/speed-type
I don't think it's sold anywhere anymore; you should be able to find it on some abandonware website, with a bit of googling.
The menus are in japanese but the text to type is all either in english or at least uses english characters. If you want the proper english version you could try with wine, the tests on winehq seem to report decent compatibility.
http://zty.pe/
http://store.steampowered.com/app/398850/
I've been using it for a few months. Around ten minutes per day, five days a week. It has a few small issues, but overall I would definitely recommend both the site and the habit.
[1]: http://mkweb.bcgsc.ca/carpalx/?full_optimization
If I did lose the use of a hand permanently, I would probably try making a custom map with chording, there's definitely a payoff there.
I'd say it would be worth learning alternative keyboard maps if: A) you work remotely and have a single computer or set of computers you can permanently configure with your preferred layout. B) You're a wordsmith/writer and produce large amounts of textual input as fast as you can type.
I think getting a base touch-typing competency matters far more than optimised layouts, even though the latter can improve comfort/accuracy/speed even further.
In comparison, the text-input methods for smartphones and portable devices need to improve drastically. I find myself getting frustrated whenever I need to input more than a single sentence of text into a smartphone. Using terminal emulators or trying to write technical code/information is a nightmare.
I suffer from eyestrain headaches when I stare at a computer screen for a long time. I can type very fast, including all of the numbers and symbols, but if I slow down just a tiny bit, then I can type quite accurately. As a result, I can type long stretches of text or code without looking at the screen for mistakes.
Because of that kind of eyestrain, IDE's don't really help me. Having all of that info on the screen and requiring me to look at it, just makes it more painful sooner. So I code in a plain text editor. Stackoverflow is my IDE. ;-)
If you use a laptop, bring it with you. If you use a desktop with external monitor, measure the distance from your eyes to the screen.
But if you are currently doing something like getting up close to the display and squinting so you can see it better, don't do that. Instead, pick a distance that would be comfortable if you could see clearly at that distance.
For typical laptop use, this is probably around 20". Maybe a couple of inches farther for a desktop monitor, but measure to be sure. If you use both, maybe stick with the laptop distance since you can position your desktop monitor at the same distance.
Don't ask for a "reading" prescription: that is typically around 16", much too close for most computer use.
Once you know the distance, your optometrist can make a prescription adjusted perfectly for that distance, and you can try out the prescription on the spot with their collection of test lenses.
I avoided doing this for years. I thought I just wasn't the kind of person who needed glasses. Turned out I was, and it was such a relief for my eyes when I could see my screen with no strain.
It's probably much more boring but quite comprehensive for most things.
The real challenge usually comes when you're touch typing and mixing different hot keys and autocomplete functions (vim plugins in IDEs, for example).
If you find yourself bottlenecked on typing while programming, it's a signal that you should stop what you're doing and write some automation or abstraction. Sometimes you can just structure a program so that it requires less typing --- almost always a good thing.
In the rare cases where you need to be verbose in source code, you can use build-time source code generation, or failing that, an editor snippet library. I like yasnippet for that purpose.
Back at Microsoft, NT kernel style requires a big doc-comment before each major function. (These comments are extremely helpful --- but that's beside the point.) The doc comment's style is a bit more complex than Javadoc; there are multiple sections (e.g., description, arguments) and specific indentation requirements within each section.
I found it very annoying to write and format these comments. Instead of just cursing doc comment writing all day, I took a week and solved the problem. I taught Emacs to highlight and indent these comments. I taught M-q to reformat paragraphs exactly as needed. I added code to automatically generate a skeleton description from the function prototype. And after all that, I was never bothered by the doc comment stuff again.
(Incidentally, in a big monolithic IDE, I think the barrier to this kind of extension would have too high to bother with, and I'd have been left cursing this code.)
I recently got a new mechanical keyboard, which had special "layers" for punctuation. "Common" punctuation like periods and commas are still there, but other punctuation like curly braces, brackets, etc. require new key combos. [1]
I agree with you that a lot of the time programming requires modifying rather than composing, but not all the time. In particular, I blog in Markdown, which requires a certain amount of extra symbols that I wouldn't normally be typing. (Goes hand in hand with the previous point).
[1] You might be wondering, "Why get a new keyboard, if you're typing slower with it?" The new one is easier on my hands, wrists, and fingers, as well as being an actual pleasure to use.
Though I'm not a musician I assume it is similar to playing two different instruments.
[1]: https://i.imgur.com/YKojP7B.png
Typing speed is never the bottleneck. You could double most developers' typing speed when they code and it'd probably have a negligible impact on their overall productivity.
There are benefits, but do they really outweigh the benefits of those same hours spent studying a data structure or design pattern or trying new tech?
My typing speed and accuracy are both pretty low, when and if I correct that, I hope to have a similar efficiency gain as I did when I adopted clang-format since I won't be falling out of flow for mundane things like typos. Not every moment spent programming is equal, and in my humble opinion it really helps to invest in making your "special moments" more productive.
Personally I choose vim for the exact reason you choose not to: that is I want the ability to edit files in any language on any system I touch with maximum efficiency. This accelerates my ability to try new languages because I don't need to rely on language-specific tooling. Also, vim has more longevity than many design patterns which are susceptible to obsolescence by new language features, and new languages themselves which have a half-life proportional to their age.
I've also been playing around a bit with Atom lately.
That said I agree that "Typing Practice for Programmers" on "SpeedCoder.net" is a little silly. Just learn to use a keyboard (and learn to spell, that helps too).
I shrug and say I don't type enough to mind.
Cognitive overload. Shell commands with their args ... core syntaxes for half a dozen languages ... a couple base class libraries and 0-2 frameworks for each ... plus all your own abstraction/automation stuff on top? Admittedly this all used to be quite a bit simpler back in a sole "Win32-app world": VisualStudio+MSDN=done, no shell to speak of, no web layer / stack, One GUI Way, etc. But 15-20-years-ago ain't coming back for at least another decade.
"Many years ago, I taught training classes for experienced developers who were learning new technologies (like Java). The disparity between the productivity of the students always struck me: some were orders of magnitude more effective. And I don’t mean in the tool they were using: I mean in their general interaction with the computer. I used to make a joke to a few of my colleagues that some of the people in the class weren’t running their computers, they were walking them. Following a logical conclusion, that made me question my own productivity. Am I getting the most efficient use out of the computer I’m running (or walking)?"
[0] https://www.amazon.com/Productive-Programmer-Theory-Practice...
Back when I was in Windows, the system was so robust that if the static analyzer reported on your code, it was your code that had the problem, not the analyzer. It did bounds checking, nullability analysis, and tons of useful stuff. It's fantastic.
The thing about NT-style pointer typedefs is that they discourage const-correctness: it's enough of a pain to make a PFOO. You want a PCFOO too? That said, I'd be more than happy to live with poiner typedefs if I got SAL back.
BTW, I also used a hacked-up cc-mode that understood all the SAL annotations and fontified them using font-lock-keyword-face. It worked great.
I've been contemplating doing a little project that scans all the SDK/DDK headers for SAL annotations in use and making a big cross-reference where you can, like, click on the #defines in <sal.h> and see all the places where there are real examples of it being used.
Some of the complex uses are really hard to grok just from MSDN documentation alone; I've found looking around at the WDK/DDK headers much more useful.
Unrelated question: why'd you leave Microsoft? Were you doing NT kernel development there? Is that what you've done in the past?
(Edit: for spelling, oh, the irony)
If you think fast typing makes you a better programmer chances are you are a typist and not a programmer.
Which is quite a good speed for typing, and I have _never_ found that to really help me at all when coding. Usually when coding you are still thinking about what to write and the speed at which you write code is never actually hindered by the typing speed that you have.
There are a few exceptions to this, as I like doing live-coding when giving presentations it does help me write the code faster, but I already know what I am going to write to a large degree and people seem to like the live coding.
But for day-to-day programming, I don't feel like this matters..
It's all preference in the end though!
A more expensive keyboard does not make you type better in my opinion, but it does improve the comfort of typing for a longer time. It also depends on what you are used to.
Another one that is fun is typeracer, it let's you race against others by finishing a typing test as fast as possible. These are fragments from literature that you are typing and thus adds some difficulty as well compared to 10-fast-fingers, as you need to keep in mind punctuation :-)
But the thing is that typing fast and accurately feels wonderful. Conversely, it's incredibly frustrating to be constrained by a different layout or hardware.
I can be reasonably fast/accurate on my preferred keyboard, but I can't touch type very well and I envy the fluidity when I watch someone do it.
I have tried a few times to learn it, but the process is infuriating. I'd love to find something a bit more tolerable.
I would agree with that to some degree, but I think typing faster can help the thought process, in the sense that you can write down your ideas faster, so that you can free them from your memory and keep moving forward with your thoughts.
Think -> decide that you need to extract a method -> using the keyboard, and your editor, do that -> think again.
The step w/ the keyboard will involve your custom editor environment, and typing. If you get it done, you can shorten the cycle from Think -> Decide -> Act -> Think, and get into a smoother workflow. If your keyboard and tools need your active thought on how to succeed, you get derailed in that Act step, and have to restart your thinking about the real problem.