Typing at 255 WPM shouldn't cost $4000 | Hacker News Reader

Typing at 255 WPM shouldn't cost $4000

opensource.com

247 pointstux196873 comments

I was a juror on a court case, and we had a court reporter who typed in steno. Witnesses, lawyers, the judge all spoke fast, regularly interrupting each other -- and our reporter got it all down, perfectly.

It is easy to glaze over a figure like "255 WPM" and not realize how impressive it is. In the courtroom, once I thought for a second about what she was doing, I felt as if I were watching a magician at work.

Some lawyers (from a certain firm?) in Australia are said to be taught. to. speak. really. slowly.

It's clever, because even the dumbest juror will find it uncomfortably slow, and kind of tune out. It has a hypnotic effect, allowing irrational points to be drilled in without anyone realising that it's not quite logical.

Other lawyers will try to talk fast, and use big words, but people are actually incredibly good a parsing fast speech. It's slow speech which really tricks us.

How she envisions stenography would be used for programming:

http://stenoknight.com/WritingCoding.html

Programming is especially suited for steno, because there's so much boilerplate to write again and again, even in an eloquent language like Python. If I want to define a function, I have to type:

def someFunction(arg): stuff.

That's eight strokes just to get started, plus 20 more strokes to write "someFunction", "arg", and "stuff". In steno, on the other hand, you could write something like DFD in a single stroke, and it would put in the def, the space, the parentheses, the colon and the carriage return automatically, then jump you up to the space after the def to write your function name and arguments, then then drop you back down to the body of the function, all in four strokes. Best of all, once you defined that function name in your steno dictionary, you wouldn't need to worry about remembering to write out the name in camel case each time. Just use a single stroke like SPHUPBGS (pronounced "smunction"), for instance, and start thinking of it as just another word, instead of two words mashed together in a lexically unnatural way.

I love the way Vim has mapped a useful command to each key of the qwerty keyboard. It's immensely powerful once you get used to it. But it's only got 26 keys to choose from, and it takes a long time to learn which key does what, since the correlation between "move one word forward" and the "w" key is pretty abstract and arbitrary. In steno, you could certainly keep using just the w key, if it's what you're used to, but you could also, say, map the "move one word forward" command to a single stroke like "WOFRD" (pronounced "woffered"). That's mnemonically much more useful than just "w", and an even bigger advantage is that the number of possible one-stroke commands is almost infinite. Instead of one stroke equalling one letter, steno lets one stroke equal one syllable, which is about five times more efficient quantitatively. As a qualitative improvement, the advantage is inestimable.

An interesting take, though I thought most IDEs have most of those features already? (I personally dislike features that auto-jump me around apart from auto-indent.) It's funny she brought up vim since vim can be made to do those things as well; it's not limited to 26 characters since you can have multicharacter commands in any mode just fine.

I still don't really "get" the syllable perspective but it seems like it's just a mapping of one stroke (I think my confusion is what constitutes a "stroke") on specialized hardware to several on a qwerty board? So I guess you're limited to the number of keys on a qwerty board for single-point-of-entry commands with vim, but you could always use the specialty keyboard and map the output of those as multi-character vim commands... It seems the main benefit is having those mappings done for you and available system-wide.

As far as I can tell, steno works by mapping a "stroke" (a combination of keys pressed at once -- like a chord on a musical instrument) to a "syllable" which appears to be a chunk of a word for prose but apparently can be any chunk of text for things like programming. I think this is why she recommends a 45$ "gamer's keyboard", most regular keyboards have a limit to the number of simultaneous key presses that will be registered. Also it appears that when using a keyboard for steno you still only use a limited number of keys. From the video it looks like she barely strayed from the home position.

Isn't the standard keyboard simultaneous keypress limit already something like 9 keys though?

Keyboard ghosting: https://www.microsoft.com/appliedsciences/AntiGhostingExplai...

Gaming on a keyboard with severe ghosting problems is infuriating, and I'd imagine that steno would be just as painful.

Another description which I found easier to understand: http://www.dribin.org/dave/keyboard/one_html/

6 Keys on USB, if I recall correctly. However, PS2 doesn't limit you at all, and a number of keyboard let you press any number of keys you want. (Typically high-end mechanical keyboards, or gaming keyboards.) A honza mention in his (dead) comment, the technical term is "n-key rollover" where n=6 for USB, and n="n" when it's unlimited.

