Typing Practice for Programmers | Hacker News Reader

Typing Practice for Programmers

speedcoder.net

346 pointskryptos1166 comments

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!

Keep practicing. I've used an ergodox for about 4 years with the Norman layout. I am still proficient at qwerty on laptop style keyboards.

Though I'm not a musician I assume it is similar to playing two different instruments.

This is why I went with an Atomic instead of the Planck. Ortholinear, but very close to a "normal" keyboard in the layout.

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.

[1]: https://i.imgur.com/YKojP7B.png

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.

I'm just curious what code editor do you use right now?

I use the JetBrains family of IDEs (IntelliJ IDEA, PyCharm, RubyMine, PhpStorm, WebStorm) and I'm really happy with them.

I've also been playing around a bit with Atom lately.

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.

Actually, this doesn't seem helpful at all. Rarely am I typing the entire program without any autocompletion and intellisense based assists.

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 use snippets, expanders, zen mode etc. Lots of people do too. Typing has never been the issue for programming really.

I'm awful at typing. My friends make fun of my rapid chicken-pecking.

I shrug and say I don't type enough to mind.

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...

Your advice is "drink heavily"? Is this a kind of joke?

If you're a native English speaker, you really have no excuse for not detecting that it's a joke.

I am not a native English speaker, so I guess it just flew over my head.

I think it was a bit tongue in cheek.

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)?"

[0] https://www.amazon.com/Productive-Programmer-Theory-Practice...

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 wish there were explicit pre- and post-condition sections. The pointer-typedef stuff never made much sense to me either.

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:

    typedef
    _Check_return_
    _Success_(return != 0)
    PVOID
    (ALLOCATE_RECORDS_WITH_TIMESTAMP)(
        _In_     PTRACE_CONTEXT  TraceContext,
        _In_     PTRACE_STORE    TraceStore,
        _In_     ULONG_PTR       NumberOfRecords,
        _In_     ULONG_PTR       RecordSize,
        _In_opt_ PLARGE_INTEGER  TimestampPointer
        );
    typedef ALLOCATE_RECORDS_WITH_TIMESTAMP *PALLOCATE_RECORDS_WITH_TIMESTAMP;
    typedef PALLOCATE_RECORDS_WITH_TIMESTAMP \
        volatile VPALLOCATE_RECORDS_WITH_TIMESTAMP;

That allows me to include it in a public struct via:

    typedef struct _TRACE_STORE {
        ...
        VPALLOCATE_RECORDS_WITH_TIMESTAMP AllocateRecordsWithTimestamp;
        ...
    } TRACE_STORE, *PTRACE_STORE;

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:

    Foo = (PFOO)TraceStore->AllocateRecordsWithTimestamp(
        TraceContext,
        TraceStore,
        4,
        sizeof(*Foo),
        &Timestamp
    );

_Use_decl_annotations is a life saver.

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 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.

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 :-)

It's all preference in the end though!

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.

Maybe you need (to make) a typing tutor in 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..)

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.

https://www.youtube.com/watch?v=jslf5hJMtvs

That's second to the best typing game ever made, Typer Shark Deluxe.

I wish there was a modern sequel so deeply!

http://store.steampowered.com/app/3450/ https://www.youtube.com/watch?v=4Hr6drzeFgs

No love for Mario Teaches Typing? https://archive.org/details/msdos_Mario_Teaches_Typing_1992

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!

Is there a version that can be played on macOS or pi? I'm guessing it would be under emulation.

I setup Dreamcast emulation to run TOTD on a Mac last year. It was OK... Not perfect though.

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

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.

Funny, I was just thinking in the shower how you could make a magic based rpg where you need to type words out to cast spells.

ZType is also really fun (and it runs in the browser)

http://zty.pe/

Second that. It also helps me unwind actually. I play this once in a while even though I am a decent touch-typist.

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.

http://store.steampowered.com/app/398850/

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.

Coding by typing fast never seems like a great idea for me.

Isn'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.

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.

Their loss.

One of the best programmers I know types surprisingly slowly. Maybe because he's older and his fingers just don't move very fast.

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.

Eh, I'm not sure you got the point of the story. Good argument, though.

Good, these are perfect indicators that I don't want to work with these people anyway.

Edit: misunderstanding.

I think GP is saying precisely the opposite. They don't want to work with managers that judge their employees by WPM or hotkey knowledge.

> You don't want to work with people who type slowly?

Pretty sure he meant it the other way. He doesn't want to work with people who would judge him for typing slowly.

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.

I struggle when using my colleague's Mac, using the same IDE as my own machine. Mainly because the keyboard layout is different.

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.

That's totally cool. An interview is a two way street. Maybe we are just not a good fit. And that's totally cool.

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.

Why? Has that historically-on your team-proved detrimental? I'm interested to hear the anecdote on this one if that's the case.

Perhaps it's not detrimental, but I can also program on my smartphone without it causing major problems for the end result. It's just super annoying.

It's just a bit frustrating hitting the wrong key? It's not more complicated than that.

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.

It's not about the typing speed, it's about levels of abstraction. You want the basics to be automated so you can think about important things.

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.

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.

Absolutely no one said that you shouldn't learn how to type.

