Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typing Practice for Programmers

typing.io

Post reply on HN
Print view View original

101–110 of 224 posts

Re: Typing Practice for Programmers

#101

Post by kps »

moonboots wrote: post #29
edanm wrote: post #25

This. Is. AWESOME. Let me tell you what this is useful for by telling you my story: I'm a pretty fast typist (80-100WPM on TypeRacer, usually) and I really never put much thought into my typing, since it was good enough. But I recently started paying attention to the kinds of mistake I make on Typeracer, and realized that I have certain combinations of keys which I don't make using the "home row" of the keyboard, but…

Thanks, I'm glad you found the stats useful. In my initial version, I wasn't requiring the user to correct errors. I was personally getting errors rates around 3~5% , which appear good but seemed too low for the amount of errors I feel I make. Adding the need to backspace and correct keys revealed the true cost of mistyping a key, namely the wasted keys typed before correcting and all the backspaces. Thanks for point…

Supporting KILL and especially WERASE would be nice; I usually use one of those rather when I've made a string of errors, rather than watching and counting backspaces. And I agree with previous comments that it's hard to follow just how many backspaces are needed.

Re: Typing Practice for Programmers

#103

Post by samd »

I don't understand programmer's obsession with typing efficiency. We're not typists. Typing is a tiny fraction of the time I spend programming. Most of the time I'm thinking, or talking to another developer about a problem. I could have the fastest typing skills and most efficient editor and not even be marginally more productive.

Re: Typing Practice for Programmers

#106

Post by RegEx »

ismarc wrote: post #100
RegEx wrote: post #94

Earlier quoted context omitted.

Are you one of those 170wpm-ers that ruin my win streak on TypeRacer?

Only if I'm on my preferred keyboard, I top out at 120 to 130 on laptop/netbook keyboards.. For a stint in high school, I typed medical reports from dictation for a friend's mom, eventually having the cassette player on the fastest speed and keeping up without issue. I have no idea how people can be very productive as hunt and peck typists when writing code.

Would you also happen to be a fast reader? I can't seem to break the 120 barrier, and I'm wondering if the habit of mentally "saying" the words as I read them is a significant reason why I can't improve.

Re: Typing Practice for Programmers

#107

Post by moonboots »

samd wrote: post #103

I don't understand programmer's obsession with typing efficiency. We're not typists. Typing is a tiny fraction of the time I spend programming. Most of the time I'm thinking, or talking to another developer about a problem. I could have the fastest typing skills and most efficient editor and not even be marginally more productive.

I agree that we're not typist in the sense that basketball players are not dribblers.

Re: Typing Practice for Programmers

#109

Post by samd »

moonboots wrote: post #107
samd wrote: post #103

I don't understand programmer's obsession with typing efficiency. We're not typists. Typing is a tiny fraction of the time I spend programming. Most of the time I'm thinking, or talking to another developer about a problem. I could have the fastest typing skills and most efficient editor and not even be marginally more productive.

I agree that we're not typist in the sense that basketball players are not dribblers.

You think typing skills are as essential to being a productive, and by productive I mean creating wealth and value, not lines of code, a productive developer as dribbling is to being a good basketball player?

Re: Typing Practice for Programmers

#110

Post by sukuriant »

This is a very neat idea; but, I do have one issue with it. When I'm programming, I don't start with the import statements (except for maybe some common ones that I have to deal with). I usually start with the most important part of the API and then spiral outward. I noticed this issue in the Java sample I tried. It began with the drudgery of import blah.blah.SomethingSpecific 10 times. I wasn't able to get into the meat of the code, and by the time I did, I was bored to tears. Imports usually come organically, if I'm having to deal with them at all (IDE's usually take care of them).

I think a great place for this to go would be if the code bounced around a bit more. Perhaps, start with what seems like the most commonly used function and write that function header and whole function; then, start writing all of the different subordinate methods you called in this primary method, and so on until the whole class is created. The way it's written write now, in particular for Java, isn't a way that I code and I imagine it's not the way that many people code.

Just my two cents. Otherwise, it's an interesting system so far.

Post reply on HN