So it makes sense to make the button-mashing as optimal as possible, so that there is no friction involved in programming. A few minutes of practicing new entry methods (using the right fingers for the right keys, etc.) eventually results in a less annoying interface between your brain and your computer. And that makes programming more productive and enjoyable.

(Interestingly, this post would have been much better if I had bothered to connect my HHKB to my netbook. Using the shitty netbook keyboard made me want to get commenting over with as quickly as possible. Make this a habit, and your shit keyboard results in shit work. For me, anyway.)

This at first sounds true but really isn't; programming is not pure thought: it's thinking and implementing and seeing how the implementation goes and trying a different way, having new ideas, etc.

You can't "think" in a pure vacuum; you need to bounce ideas off something real.

I do some woodworking and let me assure you the "ideas" that I have before starting a project get changed a lot when confronted to the reality of wood and tools.

After a while you discover that, to some extent, you end up making your own tools, that fit you and the projects you like to do.

Programming-wise, that's also why I dislike IDEs: they add an additional layer between you and the object you're working on; it's like woodworking with gloves (impossible). And they don't contribute much; they advertise "speed", but the slow part is thinking, not typing!

- - -

(I'm typing this on a daskeyboard with blank keys, I've used it for two years, it's fantastic.)

This, for me, is totally untrue. The IDE I use, IntelliJ, is the best programming tool I've ever used, bar none. And yes, I used Emacs for 5 years. It's amazing precisely because it adds an additional layer (the AST). That layer (the AST) is what I work on, with amazingly complex semantic instructions. I haven't programmed in text for years.

Thankfully this is hardly a slamming indictment.

If I typed more quickly, maybe I would have more time for thinking. That might be very important.

I tend to agree - when a developer is on a tear, and creating great code, the _last_ thing you want to have standing between them and their masterpiece is a 20 WPM habit.

I never learned how to type, I just got good at it without trying since I've been using computers for >20 years.

Surely most if not all good programmers have at very least been using computers for a long while before becoming good programmers?

It was when I started college my freshman year and started to spend a lot of time on AIM talking to old high school friends that I really learned to touch type. There's nothing like having to keep up in a conversation to make you type more quickly.

Seriously, just putting your hands on the keyboard correctly and then continuing with a hunt and peck method, if you're typing a lot for your job, will certainly lead to being a good typist within a few months. It doesn't even take conscious effort.

I'd been dicking around with computers for about four years at this point, so I asked them if I could come in and take a typing test to be exempt. They sat and watched me type, and didn't even bother looking at my WPM before they let me skip the class.

I don't really know how you can use a computer on a daily basis, and not learn to type quickly. It's like driving a stick shift for years, and still glancing down at the knob to see where 2nd gear is.

* Hey, I taught myself to type as a kid, playing text adventure games and typing in BASIC programs from library books.

I learned to type with all 8 fingers in about 30 minutes a day for about 2 weeks. I think I just used GNU Typist. Most efficient time investment of my entire life. Is my experience different from others?

Fundamentally, I assert it's really pretty unlikely that your throughput at the keyboard is a limiting factor to your productivity when writing code. It certainly is limiting if you're transcribing speech to text. To code: it's doubtfully reliable as a measure unless you're Rainman or worst case "headbanger" coders who substitute knowledge of what they write for knowledge of the result of what they execute.

Remember, you could always see someone post about how lines of code produced does not equal productivity. There's a recurring post about the guy who considered productive being reducing the size of his code.

Don't get me wrong, typing is a useful skill and good on those who master it at a high level. However it's no substitute for 'working smart' for e.g. :

Writing scripts when you need to.

Knowing your editor inside out.

Knowing your SCM (of choice) well.

etc.

At best I suspect the 'don't type fast' thing just seems to be indicative of the duffers in the industry who are just sucking a paycheck out of your company. Don't let it fool you that it's a definitive metric of software competency though.

My first ideas are usually not quite distilled, and after the initial burst (or brain fart) of code, I spend a lot of time reducing/refactoring the code.

Maybe, but I don't personally buy it (as a fast typer myself). I think programming shares a lot with writing where the editing is more important than the first draft. In my experience, typing speed doesn't significantly affect the quality of a writer's work, though perhaps it does the quantity.

You are proof of this. From what I've seen, your writing is good and goes down well on HN, yet you've identified as a "slow" typist. I don't see why your code should be any different.

- You don't get constantly interrupted looking for a key. Seriously, remember what this was like before you could type. Being able to type without thinking about it must free up a lot of mental energy and allow you to concentrate.

- If typing is easy, you tend to write more. You don't care if you have to rewrite a function. You don't mind using longer, more self-documenting variable names that make your code clearer.

Under 30 WPM, learning touch-typing should be a top priority. (Use Dvorak if you type mainly in English, it's 4 times as fast to learn than Qwerty.) Not having to lower your eyes and your head any more is so much more comfortable that it quickly becomes addictive. Of course, you will be slow at first, but you can get your speed back in two weeks (maybe even faster if you choose a Dvorak layout).

50 WPM (my speed, getting better over time) feels pretty comfortable, though Id' like to type a bit faster. If you hunt-and peck at that speed, touch typing will only buy you the comfort, but even that may be worth it.

90WPM is the speed of speech. Any faster is for contests.

Speech speeds for speeches and books on tape, where the listener can't interrupt and ask you to repeat, are typically around 150WPM http://www.humanfactors.com/downloads/aug00.asp but normal conversation is up around 170-280WPM http://itre.cis.upenn.edu/~myl/languagelog/archives/003423.h... and court reporters need to be able to transcribe speech at over 180wpm and typically 200wpm http://www.thehighschoolgraduate.com/editorial/DF/courtrepor... .

Try reading aloud something you're typing as you're typing it. You'll find that 90wpm is very slow speech. The only reason speeds like 50wpm and 90wpm can feel comfortable is that the actual process of typing is distracting enough that we don't have time to get bored.q

In ......... my opinion it's impo..r..t..ant to make ... these pauses.. when programming .... otherwise you might ... miss ................ something important.

Perhaps knowing the eventual time you must spend to type causes you to think more before you begin typing...

Who's to say?

That said, I can't imagine those blog posts come out quickly :)

However... Having said all of this, I do my best programming in the the 20 minute walks I take after getting up and walking away from the code for a while, not while I'm actively sitting at the keyboard typing stuff in. At the point in which I'm typing, I'm basically just dictating my own previous thoughts into a text editor and while it might make me marginally overall more efficient to do this faster, it is not at all the bottleneck of my entire process, it isn't even one of the top 25 hotspots.

Given my own process, I've never understood why anyone could possibly attempt to make a connection between input speed and quality. I could type one line of code a minute and typing still wouldn't be the botttleneck to me creating great code and I find it hard to believe that is true of anyone else if they are really being honest about their overall development process.

Note I'm not saying this because it's just that much more awesome or whatever, this is a real concrete change I experienced. I wasn't "hunt and peck" but I was all over the board and thought stodgy typing rules were silly. Right opinion, wrong reason; the rules are nonsense on a QWERTY board, but make sense with sane layouts.

Whether proficient QWERTY touch typists should switch, I don't know, but the value proposition for someone who isn't really proficient is a lot more compelling. Hunt and peck typist's brains are simply correctly reacting to the lack of utility of using the home row correctly, and if you fix that problem the rest will just flow.

It's not worth it to me to become proficient with Dvorak, even if I can see wins in typing speed and accuracy, because I'll incur ten times the frustration when forced to perform routine operations on a friend or coworker's computer.

Perhaps Atwood's analogy isn't the best. Programmers are the composers and the computer itself is the pianist, running the composition. However, you need a keyboard to compose!

I don't think my typing really got fast until I started using instant messaging. When it comes to programming, I could always type a lot faster than I could think. I'm probably typing this message significantly faster than I'd type any code.

And if I was driven insane by the impediment of a keyboard, do you think I would suffer it gladly?

Which is my way of saying, I haven't been driven insane by it and I don't perceive that my ideas are suffering in a traffic jam trying to get out of my brain and into the computer.

You're likely correct, and I've found myself doing this with some of my coworkers, however, over time I've come to understand it for what it is: There are many occasions in coding where I do not find it necessary to type quickly. I can type at the speed a typical person speaks -- and accurately -- and without effort (including symbols, numbers and other elements that are uncommon in spoken language but common in programming languages). I have never met an effective developer who is a "hunt and peck" typist, but I've met plenty that land in around 30 wpm.

The distinction, I think, lies in how much effort it takes our 30 wpm individual to produce 30 wpm. Touch-typing (which I define as being able to type without looking at or for the key you're looking to hit) means not having to actively "think" when I type. I know where the keys are by instinct/muscle memory. I can keep my eyes on the screen, or on my hand-written "napkin note", or on my white-board (and often a mix of the three) and transfer that information to implementation without perceivable interruption.

Like it or not, the keyboard is a bit of a tool of the trade. That doesn't mean you have to be a perfect typist (I don't use my pinkies to hit the letter "p", and until I purchased a split keyboard, I always reached with my left for the "y"), but a reasonable analogy would be one of a chef who can't properly handle a knife. Successful chefs don't always cut the way you're taught at the CIA (or wherever), but they handle the knife with precision and accuracy (and without effort or injury). They don't have to think about it, they just know what the finished ingredient is going to look like when their hands are done with the motions.

For example someone with a slow southern draw to their speech, relative to the listener, is often assumed less intelligent.

I couldn't resist responding to this one: I remember having a calculus teacher with a serious Southern drawl and I recall thinking he was very unintelligent. It was an error in judgment because I could barely understand him in a lecture setting and struggled in his class as a result (this was remedied by taking advantage of office hours and tutors). After a while I got used to it and it had a sort of accidental side-effect. I had to actively listen to understand him which resulted in my actively paying attention. He was a brilliant individual, and a gifted instructor (as well as a patient one ... willing to explain things one-on-one with a student (me) who was struggling at the time). Maybe teaching with a serious southern drawl in a northern state made him less effective, or maybe not. I'm not sure. Food for thought.