A stenographer's keyboard is a special kind of chord keyboard for spoken English.
There are other kinds of chord keyboards, but look into those.
For example:
- https://www.charachorder.com/
- https://github.com/davidphilipbarr/Sweep
Related:
I would imagine that programming languages need another vocabulary and you will also need to deal with LongVariableNames, delimiters, tabs etc.
I still find it pretty humorous that I can't really find any of that information on how this works on these websites. There must be an intro somewhere that they could link to!
Looks cool though and I respect the innovation.
I write all my code using plover, but I am not a professional programmer. I use emacs most of the time. I use this dictionary for my symbols https://sammdot.ca/steno/emily-symbols.png, this one for typing almost any shortcut combination with my left-hand https://github.com/Abkwreu/plover-left-hand-modifiers/blob/m..., as well as this http://www.openstenoproject.org/stenodict/dictionaries/cross... for moving the cursor around and selecting text. The emily-symbol dictionary is fairly popular, and most users will have some set of dictionaries for shortcuts and movement.
Its worth noting you can type single letters, so if you don't know a word or don't care to learn it, you can still type the word out. You don't have to memorize every single word.
It’s awesome just how fast and accurate they can be, and most devs were of my mindset “wow can I learn to type like that - it woukd solve this problem and that”
Till we found out just how much work is needed to get good. It’s a true skill, and sadly undervalued but something that just has too little pro for the cons - in my opinion as a developer.
I already type at faster than I can code, and slightly slower than I can write English. A better keyboard, or the same keyboard at different workstations and laptops, or some typing tutorials woukd help me - but full on 100wpm is not going to help me debug Kerberos failures
But it hasn’t prevented me from writing thousands of pages of prose, and millions of lines of code.
I think it has probably also saved me from RSI. I have a friend that is a master engineer, that has to change their career, because their arms are all screwed up (multiple surgeries didn’t fix it).
The RSI is not because of movement, per se, it's because of repetition of the same moves (Thus, the "R" in "RSI").
Trained touch-typists keep their back straight, their arms at the same level, and basically only move their hands and wrists; always alternating between the exact same positions. I suspect that "extra-clicky" keyboards, which require a bit of force to actuate, don't help.
It's highly efficient, and I have always been in awe of really good touch-typists. Most don't get RSI, and I'm not sure what the difference is, with the ones that do.
I've been trying to learn steno on and off for 5+ years. The problem is I already have 150 WPM on qwerty and I cannot think of a message on Teams faster than I currently type. The opportunity cost is far too large to justify unless you need to transcribe someone else's speech.
I can’t really relate to “I need to type faster!” programmer optimizations, nor complaints about things like static typing slowing people down because it’s a few more characters (more thinking, I’d get, but some folks do seem bothered by the extra keystrokes) since input speed is nowhere near being my bottleneck when I’m writing code.
I suppose there must be people out there who simply think a ton faster than me, and of course some others are much slower typists than me, and for those folks that stuff’s a bigger deal.
Always seemed to me like they'd be terrible for programming with all the punctuation though.
I also need a mouse way too much (and I have shakey hands so trackballs/nipple mice are not viable)
One common loop in programming is "hypothesize, test, evaluate".
If you're exploring or playing around, the quicker you can execute iterations of this, the more likely it is you'll succeed in what you're trying to do.
In that case, stuff like "unused import is a compiler error" or "static typing required" slows down iteration, so gets in the way of rapid prototyping (or whatever).
"Typing quicker" wouldn't benefit the 'hypothesize' nor 'evaluate' parts, sure, but it'd help you reduce the time it takes to test an idea.
For things like this I’d much rather spend the time to improve “quick fix” suggestions in my development environments. The computer can fix the problem much more easily than I can learn a new keyboard layout.
That + a physical inability to handwrite so I've typed virtually everything.
It's kind of useless. I almost never encounter a scenario outside of live transcription where I can conceptualize a character stream faster than my fingers can input the stream into a computer. The only programming scenario where that's an issue is LaTeX during a lecture because it's very verbose in places. I also do competitive debate which has a heavy focus on note-taking; high WPMs are useful there.
But neither of these two things will be important once I graduate university.
I agree w/ others in this thread about the underlying challenges for using a steno keyboard for coding. You basically need to pick a custom chord for every program identifier, keyword or symbol, and somehow make those chords memorable. Perhaps a custom IDE featureset can help, leveraging the LSP or tree-sitter parsers?
Thinking is a lot easier when your output is seamless and reliable though. Nothing sucks more than debugging typos. The code should work, but it doesn’t. You know you did everything right, but it just won’t work.
20min later … oh wait it’s a typo. Fix was perfect just mangled between brain and keyboard.
Double bad when for whatever reason you can only debug on a remote environment and every iteration takes several minutes.
Learn to type fast and reliably. It’s easily one of the highest ROI things I ever did.
I always say that the best code I write, is the code I don’t write.
What would be ironic is getting RSI after you chose to write less code in order to avoid getting RSI.
To the extent it's important at all it's a matter of removing mental load. Anything you have thought of but not yet put on the screen is load.
I would probably fail if I did. Probably avg 40 wpm with touchtyping.
On the other hand, I routinely encounter simpler problems where I can metaphorically "see" a page of code in my head that just needs to be flushed out of my mind's buffer, and I'm waiting for my hands to do the typing. I'm a moderately fast typer (somewhere between 70 and a 100 wpm), and it routinely is a blocker in my flow.
So, your mileage may vary, and I don't fully buy the argument. If one is going to be doing many hours of this activity every day for their life, why not get good at this aspect also?
Writing code does not suite well for this, since coding with completion contains much more punctuation than plain text.
Instead, check out ergonomic mechanical keyboards: low-profile, split, with columnar stagger, preferrably with 36 or less keys. Uncommon keys are behind a modifier key that acts as a normal key when pressed, but as a layer when held (called modtap).
Also you can experiment with non-qwerty layouts, but IME it gives much less benefit than having a layered layout of physical keys.
More info here: https://www.reddit.com/r/ErgoMechKeyboards/
AFIAK all writing-compression methods come down to optimizing for the common--and so much of what we do is the uncommon. We need lots of keys.
I think it's worth emphasising that these small keyboards bring the full functionality of the keyboard to within reach of the hands resting on home row.
They aim to increase comfort by reducing hand movement, and stretching / use of the pinky fingers. This benefit comes at the cost of a (slightly) more complex keymap.
The key thing isn't "less than 60 keys", it's "two or more thumb keys on each hand".
Some of these ergonomic keyboards opt for more than 34-36 keys. (e.g. the Moonlander is relatively popular).
Also, computer source code (whatever the language) typically contains variable names which often are (a) typically case-sensitive, and (b) abbreviated or even single characters. And even the basic syntax of the chosen language may not be easily capturable via phonetic sounds, what with open and closing parentheses, curly braces, square brackets, etc., and compound reserved words with prefixes (such as #foreach in Velocity template language).
Again, IANACR, but I don't see how it could possibly work...
Can anyone here confirm that?
https://www.fortressofdoors.com/stenography-for-programming/...
It was interesting and fun but I didn’t have enough time/patience to get really good at it.
To get good requires both a lot of practice and building up a personal dictionary. Also steno itself is more adapted for transcribing speech than code, which uses symbols and special characters a lot.
https://github.com/openstenoproject/plover
https://www.openstenoproject.org/plover/
An in-browser demo, https://www.openstenoproject.org/demo/
Suggested, loved extensions, https://github.com/openstenoproject/awesome-plover
Chorded keyboard input methods, more generally, are worth looking into.
That's one reason I haven't adopted a Dvorak habit.
Most court reporters use software nowadays that renders their special stenotype skills obsolete.
Often, the benefits from using an improved tool outweigh the costs of it being non-standard.
I really don't use other people's computers that often, but mice aren't that hard to use (just uncomfortable) and I can still type in QWERTY at about 25WPM but I'd have to look at the keyboard a bit.
Trackballs and Dvorak are both more comfortable than their alternatives, but the real benefit is the reactions I get when other people try to use MY devices when they're not prepared lol
On a German QWERTZ keyboard, most symbols are in completely different places, require modifiers, and thus you almost get cramps when typing some keyboard shortcuts. On a “default” English keyboard, they’re easy and the placement makes sense.
What software?
It would need text-to-speech of the same accuracy; for that to be possible (how accurate is that?) I think everyone would have to be properly mic'd.
Also, TTS errors would need to be detectable somehow by the stenographer, or transcripts could go dreadfully wrong.
There are some days with a combo of slow thoughts and a tough problem that my brain can easily be out paced by paper and a crayon or even a quill pen.
I always liked the look of Doug Engelbart's one in the Mother of All Demos. It's very basic, but I'd be quite satisfied with something like that today. He demonstrates it at about 1:40:
Supposedly, he used it to write programs in FORTH while driving to work.
As far as the story goes, he programmed input-only, having no visual or audible way to review what he wrote.
"...and back in the day, we had to chip the edges of zeroes to make ones..."
I would like to be able to take notes as fast as people are talking, though, and for that you do need a chording keyboard.
Sometimes, and more so in certain languages and the way they are used, massive amounts of boiler plate are required. Programmers use copy and paste techniques to do this, which are basically devices for massively amplifying typing speed and accuracy. When you copy 50 lines, and then change five places in the copy, that's faster than typing them from scratch. The editing commands are a kind of shorthand, which gets expanded in the editing buffer.
...but yeah, for actually writing code IntelliSense or whatever just makes it fast enough that if you can touch type at any speed you are not gonna be bottlenecked.
I use a combination of Dygma Defy with its awesome thumb cluster, along with macros for frequent series of letters (think “tion” and such) as well as chords using https://github.com/rvaiya/keyd/ . And I use the Optimot layout because I’m French, for English speakers, Dvorak is probably enough, but Colemak and many other alternatives offer various advantages depending on your usage.
As many have hinted here, it’s absolutely not only about speed. It’s about comfort, both physical and psychological.
Using the thumb is a great way to avoid moving the hands too much because now your pinkies don't have to reach keys on the side which generally causes a slight extension of the hand. After a year of using the Defy, I don't have any form of strain building up in the thumbs, even though I use them quite a lot - but still a lot less than other fingers.
Macros for short series of letters are very powerful in my opinion: it doesn't necessarily goes faster as it breaks the flow of typing, but you have a lot less keys to press which also minimizes errors. The same goes with chords using keyd (I know it’s originally not exactly designed for that usage, but it still works great at least for me) - less keys, less coordination.
Finally, the choice of keyboard layout is critical. Originally I’ve switched from the French Azerty to Bépo because I notices how much my wrists were moving when I was typing in French with Azerty compared to English in Dvorak. There was a huge difference and I could feel it in my bones after long sessions of typing. So yes, choose your layout wisely.
As a last note, typing speed does matter. But it’s not about typing at the 0.001% fastest percentile. Typing speed will not make you really faster, but you just don't want it to slow you down too much. Typically, you don't want to be in the position where your thoughts go so fast that you feel the frustration of not being able to type fast enough and losing some of your thoughts in the process. Besides, for coding it’s much more about having the right tools at your disposal: powerful auto-complete and suggestions, easy refactoring processes, keyboard shortcuts to do everything you need, easy access to symbols on your keyboard/layout, etc. Typing speed is rarely an issue while programming compared to when writing plain text.
Stenography looks like 'high effort, high reward'.
Whereas, bringing keys like backspace, enter, esc, tab to within easy reach of the hands on home row is going to be a big increase in comfort (and I'd be surprised if it was slower).
Programming languages don't have such constraints because the language can be fluid to adopt to the keyboard. A good example is C compared to the much less terse Delphi.
It's not a general purpose character entry method, but it's very interesting.
There you could match the chords to glyphs rather than require the auto complete functionality others have suggested.
We'll see if I can actually use it!
For instance, when I was freelancing, I would be hired by people to write code for their websites, in Javascript and PHP. Telling my employers that I wrote the ideal amount of code (none) would not be satisfying to them. They would not be willing to pay me for the code I didn't write. Outside of the SV bubble, that kind of thing doesn't fly.
The HNHEF (HN Humor Eradication Force), like the oft-mentioned-on-HN RESF (Rust Evangelism Strike Force), strikes again!
Foo(l)ray!
generally, eh?
faa--aa--aa--aa--ukk.
I don't know whether to laugh or cry at the ridiculousness of that statement. overall, to laugh, I think, makes more sense. because, according to you, majority wins?
see https://simple.m.wikipedia.org/wiki/Majority_rule
and the downsides mentioned there.
that means minorities should not have any voice? their voices should be suppressed by downvoting or criticizing them for not toeing the "generally" (sheesh!) accepted line?
then how is this different from any other form of discrimination, such as racism, sexism or ageism?
can we call it old-boys-club-ism?
you miserably fail to convince, right at your first sentence above, bro. but that's par for the course for the many HNers of the hive mind / echo chamber kind, who think that everyone else needs to think like them, or else they are considered the wrong type of people, and try to brain wash them into thinking differently from what they already do, as you just tried to do above, or by knee-jerk reflex action, downvote them. I have seen that pattern often on this site. and it's not just me, others have commented about it too.
because, you know, generally, it is considered that people should be tolerant of others' opinions, unless they are dangerous or something like that. and how is making a few innocuous puns, even if they are not "clever", dangerous?
I bet you don't agree with that statement.
but, and this is my key point, by the way, did you see what I did there with my use of the word generally?
I used it in the same discriminatory way as you did.
still editing, to make any wording changes and check for typos.
That being said there is some [support for stenography in the QMK programmable keyboard firmware](https://docs.qmk.fm/features/stenography). I’m not sure how widespread its use is.