Live data from Hacker News

Typing Practice for Programmers

speedcoder.net

61–70 of 172 posts

Re: Typing Practice for Programmers

#61
post #22
post #2

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.

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…

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

Re: Typing Practice for Programmers

#62

Who write code that way (linearly)?

Good question. I don't type code as I type a letter. When "coding", I edit structured text. So what's important for productivity is things like jumping with accuracy (word, corresponding bracket, file...), cut/paste, other IDE shortcuts to rename, refactor, etc.

Re: Typing Practice for Programmers

#63
post #2

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.

Re: Typing Practice for Programmers

#64
post #10

Earlier quoted context omitted.

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

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.

Re: Typing Practice for Programmers

#65
post #22
post #2

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.

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…

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.

Re: Typing Practice for Programmers

#66

Programming is a unique field: if you're doing it right, it should never be dull. Frustrating? Draining? Rage-inducing? Sometimes. But not mind-numbing. Why? Because we can build our own tools. If we find ourselves doing repetitive work, we can build a tool to automate that work. This automation is itself likely at least somewhat interesting. What isn't repetitive and that can't be automated should be interesting as…

I see where you're coming from, but this tool is still valuable in a number of cases that I don't think you're considering.

I recently got a new mechanical keyboard, which had special "layers" for punctuation. "Common" punctuation like periods and commas are still there, but other punctuation like curly braces, brackets, etc. require new key combos. [1]

I agree with you that a lot of the time programming requires modifying rather than composing, but not all the time. In particular, I blog in Markdown, which requires a certain amount of extra symbols that I wouldn't normally be typing. (Goes hand in hand with the previous point).

[1] You might be wondering, "Why get a new keyboard, if you're typing slower with it?" The new one is easier on my hands, wrists, and fingers, as well as being an actual pleasure to use.

Re: Typing Practice for Programmers

#67

For anybody learning to touch type, I highly recommend looking at alternative keyboard layouts. I use QFMLWY, which reduces typing effort by 43% in comparison to QWERTY (for some measure of "effort") [1]. It greatly reduced my wrist pain, and just feels much "lighter" to type. [1]: http://mkweb.bcgsc.ca/carpalx/?full_optimization

I used left-handed dvorak for a while while my right hand was broken, and used colemak at home, but I reverted to QWERTY after realising I have to work with other people. Other people use my computers, and I use other peoples computers. Having to remember to switch maps before letting someone start typing at my computer, or having to cognitively switch back and forth between layouts whenever I used anothers wore thin, and I gave up.

If I did lose the use of a hand permanently, I would probably try making a custom map with chording, there's definitely a payoff there.

I'd say it would be worth learning alternative keyboard maps if: A) you work remotely and have a single computer or set of computers you can permanently configure with your preferred layout. B) You're a wordsmith/writer and produce large amounts of textual input as fast as you can type.

I think getting a base touch-typing competency matters far more than optimised layouts, even though the latter can improve comfort/accuracy/speed even further.

In comparison, the text-input methods for smartphones and portable devices need to improve drastically. I find myself getting frustrated whenever I need to input more than a single sentence of text into a smartphone. Using terminal emulators or trying to write technical code/information is a nightmare.

Re: Typing Practice for Programmers

#68

For anybody learning to touch type, I highly recommend looking at alternative keyboard layouts. I use QFMLWY, which reduces typing effort by 43% in comparison to QWERTY (for some measure of "effort") [1]. It greatly reduced my wrist pain, and just feels much "lighter" to type. [1]: http://mkweb.bcgsc.ca/carpalx/?full_optimization

I'd be delighted to just have a querty with a Swedish layout, but with some English mappings for \[]{}, all of which require AltGr on a Swedish layout. Having those available on a better (or no) modifier would save my wrists a lot of pain.

Re: Typing Practice for Programmers

#69
post #61
post #22

Earlier quoted context omitted.

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…

> 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 am…

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

Re: Typing Practice for Programmers

#70
This test is a bit..silly to me. I am an enthusiast of mechanical keyboards, own a few, and have enjoyed typing for as long as I can remember. On top of that, I can type quite fast - depending on which keyboard I am using as it does affect me a bit I reach about 720cpm on my mx blues (ducky keyboard) and about 670cpm on my KBP keyboard with Matias Quiet Click switches, which is my slowest board. (on the 10 fast fingers typing tests)

Which is quite a good speed for typing, and I have _never_ found that to really help me at all when coding. Usually when coding you are still thinking about what to write and the speed at which you write code is never actually hindered by the typing speed that you have.

There are a few exceptions to this, as I like doing live-coding when giving presentations it does help me write the code faster, but I already know what I am going to write to a large degree and people seem to like the live coding.

But for day-to-day programming, I don't feel like this matters..

Post reply on HN