What is it that is so distracting and pulling you out of your zen when you use a mouse? Seriously you type so fast and code at the speed of thought that a little glitch here is like making a mistake with a Formula 1 car in the Monaco Grand Prix?
Let me tell you how real work happens and how productive people work. I am currently working with a very senior electronics guy in the night for some side projects. Watching him work shows me the path on how we programmers should be working. He will first build the base PCB with all his reusable designs and additional ones reading the documentation I rarely saw him Google anything in the past 15 days. If he has to ever get down to googling its generally to find some data sheet. Once that is done, he gets the components and meticulously builds the entire circuit on the PCB module by module. Every time he builds the module he tests if the inputs and outputs to it are as he designed on the PCB. It took a well whole month with each sitting spanning hours to get the whole PCB working. When he was done, the entire PCB worked like magic. The manufactured one's too. And there wasn't a single problem/bug. It was so spotlessly done. It looked like art work.
Yet the pace at which he solders, or used the CRO or multimeter hardly matters or is even relevant.
And yes, he hardly rushes or goes in a rash break neck speed in doing anything. So here is what I learned. Firstly learn to define the problem correctly, break the problem and establish a clear understanding of inputs and outputs to each module. Read documentation get a clear idea as to what it is done. Spend long hours trying to build/test each module. If possible automate testing(if its software). Spend time integrating.
Go slow, the biggest productivity leaks are not in going slow. Go slow but go steady. The biggest productivity problems are in problem definition, solution clarity, distraction and procrastination. For us programmers, let us be frank. Most of us don't RTFM. We jump to googling and then go down the time sink and end up reading all sorts of articles achieving nothing at the end of the day.
If possible work things out on the paper. Do use stuff like Mind Map for test cases. Learn to work things on the paper and by reading documentation. Learn good debugging tools, sound programming practices etc.
That is what counts guys. Not optimizing the 1 second delay needed to reach the mouse. That's not even relevant in the broad spectrum of things.
Please, don't take it to the other extreme.
The way I use vim, I still use arrow keys instead of hjkl. I usually don't do 8k or 3j. Yet daW, cs"', cit, /foo<CR>whateveroperationnn.nnn.n., /bar<CR>qawhateverbutmorecomplexqn@ann@a are part of my daily routine†.
Clicking around or moving with arrow keys to operate on well defined text objects feels like hunt-and-peck typing, while the argument is that the only true way to vim is knowing it, similar to touch typing. Yet between hunt-and-peck and touch typing, there's a continuous world.
I type at a reasonable speed, and I use vim at a reasonable speed. I'm not aiming for purity, I'm aiming for usefulness.
In general, Sublime Text does a vast and extensible yet at any given point in time fixed number of things well, while vim allows for composability, and hence even with a default setup and few things known, a great deal can be done already. This is what empowers me, not the home row touch typing stuff, not the navigation speed, but the quality of the dialog I can have with the editor.
† I know about multi-cursors in Sublime Text, and Ctrl+D, but Ctrl+D doesn't allow you to skip, and the whatever_operation you want may or may not operate on the search itself (which could actually be an ack search), and can operate on objects ST doesn't even know about. This allows me to do free-form refactoring without relying on fixed-form refactoring routines and plugins (i.e not just a glorified search and replace).
Thanks for condescending to all us unproductive children who obviously have never done any "real" work.
<long description of PCB design with iteration and unit testing snipped>
Guess what? That's called iterative design, and some very quality software is made the same way. It also has nothing whatsoever to do with arguing against using proper tools.
Here's a question: if your EE had to stop to deal with some clumsy tool (say, a soldering iron that was too big or had a badly designed handle), how badly would that impact his workflow? That's what people are talking about when they say that using the mouse when editing code (a purely textual medium, I might add) is a cache miss.
If any thing. vim is not the 'proper tool' of 2010's, 1980's may be. Not in 2013.
It is true that so many of us in software don't RTFM, and I am guilty of that, but it's also true that the FM is often out of date, incomplete, doesn't carry the edge cases, and is often written by a reluctant author inexperienced in writing good copy.
Apart from that, 'go slow' is missing the point a bit. It's not the 'lack of turbo speed' that the mouse is creating problems from, it's the context switching. 'Go slow, steady, and thoughtful' is fine, but the less context switching you have, the more attention you can spend on your task.
You have no right to condescend to tell others how 'real work happens' and how 'productive people' work, as if you were the only real productive worker in the room because everyone else is using a stupid editor rather than the mouse. Using the mouse doesn't make you a Real Programmer more than other people.
In this instance I'm talking about vim, but it doesn't matter, being able to operate on code in a context that matches the way you're thinking about it is invaluable in my opinion.
That said, I felt this was a bit over the top. While I totally think that this pays dividends, I don't think it enough to write a novella like he has.
Being bug free is nice, but not really the general case. I agree however that PCBs do need fewer iterations than software to become practically bug free.
I am unsure whether, in the general case, this is due to the quality of the people doing PCB design or due to the quality of the PCB design process (and associated tooling).
Another point is that in PCB design, there is (from my limited experience) a much stronger correlation between quality of the design and the quality of the implementation than in software projects. I attribute this to the lack of hand-off between the design and implementation stages, i.e. in PCB design the designer of the circuit is usually (not always) also involved in the routing process.
I would say that is the case because making mistakes there is expensive.
And yes the process they follow is generally far better than we do.