5 ms·

> I've often done things iteratively and interactively that could probably have been done more efficiently if I'd taken the time to think out the correct incant

> I've often done things iteratively and interactively that could probably have been done more efficiently if I'd taken the time to think out the correct incantation. Maybe not. Efficiency is a measure of the time it takes accomplish something. 'Puzzling out how' can sometimes be a more relevant bottleneck than 'number of keystrokes.'

swombat 15y ago
The difference is, if you just do it mechanically, you'll never get faster at it - the limit is the speed at which you can hit keys in a coordinated manner, which is not going to improve much over time. Something that takes you 100 keystrokes and a mouse movement today will still take you that much in a year's time. However, if, with a minute of thinking through the correct incantation, you can turn that into 10 keystrokes and no mouse movement, next time it will probably only take you 40 seconds to remember how to do it. Then, 30 seconds. Then, 20 second. Then, 10 seconds. Soon enough, if you do it often, it'll become automatic. And then you'll have locked in a more than 10x gain in productivity which would have been impossible the dumb way. This is also the reason we spend years learning how to program instead of just copying and modifying bits by hand, by the way.
- tyree732 15y ago
  While I agree with your initial arguments, that last sentence doesn't make a whole lot of sense.
  - swombat 15y ago
    Learning to program takes almost as long as learning to use vi (hah!). Many people learn to program to automate a simple, boring task. Many people learn to program better by automating more of those tasks, before they progress onto "full programs" that have more of a stand-alone nature. Within those full programs, there are many times when we continue to have a choice between doing it the quick but dumb way, or taking a little more time and doing it the clever and reusable way. Of course, sometimes this can be taken too far - see yak shaving - but there are many points, while learning to program and while programming, where we face the choice between "do it manually in half an hour" and "take two hours to program something that will do it in 3 seconds". The difference between a programmer and a non-programmer is, largely, that given this type of choice, the programmer will tend to pick the latter option.
- yesimahuman 15y ago
  I find that in vi the fastest method for me is usually a mechanical combination of visual mode/movement/yank/paste rather than figuring out in my head where the next "word" ends or how many times to repeat the command. I've never been good at that but I consider myself very fast in vim. It is rare that I have to repeat a command and then I usually use the macro recorder and repeat it a random amount of times until I get it right.
- Triumvark 15y ago
  > [Optimization is often beneficial.] Your point is indisputable. Fortunately, it's not inconsistent with my own: >> [Optimization is sometimes harmful.] Optimization pays the greatest dividends to tasks which: (1) could be brief, (2) but are quite long and (3) frequently necessary. As to vim: On (1), brevity, Vim is powerfully so. On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers. On (3), frequency, this surely depends on the person and task. I rarely delete every third occurrence of x between the seventh and ninth y... but if I used vim, I would make a point to. So, I would turn to vim if there were several meta-editing tasks I routinely performed, each requiring a large number of keystrokes, each of which vim could reduce. And hey, maybe this is the case. I'd love to see a plugin that analyzed my editing style and made suggestions to make me more efficient. But originally I was just noting that efficiency and optimization are messy.
  - swombat 15y ago
    > On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers. As a simple example of that, using a dumb text editor like notepad as the baseline, changing the same 10 characters on 10 consecutive lines will take at least 200 keystrokes (100 DELs, 100 times typing the same characters back in, plus the movement keys - about 9 to move down to the next row. With a bit of thought, in notepad, you can reduce this a bit. use Ctrl-C and Ctrl-V to reduce the amount of typing - but you'll still need to either DEL or select the words to replace, in the same location on each line. With a more modern text editor, you can select a rectangular area and replace the text within it. In vi, replacing those 10 strings on 10 consecutive lines will take (starting at the first character to replace, like Notepad, and assuming it's a single word inside separators): Ctrl-V e 1 0 j c A_NEW_WORD That's 16 keystroke instead of over 200, with no mouse movements. This is something I do frequently enough that I didn't need to even think for a millisecond to bring to mind the keystrokes needed to do it. Now, I'm not arguing your editing style isn't different - maybe you've never needed to do this - but I would argue that this is a fairly common programming text editing task.
    - 15y ago
spiffworks 15y ago
I just started using emacs as my primary editor for work, and I face this all the time. I'm completely sure that most of the things I do can be done more efficiently and with fewer keystrokes. But to stop and think about it breaks my flow, and stops me from thinking about the code itself.
- dasil003 15y ago
  The trick is to just spend a few minutes each day reading up on a command or working on your config. There's no rush because emacs will be around for the long haul. It's not about the most efficient command sequence at every moment in time, rather it's about building up the mastery that allows your natural instincts to subconsciously pick more efficient paths.
