Bicycle skills

http://www.johndcook.com/blog/2012/08/01/bicycle-skills/

by ehamberg • 14 years ago

150 88 14 years ago

Most skills are bicycle skills - we do a lot of different things every day in this business. Its tricky to guess what we'll do more than once, that's the rub.

I learn skills when I want to - not when the job demands it. I actually enjoy learning things, and do it more often than needed, to improve myself you might say but actually just because.

stephengillie3• 14 years ago

Many would consider switching from Qwerty to Dvorak a bicycle skill. Typing a blog post or email can take much longer when you're learning to type in a new pattern. For some, the enjoyment of learning Dvorak, or the anticipation of being faster in Dvorak than Qwerty offsets the annoyance at the task's increased duration. For others, they have no such enjoyment or anticipation, and so the task is merely annoying.

People will only pick up bicycle skills where their benefit (or perceived benefit) is greater than the annoyance they deal with.

RegEx3• 14 years ago

Personally, I wouldn't recommend learning Dvorak to anyone employed as a programmer. I would highly recommend it to high school/college students with some free time on their hands. Going from 100WPM qwerty to 30WPM Dvorak while learning was extremely frustrating for just non-critical tasks, such as chatting with friends. I wouldn't be able to handle going so slow when I needed to actually get stuff done.

eru5• 14 years ago

I learned Dvorak as a student, too, and wasn't any fast at qwertz before.

You can learn Dvorak, even as a professional programmer, if you just reserve half an hour each day on the side for the learning, and keep using your old layout for your day job until you are comfortable.

agscala• 14 years ago

I don't think switching to Dvorak is worthwhile. Most people don't have the capacity to actually squeeze out the few extra wpm that Dvorak gives you, and if you do, the benefits aren't extraordinary. Plus if you use Vim, either you'll have to remember where the original keys were on the keyboard and use it solely through muscle memory, or relearn.

RegEx3• 14 years ago

Luckily I began the transition to Dvorak before I ever heard of Vim. The process definitely would have proved more painful with an additional set of muscle memory to override.

jcoder• 14 years ago

To me (Dvorak typist for > 2 years), it's not about increased wpm. I'm actually not a fast typist. It's about greater comfort at the keyboard, because ~70% of my keypresses are along the home row, compared to ~30% with QWERTY.

WRT Vim, I made the switch without too much trouble. In fact, I find the j/k on the left hand and h/l on the right hand useful.

sopooneo• 14 years ago

And most of us are programmers, right? Beyond some very low threshold I can not imagine WPM factors into programmer productivity. If you are a writer then perhaps it would help.

tomjen3• 14 years ago

I type in dvorak. If I don't my hands hurt.

And go install emacs. Its shortcuts are easier to type in dvorak.

eru5• 14 years ago

> Most people don't have the capacity to actually squeeze out the few extra wpm that Dvorak gives you [...]

For me it's not about speed, but about ergonomics.

cs7022• 14 years ago

Many would consider switching from Qwerty to Dvorak a bicycle skill.

Are you sure? I'd consider typing in Dvorak a non-standard skill that would make me less productive with ~99% of keyboards in existence!

This strikes me as about as worthwhile as learning to ride a non-standard dual-wheel vehicle, as a consequence of which it becomes much harder to ride regular bicycles.

evoxed• 14 years ago

I'm just one data point of course but after the switch I actually type much faster in qwerty as well. No looking, somehow when I need to I just switch without thinking. It's especially helpful when running a VM or when the bootscreen is tied to qwerty only.

starpilot2• 14 years ago

But most of your typing is probably on your personal or work computer(s). The rest of the world's keyboards don't matter.

eru5• 14 years ago

While I concede that I have become slower on qwertz keyboards over years of not using them, your bicycle example is wrong.

