6 ms·

I guess it depends on the type of software you're working on, but input speed has never been close to being the bottleneck with coding for me... Most of the ti

I guess it depends on the type of software you're working on, but input speed has never been close to being the bottleneck with coding for me... Most of the time I'm trying to figure out what to do or how to implement an algorithm. Rarely do I get those mad-scientist frenzies where I'm typing away frantically trying to get all the words down as they come into my mind in a flash of inspiration.

nightski 13y ago
No, but the less time you spend going through the mechanical action of translating thought to code the more time you have to focus on solving problems.
shurcooL 13y ago
It usually happens during refactoring, or when you're doing something you've done before, so you already know pretty much exactly what needs to be done and you're just executing. It also helps to stop coding for a minute, think what you want to do, then code until you stop typing for more than 5 seconds, repeat.
- m_mueller 13y ago
  When refactoring: Instead of typing fast, use ST multicursors or VI/emacs macros in an intelligent way. And I really really recommend ST if you don't want to debug your editor macros before debugging your build macros before debugging your code macros before debugging your code (yo dawg etcetera).
  - sophacles 13y ago
    On the other end are us visual thinkers. I could do all of that proficiently just fine. In fact I do plenty of macros and scripts and so on. But at the end of the day, I think in pictures. I end up using a lot of editor short cuts and "lots of keypresses" style refactoring while I work out the shape I really want. Then, when I get that, fire off some macros to deal with the rest, cleanup, etc.
    - m_mueller 13y ago
      That's what I like so much about multicursors: It's a visual way of mass editing.
cturner 13y ago
It's very different for different programmers. I've worked with people who are skilled developers and who can't even touch type. They have a slow-pace, methodical way of working. Many look at the keyboard over glasses and hunt and peck. The professor who ported plan 9 to raspberry pi (recent video here) is an example of this approach. On the other hand, I have a shocking memory and can't hold context for long. Sometimes I come to write a piece of code and find that I wrote it last week and can't remember a thing about it. I work by crashing through. I stalk the problem, procrastinate, drink tea, write short essays about what's stopping me from getting started. Eventually I get the whole problem in my head, and then need to get it down and done before I get tired. When I'm in this state and I need to solve a problem that I could use a standard library function for, often I'll just hammer out code to make the problem go away (list comprehension, string manipulation and the like) in order not to cause any extra load on my short term memory or distraction. Raw typing speed is very important. A drop in pace would hurt a lot.
- DigitalJack 13y ago
  That's an interesting approach... the writing essays about what's stopping you from getting started. I think I might have to try that.
- jostylr 13y ago
  Have you tried literate programming? It is a way to download your thought process into the "code". Particularly good for those who like to write. An example tool to create it is my own program at https://github.com/jostylr/literate-programming https://github.com/jostylr/literate-programming which uses markdown as the syntax. While the examples are web language-flavored, it can be used with any language.
  - deleted 13y ago
    [deleted]
moconnor 13y ago
This; if I'm typing and jumping around the code at full speed for long periods it usually means either: 1. I haven't understood the problem 2. I haven't understood the solution 3. I need to spend five minutes improving my Vim macros
- reeses 13y ago
  #3 is often the equivalent of taking a walk or a shower, or walking in the shower. It's enough of a context shift that your brain will forget the inessential and you'll notice the pattern you were hoping to extract. I think it's one of the great things about working with extensible tools and having a tool-building mindset. You can maintain momentum while relaxing your brain from working on a seemingly intractable problem. But, you should be using emacs. :P