The newer USB keyboards with n-key rollover don't have this limit. I'm able to depress 22 keys at a time on a Sidewinder X4 ($45) or a Filco Majestouch ($120) connected via USB and have them all register perfectly. Yep, the steno layout is only two rows for fingers, one row for thumbs, and one meta-row for numbers. There's very little movement of the hands required, which makes it both ergonomic and efficient. Chords of 1 to 22 keys are mapped to syllables, words, or phrases. It's a lot like playing a piano.

Zen Coding [1] gives you some of that advantage, by turning many complex constructs into 3-4 character keywords, and placing the caret automatically at meaningful places (some textmate bundles do this too). The approach works really well for CSS and HTML.

1. http://code.google.com/p/zen-coding/

From playing around with it for a few minutes, there's a little bit more to it than that. It auto-inserts spaces between words, but there are some keys which add to the end of the previous word (e.g. one button adds 'es' to words ending in 's' or 's' to other words, or makes a new word if part of another chord). So it isn't a direct one-chord-to-one-string-of-characters mapping.

Not a programmer here, but would you say your productivity is impaired by boilerplate?

I always got the impression the thing that ate up time was compiling, debugging and thinking. Not typing.

Thinking and debugging take up a lot of time, but typing time is still nontrivial and worth optimizing. Especially in debugging where moving around the file quickly is important, vim's movement commands make this quicker.

I do agree that being able to navigate an editor like vim quickly is the determining factor in code writing, however, I do not think WPM is directly related to one's ability to do this. Even though I don't type insanely fast, I can hit a 1-5 key combination in an instant.

Correct me if I'm taking this the wrong way, but I don't think WPM even applies to programming. To audio typers, secretaries, etc. it's a good measure of how well you can keep up.

To a programmer, you can only go so fast when you're not even dealing with human language that has no natural flow, and the quirks of the editor of your choice. Especially on, say, a Mac, where you could be typing a '#' far more times than you ever would in any other situation, or a backtick or pipe.

It's probably telling that we're favouring languages that reduce the syntactic complexity of coding, like CoffeeScript in favour of Javascript, Ruby, maybe Python, Clojure, and the functional languages like Haskell and Erlang. Not just because it's easier to read, but because it's easier to type.

I might just be talking rubbish, of course. But I wouldn't use typing speed as a performance metric for a programmer.

It's not much of a performance metric , but I don't really enjoy typing very much in situations where I have decided what I'm going to do and then have to type it out. I can't generally think and type very well at the same time.

This means for me that trying a random idea I have quickly is much more enjoyable in say python that it is in Java.

Sometimes I want to just try something random in Java but I really can't be bothered to type all the code required to create a new class, handle exceptions and then also do the compile and run.

If I had super fast typing skills or a more concise language I would find much less friction is doing that, this would make my programming time much more educational and make me better in the long run.

It's the fluency that steno lends to composing text or code that's far more useful than the speed. Tab-complete requires that you pause for a short time to read your options while you flip through them. Steno is entirely deterministic; you can implement the command in one stroke without twisting your hands around (unlike metacommands, especially those used in emacs, which can result in the dreaded emacs claw), and you know exactly what the result is going to be. Because you're writing entire words with each stroke, if you accidentally hit the wrong key, you'll be able to reverse the error in a single "delete last stroke" command, rather than having to backspace 20 times to correct a letter transposition error you made several words ago. Qwerty requires commands and variables to be broken down into minuscule portions, with the potential for error occurring each time a key is deployed. Steno reduces that error potential drastically by chunking words and variables into single-stroke entities, requiring less vigilance for error and allowing for a much smoother flow of thought and composition.

Typing speed usually isn't the limiting factor, but being able to touch-type (really touch-type, which allows you to keep your eyes on the screen instead of going back and forth) is extremely valuable: it makes text entry much more natural, and allows you to catch typos.

Visual Studio, for example, has boiler plate snippets, type prop[tab][tab] for a prop declaration, for[tab][tab] for a for loop, fore[tab][tab] for a foreach, etc. There's auto-brace completion and ctrl-enter to add a semi-colon and move to the next line (surprisingly useful with auto-braces). The point being that editors can make boiler plate very easy.

