ie. you speak out the code, and someone else across the room types it in

Anyone tried this?

Obviously the person taking the dictation would need to be a coder too, so you didn't have to explain everything and go into tedious detail (not 'open bracket, new line...' but more like 'create a new class called myParser that takes three arguments, first one is...').

I thought of it because sometimes I'm too easily distracted at my computer. Surrounded by buttons, instant gratification a click away, the world at my fingertips. To get stuff done, I want to get away, write my code on paper. But that would mean losing access to necessary resources, and necessitate tedious typing-up later on. The solution? Dictate.


  • no chance to check reddit, stackexchange, gmail, etc.
  • code while you pace the room, lie down, play billiards, whatever
  • train your brain to think more abstractedly (have to visualize things if you can't just see the screen)
  • skip the tedious details (closing brackets etc.)
  • the typist gets to shadow a more experienced programmer and learn how they work
  • the typist can provide assistance/suggestions
  • external pressure of typist expecting instructions, urging you to stay focussed


  • might be too hard
  • might not work any better
  • rather inefficient use of assisting programmer
  • need to find/pay someone to do this
  • I've thought of trying this with speech recognition software, like Dragon, but I haven't done it. – Mike Dunlavey Feb 15 '11 at 1:19
  • 12
    Pair programming is another tool that appears to solve these same issues. – Anon. Feb 15 '11 at 1:21
  • I wish I could use pair programming but as I'm a student, the project needs to be all my own work. I suppose it also implies more of an equality/parity between skill levels, no? – Andrew M Feb 15 '11 at 1:26
  • iirc, legend has it that Richard M. Stallman had to dictate code to an assistant at one time, due to suffering from such severe RSI that he was on doctor's orders to absolutely not do any typing. – Carson63000 Feb 15 '11 at 2:10
  • 3
    @Andrew, just so you know, pair programming does not require parity in skill levels. In fact, it's a good way for a junior to learn from someone more senior. (it helps the senior person though, too). – Marcie Feb 16 '11 at 17:29

I have tried this, I find it's a good way to introduce a new programmer to a system. The new programmer gets some committed code, and experience using the system, which acts as a big confidence boost when you cut them loose to work alone.

Working in a pair with a programmer who is already familiar with the system (I personally haven't tried this), I would imagine this could be a very effective form of pair programming, as your pair reviews everything you code (since he has to type it!)

| improve this answer | |

The Agile Development concept of Pair Programming is actually quite similar to this. While it's not a direct dictation/writing system, you still have one person thinking and producing code, and another person reviewing as the code is written.

Pair Programming incorporates most of the pros you listed, except that both programmers must be at the computer.

I haven't actually tried it myself, but Agile development advocates swear by it. The Wikipedia article linked cites a number of studies where Pair Programming either increased productivity, code quality, time efficiency, or some other factor. So, most of your listed "cons" aren't really cons.

| improve this answer | |
  • I used to use Pair Programming routinely at my last company, I find it boosts productivity tremendously. Though the typing from dictation thing is very hard, due to the technical nature of what you have to dictate. – Orbling Feb 15 '11 at 2:08
  • In my experience, Pair Programming quickly degenerates to dictation anyways. – smithco Feb 15 '11 at 3:44
  • 1
    @smithco - depends on who you're pairing. Totalitarian senior architect with first-year junior code monkey? Yeah, there will be a lot of "type this, then this, then this" coming from the senior when it isn't his hands on the keyboard. That can still be beneficial as a teaching tool, but it isn't "collaboration" as you seem to expect all pair programming to be. That typically comes from two devs of roughly equal skill level, where one types and the other observes for mistakes or smells. – KeithS Jul 10 '13 at 0:04

Let's take a step back. The problem you seem to want to solve with is one of focus. That problem already has a solution, similar in look but very different in practice, which others have mentioned; pair programming.

Pair programming between two competent developers of roughly equal knowledge should not be programming by dictating. Instead, one programmer codes, the other one observes. Both are thinking, and of course communication is key, but both typist and observer are equal partners; the observer should neither be a backseat driver nor be catching Zs. The pair will also switch often, with observer coding and coder observing.

The main point is to stay focused, which is what you want. If one coder spends more than a few seconds on an IM or updating his Facebook status, the other can politely clear his throat and bring the coder back to the task at hand. Of course both coders can get distracted, either on the same or different things, but usually not for very long; one of them will soon enough resolve his distraction and be tapping their feet waiting for the other. If both of them are lost in Stack Overflow, Reddit or YouTubes, well that's a problem, but it's unlikely; one or the other is going to get self-conscious about wasting the other's valuable time with lolcats or skateboard bails and suggest they get back to work.

The second point is to have two pairs of eyes looking at the code, and two brains thinking about it. Pair programming provides a real-time code review process. This requires some tact; the observer has to allow the coder the time to go back and fix the typo he made. Immediately pointing out fat-fingers and other typos when the coder, more often than not, knew exactly what he did and just wants to finish his thought before correcting it, is extremely frustrating, bordering on dictation. However, if the coding partner seems to be moving on and has genuinely missed something, the observer can point it out so it gets fixed before they waste time with a build or a test run. By the same token, if the observer thinks they know a better way, they can not only tell that to their coding partner, they can take the wheel and drive for a while.

My experience with pair programming is typically positive. My experience with programming by dictation is typically negative. As the dictator, I feel handcuffed by not having my hands on the keyboard (this is alto true with pair programming when I'm observing, but to a lesser extent). I know my way around this application (be it what we're coding or what we're coding in). I know what I want to do and exactly how to do it. Yet I'm stuck watching this other guy constantly hesitating, searching for the right command or identifier, while doing something not quite what I had in mind, but close enough that I don't call it out because that would be micromanaging (but I sock it away with all the other things that give me nervous tics by the end of the day). Whenever I've been required to dictate code, it has almost always been to a guy fresh out of college who's had maybe two semesters' academic experience with the language and IDE, and I find I have to dictate every keystroke, because if I make any assumptions that the typist knows what I want when I describe what to do in more abstract terms, I'm disappointed as he types in something so obviously wrong that even Notepad would cry.

I imagine people who have typed according to my dictation have had similar levels of frustration. They're not in my head, they don't know what I know or what I'm thinking right now, and I think much faster than I can talk so I'm probably not helping. They often don't have my fancy $130 code formatting tool, so as much as they may care about proper indentation or naming conventions, it's a hell of a lot more work for them to get there on their box than for me on mine (we're trying to fix that). They're trying to keep up, and you'd be surprised how many really smart coders are lousy touch typists. It doesn't help that coding commonly uses symbols and character combinations that don't often pop up in the everyday administrative assistant's typing test, to say nothing of a friendly IM conversation.

Programming by dictation is, IMHO, one big fat sack of "no". It is the anti-pattern to pair programming's good practice.

| improve this answer | |

I used a variation of Pair Programming at my last job. Some of the problems we encountered were above our skill levels (both of us were just students), so we used to just sit at the same machine and code out a solution to the problem.

Rather than one person tell the other what to code, we just took the keyboard and mouse and coded the next section after explaining what we needed to do. It was good because it promoted respect between the two coders, since we had to relinquish control of the input when appropriate.

Personally I find it very hard to dictate code, though to be fair my experience is not with good coders per-se, normally its people who are learning to code/not very good yet (I'm still a student)

| improve this answer | |

"and not go into tedious detail" sounds like a peasant worker doing all the hard work while the boss stands back and directs.

If tedious detail is getting in the way of coding, you need to stop coding and start designing first. This is how we used to do it - sit down and think about what you want to do before you start doing it. Use paper, storyboards, various UML diagrams (if you like, I find them tedious in themselves!) and anything else that gets the concepts, transitions, state and overall system architecture in place. Then you can code to this design and find it a lot easier.

| improve this answer | |

The real issue seems to be I'm too easily distracted at my computer.

This is something you are going to have to learn to overcome as outside of the university course you won't have the liberty to dictate to a drone programmer.

There are ways of forcing this by blocking (eg in the hosts file) sites you find distracting, other ways of working such as the Pomodoro Technique which mandates times of no distraction interspersed with enforced 'rest' periods to do what you want.

Another thing to think about is if you find programing so arduous you would rather Reddit than do it... is this the right career for you? Maybe boat building would suit better?

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.