The point is that you shouldn't need to be particularly fast.

> 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

Slow IDE, slow compilation, spotty Internet force you to wait and captures your attention.

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.

> you should be working on some more difficult problem instead

Building simple things that solve real problems pays really really well.

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.

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.

Most fast typers type much faster than they speak. Thus I don't really think this would help.

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:

https://www.ncbi.nlm.nih.gov/pubmed/10166812

It certainly would be nice on my iPad.

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.

To your second point, I think simply encouraging this practice will see benefits.

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.)

> 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.

I don't know if a programming-specific one is needed but you can save a lot of time learning how to touch-type. http://steve-yegge.blogspot.com/2008/09/programmings-dirties...

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'm hesitant to take up any of those because not being able to use other computers seems like too much of an impediment.

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.

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.

I find this a bit silly. It wants me to type a whole bunch of things I never actually type. I could type the python function within emacs with less than half the strokes that were required by the exercise. And anytime I'm doing any sort of programming that ends up being repetitive or with frequent structures that are difficult to type I'll build something to make it a few keystrokes to pop a template.

I think the best practice is putting your skill to use. When I play with a new keyboard style (e.g. Dvorak / Programmer's Dvorak) or editor, I give myself a period of acclimation where I _know_ I'll be slower, but the investment in time will potentially pay off dividends once I get used to it. I've gone down a few roads that didn't work out, but also a few that have. When it comes down to plain old typing speed, short burst typing like messaging or command lines have proven to me more productive than typing exercises that mean nothing to me and don't apply to the things I regularly type.

Regardless, the developers here have put together a nice interface and figured out a good way to apply it across multiple languages. If they added a few shortcuts that are commonly present in IDEs to get real completion strokes I think this kind of a tool might get pretty popular.

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.

Yup, I hit tab a few times, and I also expected it to automatically convert .'s to ->'s.

But despite that I still managed about 60 wpm and 95% accuracy on the snippets I tried.

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.

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.

Unfortunately, in the real world, typing doesn't always work like in the test.

For example I'm a heavy IDE user and I know exactly what kind of autocompletes it will present me when I write something or what kind of shortcuts I can use, which made this really weird to use.

For example I rarely write 'function', I write 'fun' and press enter because I know 'function' will be the first item in the autocomplete list. When I'm writing a variable for the second time I feel the latency at which the IDE will autocomplete me. If there are more variables with similar names I know which characters to type to make it autocomplete the right one. If I have a variable named weirdNamedLongAssVariableName I will write wNLA and press Enter.

This confused me a lot on a subconscious level when I first tried the examples on the website.

I type too fast as it is, I would rather have something that slows me down.

If you think fast typing makes you a better programmer chances are you are a typist and not a programmer.

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.

At the last character (}), I pressed Enter (as anyone would!) which actually resulted in closing the results window before I could read them!

This is really bad for getting better at typing for code in the same way all other typing tutors are.

The problem is that programming overuses a bunch of character sequences that rarely come up in standard english and thus in most of your typing practice, e.g. special characters, and mid-word capitalization. If you want to improve your typing speed for programming faster than you would just writing code normally you have to focus on those sequences.

You would probably want to practice with something that looks more like obfuscated code than beautifully formatted segments. Ideally you could even generate such segments so as to work out your least performant two character sequences while not slowing you down too much by being too random looking. Though even just repeatedly typing "jf" then random characters using the right pinky will be more helpful than this or https://typing.io

This is just silly and misguided.

A great quote from Lambert:

1. Decide what the program should do. 2. Decide how the program should do it. 3. Implement these decisions in code.

Only the last part is actually coding.

In other words, you are not paid for typing fast. You are paid to type as little as possible to solve problems!

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 don't feel that I need it but I thought I'd give it an honest try and follow the instructions. I never realized it but when it comes to curly braces and other keys in that corner "{ [ ] } \". I would take my hand off and use my ring and middle finger. Therefore I was under utilizing my pinky. I also noticed that I tended to use the same shift key for all the letters resulting in weird contortions of my hand.

Doing a quick 1 minute typing test comes up at 90 wpm. However programming, with all the mistakes from jumping around I think brings me down a lot more than this. So I found it surprisingly useful.

I've been touch typing for 20 years at this point and 90 WPM seems crazy to me. I first tried the speed coder site on some Python code and only managed 45wpm. After reading your comment I then went and did a 1 min test on some general text and only managed to hit 55wpm! That said, I've never felt constrained by my typing speed while programming.

er, nope.

  $ curl -I https://www.speedcoder.net/
  curl: (7) Failed to connect to www.speedcoder.net port 443: Connection refused

  $ nmap -p 443 www.speedcoder.net

  Starting Nmap 7.40 ( https://nmap.org ) at 2017-01-29 17:18 PST
  Nmap scan report for www.speedcoder.net (52.36.71.201)
  Host is up (0.066s latency).
  rDNS record for 52.36.71.201: ec2-52-36-71-201.us-west-2.compute.amazonaws.com
  PORT    STATE  SERVICE
  443/tcp closed https

  Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds

Unfortunate. With Let's Encrypt, there's really not much excuse not to support both HTTP and HTTPS.