Hacker News Reader

Comment by dperfect | Hacker News Reader

Honest question: do other software engineers write code so quickly that keyboard efficiencies really make a significant difference in productivity?

I agree that familiarity with a keyboard layout is important, as is familiarity and confidence with a given editor/IDE (frequent switching between keyboards/editors does seem to slow me down a bit), but beyond that, are you really feeling held back by the speed at which you can move characters from your brain to the computer? My own experience shows that much more time is spent just thinking about the problem at hand. Even when it comes time to write, I rarely (if ever) feel like the keyboard input part is slowing me down.

View on HN

It's not just "how much time do you spend writing" but "how much concentration do you give up on your keyboard layout".

If you have to think about how to do the actions to indent, comment and reformat some code, your mind isn't on what you're actually doing at the time, which could be a very complex operation which requires your full attention.

Try to type a reply to this comment, but type it with one finger while looking at the keyboard and see how focused you are on what you want to say.

I find that for the actual writing of code, keyboard efficiency really doesn't matter at all.

Navigation and refactoring are where efficiency becomes huge. I think most of what I type into an IDE isn't actually code, it's navigating without a mouse (Find in files, go to declaration, back/forward, search for a type, etc.). The thing is most of these operations have in common is they're working with a symbol table or an abstract syntax tree though. This is why I like (good) IDE's over text editor's like vim and emacs -- I rarely need to be super efficient writing within one file, I need a program that can understand and parse an entire project. I also don't need my keyboard shortcuts to be super efficient (I don't particularly care if they drag me off the home row or involve multiple modifiers), I just need them to have a high multiplier effect in terms of my time.

Honestly I think the most useful keyboard shortcut I use is also the most vague: alt-enter in resharper/intellij. It's basically just "show me the most obvious transforms in this particular context". So it might transform a type declaration to "auto", or convert a for-loop to a foreach or vice versa.

Nope, it's not about the speed. It is about physical comfort and pain.

I'm 34, and have sadly discovered the reality of RSI over the past couple years (The author's final warning is appropriate). As a result, I've definitely modified keybindings specifically to avoid some recurring painful movements, and I think that's the reason the author discusses the topic, not speed of input.

It's not just about how fast you can push code out your brain, but how fast you can manipulate code in your editor. Uppercase that constant, move subroutine bar to file foo, indent this section, move this code block 'til after the widget is frobbed, etc. These sorts of boring and tedious editing tasks are the ones I'd really like to speed up, and most of them all require the use of some kind of meta key.

It's not just programmers who want to be able to edit quickly, as an ops person sometimes I'm called upon to bang out and edit a lot of UNIX shell commands. Sometimes I'm doing this in tense SEV-fucking-0 situations where being able to edit and type quickly has a real benefit.

As an emacs user, my shell editing commands, editor editing commands, and text I type into GUI OSX text widgets all use the same control/meta key editing sequences. I also use a Kinesis, and use the two largest keys on the left 'thumb island' for control and meta. When I'm away from my Kinesis I use caps-lock for control and ESC-[ for meta.

I think some of this comes down to tool quality. I more or less never do the kind of repedative tasks that that your talking about.

For me, at least, it's not so much a "raw LOC output" thing as it is a comfort thing. When I go back to IDEs or text editors that aren't Emacs, even though I can be productive there are lots of movements and tricks that I miss. It's less time spent text editing and more time spent looking, reading, and thinking.

Rarely, I'll be in a situation where I have to do a series of complex edits. At my old job if we were crunching, some of the people that were junior to me would look over my shoulder and see me rushing through a ton of different files to make them. I think if you're familiar with a tool/setup it's easy to do this, but it's not totally necessary.

> do other software engineers write code so quickly that keyboard efficiencies really make a significant difference in productivity?

For anyone who tries to make their code as small as possible, the idea seems absurd. But lots of other things involve typing, like interacting with a REPL or terminal, or querying data. Typing can sometimes be a limiting factor there, especially when working with tools whose verbosity you don't control.

Yes. Absolutely. Without question. As someone who has invested years on the same editor, i have a hard time paired programming with anyone who doesn't have mastery over their editor. Things that can take 1-3 keystrokes instead take 30 seconds. Every moment spent consciously navigating or searching or moving code is time spent not thinking about the problem at hand.

In fact, i wrote an article on this very topic a few months ago because i find so few programmers consider tool mastery a part of programming mastery:

http://blog.benroux.me/editor-as-artbrush/

    Things that can take 1-3 keystrokes instead take 30 seconds.

This kind of editor mastery is oft mentioned, but I've never seen it.

