Very cool, if true

#5: many years ago, in one of my university vacation jobs, I had a conversation with my manager about input devices, in which I said I preferred to use the keyboard to the mouse because (if you can type well) you can input data at a higher rate, and get things done quicker.

My manager's response was something like "You should be neither typing nor mousing that fast". He felt that if your input speed is the limiting factor in working with a computer you're doing it wrong – you should be thinking more and inputting less.

I disagreed with him then, and I still disagree with him now. But I don't disbelieve your statistic of only 5% time spent editing code. (In fact at work it might be even less than that, for me – both editing code and understanding the problem have to share my work time with meetings, bug-tracker paperwork, etc…)

But the thing is that, for me, "understanding the issue I'm trying to solve" also involves a lot of input, because I very highly prioritise hands-on investigation. Much more so than a lot of my colleagues, who are constantly looking at an error message and then just scratching their head trying to work out what might have gone wrong. If I can't see it immediately, I'll try to get more information, by typing more commands – running the program under strace, or under a debugger, or filling it with diagnostics and re-running, or running it differently, or cutting down the input file, or something which will give me more clues than I already have. So my speed of input is still important even though I'm mostly trying to understand the problem, because the way I understand the problem is highly interactive!