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.

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 which uses markdown as the syntax. While the examples are web language-flavored, it can be used with any language.

That's an interesting approach... the writing essays about what's stopping you from getting started. I think I might have to try that.

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.

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.

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.

... the video is itself a few months old.

I frequently have times when I'm doing things like "writing articles on what's stopping me from coding" and the like. But for me, when I'm on, I'm ON, and in those periods, being able to put code together reliably and quickly is of utmost importance.

Even with the macros and shortcuts he shows, I still would be slower using a system like that. When I'm typing in a good editor, I can blast out code VERY quickly, and when I've typed it, I KNOW it's what I meant. When he says it, he has to stop and look to ensure the code matches what he said.

Yes, he can say a phrase like "camel someVariableName" quickly, and sometimes it Just Works, but when it doesn't, he has to back up and say it again. That kind of distraction can throw me off my train of thought, and the damage to my productivity would be profound.

That said, it still IS great for anyone with an RSI as an alternate way to enter code. I just don't buy the "it could be better even for people who don't need it" argument. Especially with his claim that I would need to abandon my modern editor with awesome language support for one of those relics that relies on CTAGS.

...Did you watch the video?

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

#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

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.

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.

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

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.

That's what I like so much about multicursors: It's a visual way of mass editing.

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.

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.

Did you eventually get better at typing on the Kinesis?

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.