To be completely honest these features don't save much time, even though I use them all the time. As you say thinking and debugging do, compiling not so much unless you're working on a very big project.

Writing fast means you can express the idea in your head before you forget exactly how you figured it was going to work. This is the reason I find most compelling to be able to type fairly fast as well as know the keyboard shortcuts for jumping around (for example jump word in VS is ctrl-left/right arrow).

Revelations can fade fast once you start implementing them.

Compiling is quick in many languages, but you're mostly right about debugging and thinking. However, the key to productivity is to stay in flow, and having to type the same boring boilerplate over and over again tends to take me out of it. http://en.wikipedia.org/wiki/Flow_(psychology)

Someone introduce her to APL.

All of that either already exists as described, or keystroke-count equivalents exist, in every programmer editor. If people aren't using it in existing editors they sure aren't going to pick up a radically different keyboard layout to use it.

(Said the guy who types in an increasingly-heavily-modified Dvorak layout. I recently mapped Backspace to "change window" (i.e., ALT-Tab in most WMs), since I long since moved Backspace to Caps Lock. You can't be much more willing to fiddle with your keyboard layout than I am.)

I'm incredibly excited about Plover - but only for English typing, not coding. I guess for typing strings in code, maybe. But coding? No. The ratio of typing to thought in coding is vanishingly small.

Vim already has the capability to allow pressing a key chord to perform a custom function. Just use the plugin vim-arpeggio at https://github.com/kana/vim-arpeggio. And you can already do something like “DFD” expanding to “def someFunction(arg): stuff” by using the vim-snipmate plugin at https://github.com/garbas/vim-snipmate. That “snippets” functionality is based on TextMate’s snippets feature, and I know Eclipse supports snippets too.

Thus, steno is not necessary for either of the advantages mentioned. However, it still might be good to have the mindset of using tools like vim-arpeggio more, and steno still might make typing variable names slightly faster.

Hmm...seems like it might be possible to use vim-arpeggio to implement steno on vim. Then whenever you're writing prose, turn steno on and type 200wpm in insert mode, while still having all the vim editing features available.

Edit: "Part of the frustration was that, try as I might, I was never able to make my steno software work effectively with Vim, my favorite text editor." http://plover.stenoknight.com/2010/04/writing-and-coding-wit...

I wonder why.

Because all proprietary steno software builds in a 1.5-second buffer between when the stenographer enters the stroke and when the stroke is transmitted to an external program. Imagine having to wait 1.5 seconds for each command to execute. It's infuriating. Plover is the only steno software that uses a length-based stroke buffer rather than a timing-based one, so it sends commands immediately, making it work beautifully with Vim and every other external program I've tried it with. The difference in usability is startling.

Ah, ok. I was actually thinking of something different: implementing steno chords in vim itself, instead of hooking it to an external program like plover. Since vim-arpeggio already handles simultaneous keystrokes, it seems it'd mainly be a matter of importing all the chords into vim-arpeggio.

But I didn't know anything about steno before today so I'm probably over-simplifying. And it's pretty interesting that plover can work with vim...I'd love to see a blog post or screencast showing how that works.

http://stenoknight.com/plover/ploverdemo/ploverdemo.html

In-browser demo of the software.

http://i.imgur.com/iKqk9.jpg

I thought HN was meant to be pretty much meme free...?

Actually, that was pretty good feedback :)

Ah, I forgot to post the tutorial link! http://stenoknight.com/wiki/Quick_References

Also useful: http://stenoknight.com/plover/qwertytosteno.png

This is actually going to remain a problem until computerized speech-to-text is solved. And I'm pretty sure speech-to-text will not really be solved until generalized artificial intelligence is solved, so this will be quite some time.

Even with perfect room-of-people-interrupting-each other text-to-speech, there would remain one important use case - writing down own thoughts. Maybe also descriptions of live events where a lot happens at once?

My thoughts exactly. To understand what was said you often have to understand the context and the intention. Otherwise you have no chance at decoding garbled sounds people make even with you carefully optimized meatware.

Perfect text to speech also needs true AI that understand the text it is reading it's context and intention. Reader must understand the message to read properly.