lambda 13y ago
It's one thing to not be able to write code as fast as you can type. It's another to use a speech to text input method that's designed for long-form prose and try to use it to code. Can you imagine the frustration of trying to enter longCamelCaseVariableNames without a special macro to do so? I don't know the usual commands in Dragon, but I imagine it would be something like: "long delete space uppercase camel delete space uppercase case delete space upper case variable delete space uppercase names", possibly with a few false starts and undos in there as it interprets some of your words as commands rather than code. To experience something like it, try using your phone keyboard, with word prediction on, to write code. It will be slow, and frustrating, and have a lot of false starts. There's a big difference between "not the fastest way to enter text" and "so slow it's unusable", and the impression I get is that without extensive macros like this, most speech to text systems are so slow as to be unusable for writing code.
- pseudobry 13y ago
  ...Did you watch the video?
- egypturnash 13y ago
  That's kinda the point of this article. He's got a bunch of macros and idiosyncratic commands. At 11:30 in the video: "Camel this is a test" -> thisIsATest "Studly this is a test" -> ThisIsATest "Jive this is a test" -> "this-is-a-test" "Dot word this is a test" -> "this.is.a.test" "Score this is a test" -> "this_is_a_test" "Mara" -> selects all text on screen "Chik" -> delete He says he'll release his code in a few months.
  - cbhl 13y ago
    ... the video is itself a few months old.
  - lambda 13y ago
    Yes, that was my point. I watched the video, and picked the camel case example from it. I was replying to someone who said that input speed is not the main bottleneck in coding, hence implying that it's not all that useful to do things to improve input speed. While I concede that input speed is not the primary bottleneck, my point is that without macros like this to speed it up, voice input would be way too slow to do anything useful.
DennisP 13y ago
People say the same thing about learning a good text editor. Personally I find that while I spend most of my time thinking, when it comes time to enter or edit code it helps a lot if I can do it as quickly as possible. That way I stay in flow instead of getting bored and clicking over to HN.
burke 13y ago
I was never sure which side of this argument I came down on, and then I switched to a Kinesis Advantage keyboard. I had to slow down my typing for a couple weeks to get the finger positions right. The whole time, I felt like I was coding with a hangover. I felt like I couldn't think properly, just because of the reduced brain->computer bandwidth.
- bostonvaulter2 13y ago
  Did you eventually get better at typing on the Kinesis?
  - burke 13y ago
    Yes. After 2 weeks, I didn't feel handicapped. After 4 weeks I could type as fast as before (75-80wpm). Now, about 6 months later, I can type 95wpm on a good day.

nightski 13y ago

No, but the less time you spend going through the mechanical action of translating thought to code the more time you have to focus on solving problems.

shurcooL 13y ago

It usually happens during refactoring, or when you're doing something you've done before, so you already know pretty much exactly what needs to be done and you're just executing. It also helps to stop coding for a minute, think what you want to do, then code until you stop typing for more than 5 seconds, repeat.

m_mueller 13y ago
When refactoring: Instead of typing fast, use ST multicursors or VI/emacs macros in an intelligent way. And I really really recommend ST if you don't want to debug your editor macros before debugging your build macros before debugging your code macros before debugging your code (yo dawg etcetera).
- sophacles 13y ago
  On the other end are us visual thinkers. I could do all of that proficiently just fine. In fact I do plenty of macros and scripts and so on. But at the end of the day, I think in pictures. I end up using a lot of editor short cuts and "lots of keypresses" style refactoring while I work out the shape I really want. Then, when I get that, fire off some macros to deal with the rest, cleanup, etc.
  - m_mueller 13y ago
    That's what I like so much about multicursors: It's a visual way of mass editing.

cturner 13y ago

It's very different for different programmers. I've worked with people who are skilled developers and who can't even touch type. They have a slow-pace, methodical way of working. Many look at the keyboard over glasses and hunt and peck. The professor who ported plan 9 to raspberry pi (recent video here) is an example of this approach. On the other hand, I have a shocking memory and can't hold context for long. Sometimes I come to write a piece of code and find that I wrote it last week and can't remember a thing about it. I work by crashing through. I stalk the problem, procrastinate, drink tea, write short essays about what's stopping me from getting started. Eventually I get the whole problem in my head, and then need to get it down and done before I get tired. When I'm in this state and I need to solve a problem that I could use a standard library function for, often I'll just hammer out code to make the problem go away (list comprehension, string manipulation and the like) in order not to cause any extra load on my short term memory or distraction. Raw typing speed is very important. A drop in pace would hurt a lot.

