Hacker News Reader

Comment by collyw | Hacker News Reader

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.

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.

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

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.

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.

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.

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.

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

Reply on news.ycombinator.com