Thank you! It's so refreshing to talk with coders about this stuff; non-computery types so often assume it's a solved problem, because they don't realize how lossy a format spoken language actually is.

According to what I'm reading, speech is only about 180 WPM and steno can be 240-300 WPM. Speech-to-text will actually be less efficient than steno. And for me, typing 1.25 million words of English per year (in technical translation, mostly from German) - if I tried using speech-to-text my larynx would be burnt out in a month. No way. I've heard some people get mileage out of it, but not me. I'm learning me some steno, starting today.

I can't tell if you're joking or not. The point of speech-to-text is not necessarily efficiency, it's also for subtitling and/or recording normal speech (i.e. phone conversations, or TV screens in public areas)

Ah. Yeah, for that it's obviously going to be the bee's knees except for the whole AI-completeness issue. But for me it's useless; I look at German text and type English text, so the issue really is throughput. (Mostly.)

So no, not joking at all. Just talking about a different application.

I already type way faster than I can compose code or prose. 255 WPM would be pure stream-of-consciousness, but I suppose that would be nice to have in some situations.

So do I, in 80% of the cases. However sometimes I think faster than I write, in which case writing kind of gets in my way.

250WPM is at least 2 times faster than I write. That's surreal.

I had the same thought. Maybe for short burst where something is well thought out in your head and all your doing in transcribing. For most coding I find my typing to be more than sufficient. Maybe for something like documentation (but who writes that anyway?).

Even documentation, if you want people to actually read it.

So it's emacs as a keyboard driver? Seriously, being able to chord more efficiently would be awesome. I wonder how integrating emacs and stenography would work.

I use http://www.emacswiki.org/emacs/key-chord.el to great effect. Lets you bind arbitrary commands to arbitrary keystrokes. For instance, I have switch-buffer bound to Z+X, which is just a short distance away and more efficient than C-x b for my tastse.

Wait... 98% of deaf and hard-of-hearing people don't know ASL?

I can't verify this claim, however I would guess that the "and hard-of-hearing" part is a big factor. I have a suspicion that the number of people we would refer to as deaf is dwarfed by the number of people who are 'hard-of-hearing'. Additionally the actual quote only claims that this percentage of people are not fluent. I would guess the most people born without the ability to hear have learned to sign fluently, I would likewise guess that most people who become even severely hard-of-hearing later in life get by on closed-captions, lip-reading, and basic knowledge of signs.

The problem with sign language is that it doesn't do you any good unless everyone else speaks it, as well. Sure, there might be special services for the deaf where they can expect to be able to converse with someone in ASL, but for the vast majority of their interactions they will be dealing with people who don't know it. It then becomes something of limited use.

It's as if there were a programming language that greatly improved your productivity, but was only available for SPARC boxes running Solaris. Sure, the few times you were able to use such a system, it would be great. But how many programmers would bother to learn a language that they would use so infrequently?

If the hypothetical language actually were that much "better" than existing languages, hackers would flock to it in droves. SPARC boxes running Solaris would quickly become the new AWS boxes running nginx.

Right, and perhaps it's a poor example. That was, in fact, the first counterargument that I thought of when I wrote that comment. I was trying to think of something that would be intuitive for the audience here, and perhaps in pursuing that goal I made a poor analogy.

The point is, ASL must be a language first, and an aid for the disabled second. On that point, it fails. The goal of a language is to enable communication; if less than 1% of people you are likely to interact with are capable of communicating in that language then it is of limited utility. People who have normal hearing are generally not going to learn ASL, as the value proposition just isn't strong enough. Because of that, even people who have hearing problems might not be incentivized to learn it, for the same reason: it just might not be that useful.

Now, as with any group, a shared language leads to shared culture and a sense of belonging. That, in and of itself, will make ASL attractive to many people. That's fine. It fails at its intended use as a primary means of communication however, as it just doesn't let you communicate with that many people. This, I think, is why many deaf people also learn to lipread: it allows for communication outside of the (relatively) small deaf community.

Canonical counterexample: Symbolics Lisp Machines.

Spot on. ASL is a really beautiful language, but it's incredibly difficult to learn, partly because its grammar is spacial rather than linear, which can be a real mindbending experience for speakers of oral languages. I've been learning it for three years, and I'm still only conversational; nowhere near fluent.