I'm an avid fan (and rider) of unicycles and recumbent bikes like the Flevo Racer. The Flevo Racer's pivotal steering makes you have to learn biking again from the ground up. It takes a few afternoons (or faster, if you aren't that clumsy). Riding a unicycle took me two weeks to learn.

Nevertheless, I can still ride a standard upright bike without any problems. And after all this crazy wheeled stuff, even bipedal locomotion still works fine.

Skills don't have to crowd each other out.

cdr• 14 years ago

Hasn't Dvorak been pretty thoroughly debunked as far as claims of speed? [1] is only the first google result, I can recall seeing quite a few articles on HN.

Dvorak is more unicycle than bicycle.

[1] http://reason.com/archives/1996/06/01/typing-errors/print

starpilot2• 14 years ago

No. That 1996 article is wrong on that point, and fluffy on others. It's straightforward to calculate finger travels for typing words on various keyboard layouts [1], and Dvorak easily comes out on top. Placing e on the home row alone is probably a significant improvement. Compare the home rows:

asdf jkl; aoeu htns

Placement of high-frequency letters, especially vowels, reduces finger movement and eases typing. There's no magic about it.

[1] www.typocheck.co.uk/dvorak/

aangjie3• 14 years ago

OT: I haven't read this specific article, but have been on DVORAk for about a year and am happy about it. But one of the problems i have noticed in arguments for and against these kb layouts is the hand size. they vary from individual, and i can easily see someone with a bigger hand not realizing the same efficiency improvement as i did when i switched over.

*-- I switched over by trying Dvorak for an hour a day instead of the QWERTY i had used for about 3-4 weeks. I was a below average QWERTY user. Touch typist, but not fast/ not a lot of typing experience.

decklin• 14 years ago

That article is mainly about the strawman argument that if Dvorak is better, then free markets are bad, because they lead to the kind of network effects that gave us QWERTY. (As a happy Dvorak user, I find this argument silly.) The author is very motivated to prove the premises false, for political reasons. I don't think it's very insightful.

SkyMarshal2• 14 years ago

Dvorak = old and busted.

Colemak = new hotness.

http://colemak.com/

godDLL• 14 years ago

Seconded, for typing in code (with all the brackets and what not) this worked out better for me.

tremendo• 14 years ago

Colemak puts the colon key above the home-row, and using Shift, which for Vim is rather unfortunate. I guess you can always remap it.

eru5• 14 years ago

Dvorak is old, yes. But busted? By the way, for international users the NEO keyboard layout might be worth a look, too.

I'm just too lazy to switch from Dvorak to NEO, even though it would make it easier to type German Umlaute. Also my Kinesis Advantage keyboard supports Dvorak out of the box.

pdelgallego• 14 years ago

The command line is a bicycle skills. Any programmer should learn it.

stephengillie3• 14 years ago

Do some people really find the command line so difficult to use? I'm quite the opposite so I have trouble believing it.

Maybe it's because the default black background makes it feel like we're throwing our commands into a "magical pit inside the computer", and waiting for the output, which will be an error unless the commands were perfect. That perspective is unpleasant.

Maybe it would be helpful to visualize a GUI while using the command line, where instead of clicking on a menu or button, you have to type its name.

RegEx3• 14 years ago

The command line isn't difficult, but sometimes it's difficult to convince someone who has never "needed to use the command line" that they should give it a shot.

prawks• 14 years ago

I believe the reason people feel it's difficult is that a blank prompt is inherently not intuitive. There's no way you can hand someone a command line interface with an empty prompt and let them fiddle with it. They need to know what to type to start doing what they want to do beforehand, there's no way you can really "experiment" when you don't know where to start.

It's very similar to many mainframe interfaces with non-intuitive commands. Many legacy IT departments have these. Questions like "How do I do X?" have answers from experts like "Type XKY= and then hit PF3". But that sequence of steps is nowhere on the current screen's list of commands, or in it's help documentation. You just need to know it.

This is in contrast to a GUI where every single thing you can do (aside from keyboard shortcuts) is visible. I can hit a random button and see what happens. In a CLI, there are too many possible alphanumeric strings to try, so I can't do the same thing.

(This is of course different if the prompt is not blank, and says "Type 'help' for help")

mechanical_fish• 14 years ago

Do some people really find the command line so difficult to use?

Yes. Very yes. To the point where, when you say "some people", what you really mean is "most people".

I don't think the problem is "the command line" so much as it is "the Unix command line". You don't see a lot of people having difficulty with text-adventure command lines. You demonstrate HELP and GET LAMP and they're off to the races.

Whereas Unix commands are hard to discover unless you already know their names, have illogical names, have inconsistent behaviors, have poorly designed documentation (every command has 27 options and they're often documented in alphabetical order on man pages, with the obscure corner-case options given equal weight to the most useful ones), require combinatoric thinking (because many options can be used at one time), take invisible actions ("gzip foo" returns no output and modifies a file in your current directory; you need "ls" to see that it did anything), are context-dependent (you need to know what a "working directory" is or you won't get past square one), and often require a working knowledge of pipes and redirection to be useful (and pipes and redirection aren't intuitive skills).

You need to read a book. Nobody has time to read books. Reading books is a bicycle activity.

drcongo2• 14 years ago

This is an interesting point. My experience is that a lot of people find the command line scary, as they never quite feel in control. I wonder if it's possible to create the command line equivalent of LightTable. Something that visually shows the user what their command is doing, or more importantly, about to do.

Derbasti• 14 years ago

Just today I had a discussion with one of my colleagues. There are tons of people (most of whom matured when Windows was hot), who simple weren't exposed to the command line ever. Teaching Git to them is torture for both the teacher and them. Anything about scripting is magic.

It's tough.

Kiro2• 14 years ago

Why? I still haven't found a tool which doesn't have an equivalent GUI.

JoelMcCracken• 14 years ago

Do you use both?

Edit: I wanted to add a few more comments.

Someone mentioned scriptability, also composability, speed, "multitaskability".

tsahyt2• 14 years ago

One word: Scriptabilty. I still haven't found a properly scriptable GUI. On the command line I can automate almost everything and customize it to my needs. Additionally I'm way faster on a CLI for almost any task I do as a programmer on a regular basis than with any GUI.

For me personally, not just tasks I do when programming, but almost anything I do on a computer. The graphical display capabilities are merely a way of displaying content for me (PDFs, web-pages, etc.).

Obviously, if you're dealing with graphical content you want a GUI though.

dbecker• 14 years ago

The point isn't that you can do more with the command line, the point is you can do them so much faster.

ColinWright3• 14 years ago

Here's a task I had to accomplish recently:

    For two different directories,
        find all duplicate files that are
            both less than 10 minutes old

This was easily accomplished in a few lines of bash, and then scripted, because I knew I'd have to do it again and again.

I'm not accomplished with GUI tools, but I'd be interested to know how this would be done via a GUI.

sterling312• 14 years ago

My buddy at Microsoft tells me that in terms of automation, they use the dogma that if you need to do it once or twice, you just do it by hand. If you need to do it more than that, you automate it.

wickedchicken• 14 years ago

Dijkstra says it even more succinctly: 'two or more, use a for'.

crntaylor• 14 years ago

That is ever so subtly different.

ht_th• 14 years ago

There are always only three cases: 0, 1, and many

eru5• 14 years ago

A good rule of thumb. A more nuanced look proves even more helpful: There are graduations between manual and automatic. Semi-automation can be enormously productive, too. (And if you go beyond just automation, there's making your scripts bullet-proof under all circumstances. Which is useful, if you are doing tasks not only a few hundred times but even more often.)

unoti• 14 years ago

The first bicycle skill I thought of for me when I read this: ZSH. I've seen people blaze through common tasks using ZSH that I do myself using an unholy combination of backscroll, mouse cut and paste, and cutting and pasting into my daily work notes in another window. I've never used zsh because I never wanted to take the time to learn it.

vi is something I did take the time to learn, and it's paid off hugely over the last couple of decades.

aangjie3• 14 years ago

Am just graduating from a novice to medium level user on vim. Consider myself a medium/novice user of the Bash shell (i.e: without awk/sed knowledge. but with find and grep). Is it worth switching to zsh at this point for me or can i just wait till i pick up awk/sed for text munging and progess on the shell usage??. I have come across zsh mentioned a few times, and given it a go too, but haven't been convinced/not understood what makes it better.

ibotty3• 14 years ago

yes. it will be worth it. once you get past medium shell usage, you will appreciate many of zsh's features. you might have a harder time writing a posix compatible shell script though.

plorkyeran2• 14 years ago

Personally I found zsh worth switching to even without spending any meaningful amount of time learning to use it. The better tab completion alone is enough to make up for the setup time and the occasional bashisms I try that don't work.

mej10• 14 years ago

Sort of as others said, the nice thing about switching to zsh is that you get a lot of benefit _just_ by switching, and it is very similar in basic functioning to bash. It isn't like vim or emacs where you can't do basic tasks until you learn a bunch of specific keys.

dima55• 14 years ago

As others mentioned, zsh is compatible enough with bash to make switching relatively painless. There are many areas of zsh that are dramatically better, but the one that can make you fly is the fancy globbing that zsh has. More or less, you never need the 'find' tool when using zsh. For example, if I want to find all the Makefiles in this or child directories that have the string 'abc' and have been modified less than 1 hour ago, I can do

  $ grep -l abc **/Makefile(mh-1)

If I want to look at the most-recently-modified file, I can

  $ less *(om[1])

If I have a symlink 'dir' that points to a directory and I want to cd to the pointed-to directory, I can

  $ cd dir(:A)

Clearly, there are lots of codes, but you don't need to remember them, since the tab-completion gives you online help. I can type the '(' then press 'tab', and it'll give me a list of the various codes that can follow and what they mean.

There are tons of others. If I want all

EXCEPT

*.h

I can use

  '*~*.h'

Or for instance, say I have a directory of photos. I want to pick DSC00095.jpg through DSC00107.jpg. In bash, you cry; in zsh I say

  DSC<95-107>.jpg.

After I've typed in the glob, I can press 'tab', and it'll expand the glob in-place, letting me know if the code worked without executing. I can then undo to get the code back and have it live in my history.

There are plenty of other non-globbing-related features of zsh that make it worth looking at, but this is one that doesn't get as much press as it deserves.

heretohelp3• 14 years ago

Emacs eliminates the need to learn a subset of the diaspora of bicycle-skills. The same shortcuts, the same skills transfer over to a wide variety of problem-solving approaches.

One of those...is zsh. You just don't need it when you're an Emacs user. You get all the power of Emacs, but you can use it in the inferior shell. No need to remember weird arg registers.

gecko• 14 years ago

I'm a heavy Emacs user, and I don't agree with that statement.

I can see three places you might be coming from and feel that way: you use Eshell; you use ansi-term mode with e.g. bash; or you simply barely ever hit shell, instead using things like dired-interactive to accomplish shell-like tasks.

The last, to me, is a nonstarter. You can do many, many things using native Emacs tools, but not all. dired is not the right tool for quickly making a pile of nested directories and moving files into them based on file size, there is no Emacs take on top, etc. You can come back and say, "Fine, write some elisp for that," but to me, that's like saying you don't need to learn PowerShell because you have Explorer and VBScript. Just because there's overlapping functionality doesn't mean that one tool can substitute for the other.

If you were thinking ansi-term, then learning the nuances of zsh (or fish or whatever) is still helpful. ansi-term, at most, frees you from memorizing keystrokes. Past that, you're still very much using whatever shell you're invoking. I'd want to learn zsh just as much, or as little, running in ansi-term as in Emacs.

That just leaves Eshell. I like Eshell fine, but there are hard limits on what you can do with it as a shell, because it's not really a shell as much as an interactive elisp REPL with an alternative default syntax. Job management and piping are bizarre, you're still thrown into ansi-term for interactive tools (and yes, there are some tools I would prefer to use interactively), even non-interactive stuff sometimes displays incorrectly or bizarrely due to Eshell not really being a term, and so on. So while you can use Eshell most of the time, it's not a complete replacement for a real shell.

Now, is it possible that Emacs tools like dired/VCS integration/etc., combined with Eshell, means you can use a "real" shell less if you want to? Yeah, sure--just like I can use folder actions and AppleScript on my desktop to replace some of my old cron jobs with on-demand drag-and-drop processing. But to say that learning zsh wouldn't be rewarding if I knew Emacs just strikes me as weird.

neutronicus• 14 years ago

I had a job where the build didn't work if you started it from inside M-x shell.

On that day I resolved to learn the actual shell.

tsahyt2• 14 years ago

I think editor skills are a perfect example of bicycle skills. When you're effectively editing text all day long, learning an editor like vim or emacs really pays off in the long run, although it might be painful in the beginning.

Bash scripting is another bicycle skill I think. The power of automating tasks is obvious but often it's easier to just type stuff in quickly rather than writing a script and let the machine handle the job.

There are probably many many more, but those just popped into my mind right after reading the definition of a bicycle skill.

raganwald2• 14 years ago

Is this another way of describing what Steven Covey called "Sharpening the Saw?" You can saw wood all day, and of course in the very short run you're always more productive sawing than sharpening, but in the medium or long term, you're better off sharpening the saw before you start cutting.

Splines2• 14 years ago

I see "bicycle work" and "real-time work" as basically the same thing. In other words, you do "bicycle work" so that you can do "real-time work" successfully later.

In programming terms, this would be like taking the time to learn your language so that you can effortlessly interact with it and think about it without really thinking about it. Or learning your editor so you can move around your document on a subconscious level.

raganwald2• 14 years ago

Improving your editing skills (one of my glaring weaknesses) are a near-perfect example of sharpening the saw. You already use an editor, now you're learning to use it faster.

I guess if we're going to play with the metaphor, learning to use a bicycle is not sharpening the saw, it's learning to use a new and better tool.

So if we go with editors, learning to type faster is sharpening the saw, just like training to walk faster. But switching to Emacs is like learning to ride a bicycle where you used to run.

yen2232• 14 years ago

If we are going with 7 Habits metaphors, "learning the bicycle" would be like doing Quadrant 2 tasks, the Important but not Urgent tasks. Activities which don't bring anything in the short term, but will make your life easier in the long run.

sharkbot• 14 years ago

This is a bit similar to the "exploration vs. exploitation" problem [1]. Is it better to explore new avenues in hopes of higher returns later, or better to exploit current knowledge of the problem to maximize current returns?

[1] http://en.wikipedia.org/wiki/Multi-armed_bandit

frankus• 14 years ago

I often find myself wondering whether I should take the time to automate some little part of my daily work routine when it would be many times quicker (but less fun) to do it manually.

If I do go ahead I often end up saying something like this to my coworkers:

http://xkcd.com/974/

ImprovedSilence• 14 years ago

In other words... learn vim?

DividesByZero• 14 years ago

I've seen some organisations with an complete inability to learn these 'bicycle skills' in the interests of short-term savings because of misaligned incentives.

Gigantic enterprise software/infrastructure projects with no integration test automation because it's cheaper/faster to throw on a few temp testers every time there's a release rather than taking a month to put automation on the whole stack. Role reshuffling to make a savings for the business unit quarterly earnings sheet.

I think the other side of the coin to bicycle skills is something akin to technical debt - call it skill debt, say. Something could be done the right way straight away and the skill/process learned earlier, but because of a shortsightedness regarding cost, the cost to learn them actually increases with time until it's simply not possible without starting all over again.

This is something that can affect organisations as a whole, not just individuals, and I think it's something technical and project managers in growing organisations ought to be aware of - get your people, ALL your people, set up with the requisite bicycle skills that benefit everyone.

Bicycle skills

Related Stories