3 ms·
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 au
by menssen 10y ago
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.
- jasonm23 10y agoTo 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.)
- wott 10y ago> 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.
- Retra 10y agoI 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.
- taneq 10y agoThat 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.