DigitalJack 13y ago
That's an interesting approach... the writing essays about what's stopping you from getting started. I think I might have to try that.
jostylr 13y ago
Have you tried literate programming? It is a way to download your thought process into the "code". Particularly good for those who like to write. An example tool to create it is my own program at https://github.com/jostylr/literate-programming https://github.com/jostylr/literate-programming which uses markdown as the syntax. While the examples are web language-flavored, it can be used with any language.
- deleted 13y ago
  [deleted]

moconnor 13y ago

This; if I'm typing and jumping around the code at full speed for long periods it usually means either: 1. I haven't understood the problem 2. I haven't understood the solution 3. I need to spend five minutes improving my Vim macros

reeses 13y ago
#3 is often the equivalent of taking a walk or a shower, or walking in the shower. It's enough of a context shift that your brain will forget the inessential and you'll notice the pattern you were hoping to extract. I think it's one of the great things about working with extensible tools and having a tool-building mindset. You can maintain momentum while relaxing your brain from working on a seemingly intractable problem. But, you should be using emacs. :P

lambda 13y ago

It's one thing to not be able to write code as fast as you can type. It's another to use a speech to text input method that's designed for long-form prose and try to use it to code. Can you imagine the frustration of trying to enter longCamelCaseVariableNames without a special macro to do so? I don't know the usual commands in Dragon, but I imagine it would be something like: "long delete space uppercase camel delete space uppercase case delete space upper case variable delete space uppercase names", possibly with a few false starts and undos in there as it interprets some of your words as commands rather than code. To experience something like it, try using your phone keyboard, with word prediction on, to write code. It will be slow, and frustrating, and have a lot of false starts. There's a big difference between "not the fastest way to enter text" and "so slow it's unusable", and the impression I get is that without extensive macros like this, most speech to text systems are so slow as to be unusable for writing code.

pseudobry 13y ago
...Did you watch the video?
egypturnash 13y ago
That's kinda the point of this article. He's got a bunch of macros and idiosyncratic commands. At 11:30 in the video: "Camel this is a test" -> thisIsATest "Studly this is a test" -> ThisIsATest "Jive this is a test" -> "this-is-a-test" "Dot word this is a test" -> "this.is.a.test" "Score this is a test" -> "this_is_a_test" "Mara" -> selects all text on screen "Chik" -> delete He says he'll release his code in a few months.
- cbhl 13y ago
  ... the video is itself a few months old.
- lambda 13y ago
  Yes, that was my point. I watched the video, and picked the camel case example from it. I was replying to someone who said that input speed is not the main bottleneck in coding, hence implying that it's not all that useful to do things to improve input speed. While I concede that input speed is not the primary bottleneck, my point is that without macros like this to speed it up, voice input would be way too slow to do anything useful.

DennisP 13y ago

People say the same thing about learning a good text editor. Personally I find that while I spend most of my time thinking, when it comes time to enter or edit code it helps a lot if I can do it as quickly as possible. That way I stay in flow instead of getting bored and clicking over to HN.

burke 13y ago

I was never sure which side of this argument I came down on, and then I switched to a Kinesis Advantage keyboard. I had to slow down my typing for a couple weeks to get the finger positions right. The whole time, I felt like I was coding with a hangover. I felt like I couldn't think properly, just because of the reduced brain->computer bandwidth.

bostonvaulter2 13y ago
Did you eventually get better at typing on the Kinesis?
- burke 13y ago
  Yes. After 2 weeks, I didn't feel handicapped. After 4 weeks I could type as fast as before (75-80wpm). Now, about 6 months later, I can type 95wpm on a good day.