erikb 15y ago
It is always a long term goal to puzzle out a better way to solve the same problem. Doing that often will lead to better solutions over time. Not doing that will keep you on the same level you are now (or might even help in decreasing your skills). In a short term any solution is fine, of course.

swombat 15y ago

The difference is, if you just do it mechanically, you'll never get faster at it - the limit is the speed at which you can hit keys in a coordinated manner, which is not going to improve much over time. Something that takes you 100 keystrokes and a mouse movement today will still take you that much in a year's time. However, if, with a minute of thinking through the correct incantation, you can turn that into 10 keystrokes and no mouse movement, next time it will probably only take you 40 seconds to remember how to do it. Then, 30 seconds. Then, 20 second. Then, 10 seconds. Soon enough, if you do it often, it'll become automatic. And then you'll have locked in a more than 10x gain in productivity which would have been impossible the dumb way. This is also the reason we spend years learning how to program instead of just copying and modifying bits by hand, by the way.

tyree732 15y ago
While I agree with your initial arguments, that last sentence doesn't make a whole lot of sense.
- swombat 15y ago
  Learning to program takes almost as long as learning to use vi (hah!). Many people learn to program to automate a simple, boring task. Many people learn to program better by automating more of those tasks, before they progress onto "full programs" that have more of a stand-alone nature. Within those full programs, there are many times when we continue to have a choice between doing it the quick but dumb way, or taking a little more time and doing it the clever and reusable way. Of course, sometimes this can be taken too far - see yak shaving - but there are many points, while learning to program and while programming, where we face the choice between "do it manually in half an hour" and "take two hours to program something that will do it in 3 seconds". The difference between a programmer and a non-programmer is, largely, that given this type of choice, the programmer will tend to pick the latter option.
yesimahuman 15y ago
I find that in vi the fastest method for me is usually a mechanical combination of visual mode/movement/yank/paste rather than figuring out in my head where the next "word" ends or how many times to repeat the command. I've never been good at that but I consider myself very fast in vim. It is rare that I have to repeat a command and then I usually use the macro recorder and repeat it a random amount of times until I get it right.
Triumvark 15y ago
> [Optimization is often beneficial.] Your point is indisputable. Fortunately, it's not inconsistent with my own: >> [Optimization is sometimes harmful.] Optimization pays the greatest dividends to tasks which: (1) could be brief, (2) but are quite long and (3) frequently necessary. As to vim: On (1), brevity, Vim is powerfully so. On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers. On (3), frequency, this surely depends on the person and task. I rarely delete every third occurrence of x between the seventh and ninth y... but if I used vim, I would make a point to. So, I would turn to vim if there were several meta-editing tasks I routinely performed, each requiring a large number of keystrokes, each of which vim could reduce. And hey, maybe this is the case. I'd love to see a plugin that analyzed my editing style and made suggestions to make me more efficient. But originally I was just noting that efficiency and optimization are messy.
- swombat 15y ago
  > On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers. As a simple example of that, using a dumb text editor like notepad as the baseline, changing the same 10 characters on 10 consecutive lines will take at least 200 keystrokes (100 DELs, 100 times typing the same characters back in, plus the movement keys - about 9 to move down to the next row. With a bit of thought, in notepad, you can reduce this a bit. use Ctrl-C and Ctrl-V to reduce the amount of typing - but you'll still need to either DEL or select the words to replace, in the same location on each line. With a more modern text editor, you can select a rectangular area and replace the text within it. In vi, replacing those 10 strings on 10 consecutive lines will take (starting at the first character to replace, like Notepad, and assuming it's a single word inside separators): Ctrl-V e 1 0 j c A_NEW_WORD That's 16 keystroke instead of over 200, with no mouse movements. This is something I do frequently enough that I didn't need to even think for a millisecond to bring to mind the keystrokes needed to do it. Now, I'm not arguing your editing style isn't different - maybe you've never needed to do this - but I would argue that this is a fairly common programming text editing task.
  - 15y ago

spiffworks 15y ago

I just started using emacs as my primary editor for work, and I face this all the time. I'm completely sure that most of the things I do can be done more efficiently and with fewer keystrokes. But to stop and think about it breaks my flow, and stops me from thinking about the code itself.

dasil003 15y ago
The trick is to just spend a few minutes each day reading up on a command or working on your config. There's no rush because emacs will be around for the long haul. It's not about the most efficient command sequence at every moment in time, rather it's about building up the mastery that allows your natural instincts to subconsciously pick more efficient paths.

erikb 15y ago

It is always a long term goal to puzzle out a better way to solve the same problem. Doing that often will lead to better solutions over time. Not doing that will keep you on the same level you are now (or might even help in decreasing your skills). In a short term any solution is fine, of course.