Typing speed? Not sure how much code people here write per hour, but I doubt typing speed is a real issue (the ratio of my staring at the screen thinking versus coding is probably 10:1).
Typing speed is important for the reason the article mentions -- micro-interruptions. Most of the time, you just have to type a few words, and the editor will complete the rest for you. Fine. But a lot of the time, you are typing a symbol for the first time, and autocompletion doesn't really help. It breaks your flow if you can't type this symbol quickly and correctly the first time. (It is also worth pointing out that I can type most words faster than it would take to cycle through potential expansion candidates, so I only use it for moderately-long identifiers. Abbreviation expansion becomes less of a time saver when you learn to type more quickly.)
Anyway, a few months ago, I decided I would learn to properly touch-type (and increase my typing speed). It was very difficult at first -- I couldn't type at all, and even simple programming made me really mad. A few months later, I can type significantly faster, and I make many fewer errors. (As an aside, I don't think touch-typing was really designed for programmers. All the important symbols end up under your pinkys, which is not very comfortable. So I compromise and type some symbols like ()- with my ring-finger. This probably reduces speed, but it doesn't hurt my hand.)
The common response to typing is "programming is not about typing, it's about thinking". Sure, that's mostly true. Nobody expects you to sustain 120 wpm typing for eight hours a day. But, it's very helpful to type quickly in bursts, to get your ideas in to code form as quickly as possible. Sketching out that idea in 2 minutes instead of 3 means that your brain has more time to think about the problem, and has to waste less of its time babysitting your fingers. I know I get mad when my typing speed is delaying me from trying an idea as quickly as possible. That's why I decided to do something about it.
I'm glad I spent the time to practice typing. It has made programming and writing more enjoyable, and didn't take much time or effort at all. The dismissive attitude of "programming doesn't require typing skills" is extremely naive.
The dismissive attitude of "programming doesn't require typing skills" is extremely naive.
Shrug... Well I say that because that's my experience. I've never really been concerned with micro-interruptions. I guess I'm surprised this bothers people so much (It's the macro interruptions that hurt me more). I've been in situations where I've been unable to type (or type quickly). I learnt and grew as a coder more in those times that any other - so a different experience really.
So, yeah, typing is great. It's a very handy skill to have. It probably helps a coder a lot, and it's a good thing to know. However, I don't think it makes you a better coder.
You're wrong. Learn to type well and then come back and tell us it didn't make you a better programmer.
If you don't know how to type, then you're wasting brain cycles looking for keys when you have to type, cycles that would otherwise be spent thinking up good identifiers and nice function names. Not knowing how to type also means you'll choose terse identifiers rather than clear ones because it's too much work typing longer names.
Typing well is a critical skill for a programmer and the only programmers who don't think so are the ones who can't type.
I "type" most words when I'm programming by hitting two or three initial letters, and then pressing M-/ to complete (emacs does that by scanning all open buffers for something that matches, usually quicker than anyone could type the whole word).
I don't choose terse identifiers, I choose long ones that I know emacs will be able to find completions for easily.
Typing faster helps everyone. Programming is more than just writing code. It's communicating with people, documenting bugs, documenting code, etc. If you're telling me you never run into a situation in which being able to type faster would help you, then I'm saying I don't believe you.
This very conversation is easier to have if you can type your thoughts as you have them whilst not being distracted by hunting and pecking.
What about the cost of not learning it? Like potential neck pain, slower thinking, over-reliance on code completion (it takes your brain some processing time to decide what will be long enough to produce the right completion but not too long to waste keystrokes), less ability to communicate effectively.
And the cost of learning it is laughable. You just have to practice a bit for 3 days to learn to get the right fingers on the right keys from memory. The key to learning quickly is that you try to reproduce some text on the screen while NOT LOOKING at the keyboard, and you go as slowly as you need to avoid looking up (well, down), it doesn't matter if it takes 15 seconds for one keystroke at first. The important thing is to try a recall from memory at all costs before you finally know you've really completely forgotten and then look it up. And you do like this for each letter. You'll reduce your latency and learn the whole layout quite fast. After that it's just a matter of practicing for a few weeks and you'll be up at a reasonable 30wpm in no time.
If you don't have to look at the keyboard then you know how to type. Don't get hung up on whether it's proper or not. When people say someone doesn't know how to type, it explicitly means they have to look at the keyboard.
however, as a programmer who does have to type a lot, using the correct fingers would help you in the long run because at some point you will have repetitive stress problems, so bit the bullet and do it. The cost is tiny and certainly nothing to fear or put off.
Do you really spend that much time typing? I spend most time thinking :/
Obviously there's a lower bound, if you have to look at the keyboard then you probably need to improve, but the importance of being able to touch type perfectly is overplayed.
Guess what, if you typed faster you'd spend even less time typing... or, you'd spend just as much time typing but would produce more. Or a bit of both.
It could be that those who don't think so are people who already type fast, and so never notice much of a difference.
I'm in the "typing speed makes no difference" category. However, I already typed 80+ WPM when I started programming (thank you, AIM and MUDs), so I really have no comparison for what it's like to type slowly, except for the couple weeks I spent learning Dvorak. It's really odd for me to look at this thread and see people talking about bringing their typing speed up to 60 WPM.
I could imagine that typing speed would be a problem if you're stuck at 20 WPM or something. I just assume that anyone who does anything significant with computers is at 60 WPM+ already, and at that speed, it really doesn't make a huge difference.
That reminds me of the reasoning behind wanting faster processors in our personal computers. From one (mistaken) perspective, you could argue that there is no justification for buying a faster processor because it will just be idle for more than 97% of the time you use it. The better argument is that we are justified in desiring a faster processor because the length of the CPU bursts is a much more important metric.
Learning vim (edit: or emacs) is another step in the same direction (less transition to the mouse.) I agree that raw typing speed isn't that important. What I like is being able to see what is in my mind show up on he computer without too much hassle, so I can focus on a) perfecting my mental model of how the system behaves and b) creating a new model for the system.
Programming isn't about typing. Therefore, you shouldn't be sitting there thinking "how do I type this"? Typing being second nature frees up more time for thinking.
There are at least two people who I'd dub "great hackers" who type essentially, two fingered. One of them suffers from horrible RSI (but, at one point, had the company hire someone to be their hands).
The other didn't grow up around computers/type writers (growing up in the 1940s/1950s in Soviet Union), didn't really heavily program until after graduate school and for the first decade mostly programmed by writing code on paper and having it punched onto cards.
Gah - when I was out of school, they could have paid me minimum wage and I'd be thrilled to take a job to be a great hacker's "hands." I can't imagine many better ways to see a master work.
There was a guy I worked with who was one of the most productive people on the team and a great coder. He could type fast, but not by touch - hunt and peck all the way. When he had his ergonomic evaluation, after seeing the way he typed, the evaluator recommended he try voice recognition software. He didn't.
I knew a guy who was wheelchair bound with no use of one hand and the other only semifunctional, able to peck out keys one at a time.
I can't claim he was a great hacker, but he managed to hold his own on the team and even outperformed some. If he can be competent with that level of impairment, I think it's got to be incorrect to claim all great hackers are great typists.
I believe that corresponds with comfortable familiarity with and proper use of one's tools.
I view a non-touch-typing hacker/coder much like a carpenter who drives nails using a hammer's handle. (The inevitable reaction from both camps: Hey, what's your problem? I'm using my tools to get the job done!)
Typing ability is an effect rather than a cause of hacking ability.
It's not so that you can type code quickly. The bottleneck in coding is always the thinking time, or you're using an overly verbose language.
Typing is important because hackers communicate with one another using a keyboard. I've worked with programmers who couldn't type quickly enough to have a comfortable conversation over IM. It's torture.
If you can't type, it's probably because you're not communicating enough. Hacking is not a solitary activity, and it's mostly not coding.
If the carpenter who used the hammer handle only had to drive one nail instead of the regular fifty, then that might be totally worthwhile (Naturally, this would never be the case for carpentry, but it certainly is for coding).
Not sure I can really argue against the analogy - because you can take it anywhere. e.g. A lumberjack can rip through a tree, but a good carpenter can cut a piece of wood so that it uses the grain, there isn't waste, etc, etc. In the context you're working in, being quicker is never as good as getting it right.
You could argue that a carpenters output is limited by their use of tools. If they can't nail or saw fast enough then no amount of carpentry imagination is going to help.
What I'm saying is that I don't think this is the case for typing and coding. A coder could type quickly and produce reams and reams of really bad code - this is happening every day. Another coder could type 1 wpm and still produce something of immense value every day.
"A coder could type quickly and produce reams and reams of really bad code - this is happening every day. Another coder could type 1 wpm and still produce something of immense value every day."
Huh, ok. Now, if you take the 1 wpm programmer that produces great code and teach him to type 50 wpm, what happens?
I claim there is no programmer in this world who wouldn't end up more productive (be it by a small or huge margin) if he learned to type faster. And given the ridiculously small ratio of effort to rewards at the lower stages (say, below 50wpm), saying it's not worth the effort is like saying buying more RAM or disk-space or bandwidth is not cost-effective today.
Yes, agreed. The play on words was amusing to me (odd sense of humor alert!) It seems there is a lot of ambiguity between the way you and the GP used the word.
Though, this topic got me thinking. Unless you are using speech to text, I think that how you interface with the computer is fundamental to the act of programming. I do not think that abstraction is essential to programming. Much to the chagrin of my abstraction-loving nature, consistent procedural code can be easy to read and follow. For higher-order OOP, an understanding of abstraction and encapsulation is very necessary.
I can understand the "that's not the bottleneck" argument. But the problem with going too far down that road is this: Imagine if you had to wait one second for your keyboard to respond to any key you type (and one second between keystrokes). You could still produce awesome code and be a great hacker, but can you look me in the proverbial eye and tell me that this would not handicap you in some way? Think about the commands you type really quickly on the command line without a second thought. Think of the messages you send off to friends really quickly.
Generalize this to the experience of using the Internet. Since great entrepreneurs are relentlessly resourceful, they can make great things come to pass using a 56k dialup connection, but I'm sure you wouldn't want a connection as slow as that. Why? If you want to think of it in terms of the argument you made above, then it's obvious that the bandwidth is unimportant because your connection is idle for the bulk of the time you spend using the Web.
The important thing is not thinking of this as a comparison between how much time you spend typing versus thinking. It's more about maximizing the responsiveness between you and your computer. The less friction there is during these small bursts of interaction, the better.
"Imagine if you had to wait one second for your keyboard to respond to any key you type (and one second between keystrokes)"
I've had this experience, while traveling I had a really slow internet connection and had to do some work via ssh to fix a server, it was hell...
You go through that experience one time and you learn that being able to automate as much as possible with tools like capistrano and sprinkle for server setup is crucial (it also started me on the path to keep my /etc configuration files on git...)
I personally touch-type maybe 50 wpm but that's for documentation, not code. If you are attempting to create code at the speed that you type, you are insane ... or you will be soon, when you try to debug it.
If someone was lucky enough to think faster than they could type, they'd be able to think twice before they added more code to a program - a good thing!
Just think. Is wpm a measure of a great writer? How could it be a measure of a great programmer.
I'm not sure what a "great hacker" is. Are they something like sysadmin or maybe someone who does security?
See my comment above. I spend a lot of time typing, even though I reuse a lot of code. (I write a lot of code: http://github.com/jrockway)
It's nice to think that code types itself, but it doesn't. If you have no ideas, then it doesn't matter how fast you can express them as code. If you have a lot of ideas, though, you don't want to wait for your fingers to slowly tell them to the computer. You want the computer to know quickly, so you can move on to the next task. That's why typing is important. There is no brain/computer interface yet, so you have to do it with your hands and the keyboard. Suboptimal, but them's the breaks.
What other things do you do regularly? Write emails, specs, contracts, documentation?
Of course you probably also do other stuff than typing on a keyboard. It's just that the keyboard often is the most efficient interface between you and your main tool, your computer.
I think typing speed is a good competency to improve to be more efficient in the next few decades.
I think that if you don't have to think about typing at all you don't have to schedule time-slices for thinking and editing. It's just a side-effect that your fingers work really fast for almost anything when they're autonomous: this is the thing referred to in the article.
For example, I often observe that I have two parallel processes going on: thinking and editing. I keep editing the file, correcting formatting, keeping lines beautifully cut and moving stuff around _autonomously_ while I'm still thinking about the _actual_ problem. It's like biting your nails when thinking over something: it just happens, you don't _do_ it. Doing stuff that you don't need to think about at all actually helps me in the thinking part.
To be able to do that you have to master the keyboard, both for writing text, writing code and moving around (and you need emacs to move around quickly enough, imho hehe:)). I wouldn't want to imagine synchronising my trains of thought over a mental mutex in order to switch between editing and thinking.
This means that there's minimal latency over your thinking and what gets into the program. If it's low enough, programming becomes fluid as you couple thinking and changing the source code in nearly real-time. I could guess that many poor souls who have spent way too much time over the keyboard have realised this.
The way I think of it - typing fast is an indication of familiarity with the environment.
You can't be a good hacker without having logged countless hours in front of the screen, banging out code, emails, etc...
I guess I wouldn't arbitrarily set the cut off at some fixed value like 60wpm, but if you are slow at typing and need to look at the keyboard, you probably don't have enough experience.
Agreed. The best programmer I ever knew had severe carpal tunnel syndrome and had to use Dragon Dictate. Yet he could do things that teams of other programmers couldn't.
Before I arrived he had made a network monitoring system more than 100x faster when the team responsible for it was on vacation. (The CEO reported that the events now flew by, whereas before you could easily observe the event stream crawling.) He later single-handedly implemented and maintained the router configuration system for an ISP that spanned the US and there was never a single (non-cosmetic) bug reported against it in the 10 years I was there, even in the face of changing requirements, new hardware, and the company constantly coming out with new connectivity services.
He had learned to program in the days of punched cards, and he would do all his thinking on paper before he started coding. He would then dictate the code, top to bottom, without any bugs.
There's more to code than just code. Most of us write a lot of emails every day, and hopefully most of us write a fair bit of documentation also :)
How efficiently you can communicate with the machine is critical in programming because of the above, not because you're somehow faster at typing code - your brain cannot generate code at 60wpm anyway. Typing quickly, though, certainly takes away barriers to trying new things and prototyping really quickly.
I agree, but in practice I feel annoyed by my typos, and not being able to type directly what I think. It's a nice feeling of skill, to dance across the keyboard, with a seamless brain-computer connection. Like playing a video game.
I've tried to learn touch-typing a few times, but it makes my hands sore in a worrying way.
Another resolution is typing more slowly, and not caring so much about typos, since it doesn't really matter.
Not to mention typing fast continuously is asking for RSI. I can type pretty fast if I try, but apart from the thinking vs typing ratio, I also avoid typing fast or continuously because I know that's asking for a relapse of my RSI. And whatever I gained by typing faster will be lost by orders of magnitude if that happens.
The argument for touch typing to avoid distractions I agree with, but not raw typing speed.
It's not a "real" issue, so much as a proxy. I've never seen a good hacker look at their keyboard, whereas there are plenty of people that get out of flow looking for a symbol.
If a person can't type, I simply assume they're a noob and don't want them on my team. I don't expect them to have a very different ration of thinking vs. coding though :)
I can see that - it's like musicians that don't rate musicians who can't play piano.
But - I guess I've seen a few counter-examples in coding - e.g. I used to know a mainframe guy who had arthritic pain. He coded very slowly indeed, but it flowed out of him flawlessly.... So I tend not to have that bias.
If I met someone who wanted to get into programming, I certainly wouldn't say "practice your typing" - I'd say, "read these books".
I probably wouldn't tell somebody to go practice typing either, but that's not because it isn't important. I would just take it for granted that they could already type.
Actually, I'd say 'read these books' and 'learn to type'. Half of development is communication - writing emails, comments, docs, whatever. Why wouldn't one benefit from entering text more quickly?
Anyways, there are probably a subset of slow typists that are good programmers. But I'd be surprised if they weren't the exception.
I used to feel this way, but then I discovered that the resident uber programmer at work is a two finger typist. He is brilliant; used to work at Xerox Parc and all that.
I think it's not so much a question of typing quickly as a question of wether you are able to type without thinking and looking at the keyboard... When you get to that point, typing is just like walking you don't think about it and think about your code instead.
Agreed. Typing speed is very important when writing new features, but reading and comprehension speed is much more important for when you are fixing bugs in a multimillion line codebase.