Source: http://research.gallaudet.edu/Demographics/deaf-US.php

http://www.hearingconnection.org/hearing_loss_statistics.htm...

2% is actually a little generous based on this data, but I like to round up. 35 to 36 million people report some degree of hearing loss, out of around 311 million people in the US, or about 10% of the population. In 1972, an estimated 642,000 people signed ASL at home, and about 375,000 of those were deaf. It's somewhat likely that the number of signers has gone down since then, due to the decrease in rubella (a significant cause of childhood deafness), the oral deaf and cochlear implant movements, et cetera. It's unlikely that the number of signers has increased. So assuming there are still around 375,000 deaf/HoH signers in the country, that's 375,000 out of 35 million people with hearing loss, or just about 1%. I put the extra percent in there for wiggle room.

I wonder how this compares to switching to a Dvorak keyboard. I tried that for a while and was much faster (my vi keyboard motions getting screwed up is why I switched back).

From http://stenoknight.com/plover/:

  This means that stenographers can enter text at up to 300 words
  per minute (the world record is actually 360, but that's an
  outlier), making it the fastest and most accurate text entry
  method currently available. By comparison, top qwerty typists can
  do 120 WPM, top Dvorak typists around 140 WPM, and voice writers
  dictating to voice recognition software top out around 180 WPM.

As an aside, I use vim under Dvorak without too much trouble. I find that reciting the letters of keyboard commands in my head while executing them keeps them from becoming pure muscle memory, and I am able to do the same recitation when I need to work on a Qwerty keyboard.

I'd like to share some products and techniques which have helped me deal with daily intense computer use:

I learned to type Dvorak and did so for months. It got to match my Qwerty, about 100 WPM. I didn't find that it provided much advantage overall.

Note that you can type Dvorak on most modern keyboards with software settings -- in Windows for example, you can just change the key layout and it will start acting like a Dvorak keyboard.

The best advantage I got from learning Dvorak wa san opportunity to re-learn proper finger positioning. As a result, my form in Dvorak is better than Qwerty (which developed organically and is not correct). I never saw much of a substantial overall improvement, despite months of use. If you'd like to speed up your typing, look to improve your finger positioning (primarily: not taking the index/middle fingers away from the home row under any circumstances).

