Hacker News Reader

Comment by hackcasual | Hacker News Reader

I never feel while programming that I'm bottlenecked by my input speed.

This! I've been developing for over 20 years. In my experience, it's never been the case that typing speed or keyboard fu has been the bottle neck for that development.

I agree. I was asked in an interview how fast I type. I didn't know how many WPM, but said "Average - maybe even kinda slow". I followed up with a similar thought - I tend to spend more time thinking about the correct solution, finding the right spot in the code than I do typing. I got the job. I've had the reputation at every job as someone who can get things done quickly so it must not hurt too much. Knowing what to type is way more important than how fast you can lay it down. Of course, having both would be ideal.

> I never feel while programming that I'm bottlenecked by my input speed.

I do; it's not a long-term limiting factor, of course, but when an idea crystallizes it's a short-term drag sometimes.

My input speed definitely is my bottleneck when writing down the code I have constructed in my head. So why not optimize this part of programming?

Learning to type at 90wpm or so should do the trick.

I type at least that fast, and the keyboard is still a bottleneck for me sometimes.

When using emacs/vim and primarily using the keyboard, there are extra gains to be had by typing faster, because you can use keyboard shortcuts to navigate, find text, etc.

Unless you're playing a videogame, it's unlikely that you'll practice or improve on your mouse coordination and make significant gains there.

My input speed definitely is my bottleneck when writing down the code I have constructed in my head

Same here. Never learned to type properly and this happens often enough. I can't count the numbers of times I thought 'man, if I'd just have a brain-machine interface which would tranlate my thinking into text this thing would have been done 10 minutes ago'.

I think this often as well.

And I have actively practiced my typing to try to reduce this pain. I am stuck at a sustained speed of about 55 WPM, much slower than think. In bursts I can get it much higher, but not for a whole C++ class or lengthy function. I know it shouldn't annoy me but it does that my father, who is practically retired and has has never coded types at like 80 and this while in the military of all the unlikely places.

My bottleneck is usually how many things I can hold in my head at once. Getting things out of my head before I forget them and have to start over is not entirely about input speed, but it does have a significant effect.

This is probably the best take I've seen on the issue. Well put.

I do sometimes because my only to the computer tends to happen very unevenly, in bursts. I ponder things for a long while, then when something clicks mentally, I want to get it typed in as fast as possible before I lose it.

In my experience, only a small fraction of the time editing a program is spent "inputting" as opposed to editing.

If you see the brain as a multi-stage somewhat parallel pattern matching engine, I wonder if the speed of reading is limited by the mechanical capabilities of the eyes or by brain speed itself.

If it's the brain that's the limit then a computer <-> brain interface will likely be equally slow (or it has to bypass the pattern recognition parts of the brain, which is to say.. most of it)

Studies (that I don't know how to look up and probably am remembering wrong) show that the eye jumps forward and back while reading. It is easy to use eye tracking to figure out what word your eye is looking at. They used some scheme to figure out what word subjects were reading, and blurred the rest, and it slowed reading down when the next two and previous words were not readable.

Thus the limit is not mechanical as the eye is moving faster than the brain to feed both the current word and preprocessing of the next few.

Very true. People talking about how vim is so much more efficient than me using VSCode with my "slow" mouse inputs and I'm just thinking about how my brain is the biggest bottleneck of all - it completely dwarfs keyboard and mouse bottlenecks.

The slowest and most time-consuming thing is not writing code, but reading code. And vim, for me, optimizes reading a code base distributed across large numbers of files. I can be anywhere I want in seconds.

I know other editors also have fuzzy file finders and text search, but damn does it just feel good surfing text objects at the speed of thought!

I agree 100%. I also feel like vim helps me stay in flow by providing a frictionless input environment. The way vim edits text is pretty close to the way I think about text. "change these quotes", "delete until that >", etc.

VSCode has a great Vim plugin these days and even without it, a ton of good key shortcuts. Not that maybe you need them today, but options if you need them.

I think that's probably the best summary here: it's great having options.

Also, speed isn't the only bottleneck to worry about. It's easy to forget about things like ergonomics. Things like hand movements in mousing and back and forth between mouse and keyboard can slowly take their toll. Again, it's great to have options to control the overall amount of movement.

Awww, thanks.

(One of the developers of VsCodeVim here.)

It never should be. If it is you're probably churning out some really crap code, and you should stop and think about what you're doing.

If you're cleaning up some really crap code, input speed becomes an issue. But I do agree that well-factored code makes for less typing, though navigation speed can be very important.

Reply on news.ycombinator.com