Does anyone know of a good video demonstrating editor virtuosity? Ideally while actually coding - not synthetic examples. Any editor, any platform, any language, etc.

It's not about speed, it's about friction. I used many editors (like TextMate, Notepad++, that kind of thing) before Vim, and once I got into it, I saw the awkwardness I'd experienced in other editors vanish. I probably input code about as quickly as I did pre-Vim, but it's a lot more comfortable now.

It's like a car speeding up and then stopping at every red light vs. the one smoothly flowing up to and through each light as it turns green.

The latter might not get you there significantly faster but it's going to be a much smoother ride.

It is probably more of a desire to reduce the effects of RSI and prevent jumping all over the keyboard. We don't necessarily write code at break-neck speeds, but we do need to use modifiers and special keys more than the average keyboard jockey.

That beign said... typing speed is also important. I've always written a large amount of prose as part of my job (compared to most non-programmers). And not just time-wasting typing at HN, but documentation, job-related emails, etc.

I can't speak for Software Engineers, but as an Emacs user I can say that for me, fluent keyboarding matters. As the fighter pilot tools analogy is a long standing favorite of mine from the AutoCad days, when I am in flow I experience Emacs as a stream of consciousness spojeen in keystrokes. It's very linguistic in a way mouse movements and clicks are not.

One of the issues with mice us their default relative positioning. Digitizer tablets require less hand eye coordination and have a better chance of coming closer to touch typing. But it's still gorilla arms versus ten fingers.

Lately, I've realized that even when I am having to look at the keyboard to get the right key combination in Emacs, it's no worse cognitively than hand-eyeing with a mouse and because my hands are still on the keyboard it's actually physically more efficient and actually creates less context switching cognitive impedence.

A lot of the work is documenting and coordinating, in English like we're doing right here. (I wonder how much missing/outdated/lousy documentation we can blame on the programmers not wanting to type.)

If you type at 60wpm instead of 110, over the course of a career I'll bet that makes plenty enough difference to be worth addressing. (I recently started going over to typeracer.com and keybr.com on breaks, on that theory. We'll see.)

If you really want raw speed then how about using a chorded keyboard and get over 200 wpm? Here's an HN post on Plover:

https://news.ycombinator.com/item?id=8510409

That's a good suggestion, and I've considered it, but it's a much bigger investment to make before it could start paying off. (Also a greater cost in interop with others at their computers, etc.) If I were 20 instead of 45 I'd check it out more closely. (Perhaps I should anyway?)

I think Plover works on any keyboard that supports n-key rollover.

http://lifehacker.com/n-key-rollover-anti-ghosting-and-other...

I mean primarily the learning.

It's not so much coding, and the speed at which I type my keys.

There are other things that make my work on a computer productive. The macros I have setup, my specialized launcher that'll do things based on keywords. The console that's perfectly setup with the tabs / shortcuts I want/need/know, and syncs with my launcher: "console c:\projects\ {enter}" -> does things much faster than a normal person's computer usage.

All these "little" things add up. And like one of the other posters mentioned. Less time having to "worry" about how to get to program X, or switch to task Y, is more time I can dedicate to the task at hand and the flow that accompanies it.

I learned how to touch type before home computers were commonplace, so I get frustrated when I can't close my eyes and type what I'm thinking. Maybe I'm a dying breed. I've had laptops with such difficult keyboards that I've turned them into servers that I can manage remotely, and others that I'll plug an external keyboard into to get a consistent experience. I can use a wide variety of keyboards, but some are just plain bad.

My favorite programming keyboard is an old IBM Model M. So I've been told that the spring action is bad ergonomically for people who type a lot, but I spend a lot of time thinking and only type in short quick bursts, where the spring action is actually quite useful.

So we definitely don't "type a lot" but we do type, and aspects of the keyboard's design can effect these bursts.

I do write faster than I think but I don't think that's the point. Writing without thinking about how to write leaves more brain power to the actual problem you are solving. I spend more time thinking about how to name my variables and how to structure my code and less time about where the \ is or how I get the cursor to the position where I want to change something next.

I don't think anyone buys a Kinesis for speed. It's all about ergonomics.

I was starting to get sore wrists at the end of a day programming, rather than let it get worse, I investigated ergonomic keyboards and came up with this one. I really like it, and my wrists don't get sore anymore.

One simple example: a 's' character sitting somewere in your code because you missed the ctrl key while pressing ctrl s.

Those compile errors slow me down.

Or worse, you were holding down the key, but without any tactile feedback you misjudged the actuation point and disengaged unintentionally.

Reply on news.ycombinator.com