The biggest disadvantage from Dvorak is that it moves characters such as Z,X,C,V. I was not able to effectively re-learn the "undo cut copy paste" commands. I was not able to find a good way to categorically customize them across applications (which is really disappointing -- why can't the OS handle mapping physical keys to common logical commands like undo?)

In the past year I got a Kinesis Advantage contoured keyboard: http://www.kinesis-ergo.com/advantage.htm - once I got it, what a breath of fresh air!

It took significantly longer than Dvorak to learn, because Space/Delete and all the control characters move to your thumbs. However, I was eventually able to achieve about a 25% speedup. Their customer service was also good.

The keyboard is arranged so that finger movement distance is reduced. I feel much more "flow" typing on a Kinesis. The keys roll off your fingers in a long, continuous, fluid stream. Despite the long learning curve, if you type daily for your work, I highly recommend making the investment.

I also highly recommend the 3M ergonomic mouse: http://solutions.3m.com/wps/portal/3M/en_US/ergonomics/home/... - together with the Kinesis, these two products and a standing desk entirely resolved some minor repetitive stress problems I had developed through years of daily intense computer use.

I found that I needed to keep a regular mouse and keyboard for gaming and precision applications. My use of the 3M mouse has never approached the level of accuracy of a normal mouse, since it is deliberately designed to use the larger, stronger, but less accurate muscles of the arm to move it (rather than lower forearm/hand). But importantly, it has freed my hand from any repetitive stress problems.

For precision mouse work, I prefer the Razor: http://store.razerzone.com/store/razerusa/en_US/DisplayHomeP... - I was skeptical about Razor products initially but took the plunge a few months ago. Razor's mouse is really excellent and has perfect feel. It really is an improvement on the standard vanilla office mouse. I think it has high measurement accuracy, and they seem to have greatly tuned the way velocity/acceleration/jerk translate into cursor movement; the cursor more closely matches my intention than with other mice (as rated by performance on http://dagobah.net/flash/Cursor_Invisible.swf ). My favorite "regular layout" is Das Keyboard: http://www.daskeyboard.com/

(I have no affiliation or commission with any of the providers of those products; I'm evangelizing them purely as a satisfied customer.)

Colemak was designed explicitly to get around this problem. http://colemak.com

“… why can't the OS handle mapping physical keys to common logical commands like undo?” Sadly, Mac OS X can’t do that either, but it does include two solutions to the problem you described where Z,X,C,V are in different places on the Dvorak layout.

One is that it includes a keyboard layout called “Dvorak – Qwerty ⌘”, which lets you type text in Dvorak but switches to Qwerty temporarily while the ⌘Command key is held down. For instance, “⌘Q” according to the Dvorak labels would actually execute “⌘X” for cut, but you can still type a q by pressing the same key without Command.

The other solution is that it lets you globally remap keyboard shortcuts of menu items, in System Preferences > Keyboard > Keyboard Shortcuts > Application Shortcuts. To fix Undo, for instance, without using the Dvorak – Qwerty ⌘ layout, you would add a new shortcut for “All Applications” with Menu Title “Undo” and Keyboard Shortcut “⌘;”.

Is this worth learning for programmers?

Getting up to typing speed of 100 WPM on steno reportedly takes you six months to a year - so almost certainly not.

Ask me again in six months to a year, though.

It takes students in vocational steno schools six months to a year. As of now, they're our only source of hard data, because steno has been financially inaccessible to people not pursuing it as a career. My hunch is that a steno tutorial game will produce significantly quicker results than the current steno school dictation model, and that programmers (and other technical types) will likely pick up steno skills at a much faster rate than the average person currently attending a steno school.

Speaking of steno schools, I've read that they have something like a 90% drop-out rate. Learning stenography is not easy.

True, sadly, but it's also unfortunately true that a lot of people in steno schools arguably shouldn't be there, because they don't have the technical or language processing skills that stenographers need to do their jobs. Virtually all those skills are possessed by coders -- especially the ones who play video games and have honed their hand-eye coordination -- so I anticipate a much better success rate among geeks than you can find among steno students, many of whom have an unrealistic idea that steno is a low-skill, well-paying clerical profession.

Izzat you, Mirabai?

Yup! Ploversteno = Mirabai Knight, cofounder of the Plover Project, professional stenographer and novice Python coder.

Based on your knowledge of English, is the phrase "pie nearing" likely to come up in conversation as often as the word "pioneering"? No? Then setting the outline "PAOI/NAOERNG" to "pioneering" is probably safe. Still, this kind of probability check needs to be done whenever defining a multisyllabic word in a steno dictionary, and the decisions are not always as clearcut as "catalogues" and "pioneering".

Really? In the days of Google, there's no clear and widely accepted answer to questions like this?

That's a particularly clear-cut example, but what about something like "my great" and "migrate"? 33 million hits for one, 37 million hits for the other. They're both pretty likely to come up, so it's important to have separate strokes for both. On the other hand, what about "mycolic" and "my colic"? Mycolic has more hits, but it's also a more specialized word; if you're not captioning in a scientific setting, you're very unlikely to hear it. On the other hand, while a phrase like "my colicky baby" appears less frequently on Google, you're more likely to encounter it in general conversation than you are a specialized word like "mycolic". So a lot of these decisions depend on the context in which you're likely to use them. They can sometimes get tricky.

I see in the tutorials that you have bear (BAER) and bare (BAIR). Has it altered your pronunciation of words so you try to pronounce the difference? Does it cause problems when captioning people with strong accents?

Not really. When I'm in steno mode, it's like I'm speaking to myself in a different dialect, but when I'm in English mode it's all normal again. Like, this is how I would pronounce the previous sentence in steno:

When I'm n stoin mode, ts like I'm speeg to mysef nay difrt dailect, but when I'm in glish mode ts aul nol sgen.

-- Sometimes I tell people "I can type 240 words a minute" and they're like "Yeah, and? Who cares?" but sometimes people are like "Dude! That's so awesome! I wanna do that!" and that's when I think this thing actually has a chance."

I am firmly in the "Dude! That's so awesome!" camp. I will definitely be trying Plover.

Reply on news.ycombinator.com