Bicycle skills | Hacker News Reader

Bicycle skills

johndcook.com

150 pointsehamberg88 comments

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.

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.

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.

Hmm.. posix compatibility is not high on my list. and hopefully, i won't need much in my future career. -- planning to learn some data analysis and mining.

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.

> Personally I found zsh worth switching to even without spending any meaningful amount of time learning to use it.

Definitely. Smarter tab completion and smarter word deletion (Ctrl+W) are probably the two "most used" features for me.

FWIW, after ~6 years using Bash, moving to zsh last week was a revelation. I swapped to tmux (after dabbling in screen) the week prior. Has been a good fortnight.

[1] https://github.com/robbyrussell/oh-my-zsh/ is a great source of zsh plug-ins and configs. I use the "simple" theme and the git, brew and gem plugins (amongst others): https://github.com/elithrar/dotfiles/blob/master/zshrc

Ctrl-W works in bash too.

For this string with cursor at end: "cd /usr/share/gammu"

Bash[1] deletes to the space. Zsh[2] deletes to the slash. I installed Zsh just now to find this out, and I love that Zsh appears to use ctl-w to delete words like vim does.

[1]: GNU bash, version 4.2.37(2)-release (i686-pc-linux-gnu)

[2]: zsh 5.0.0 (i686-pc-linux-gnu)

You can use META-<Backspace> (Emacs mode)

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.

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.

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.

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.

I don't use dired. I don't use the baked-in VCS utilities most of the time, although annotate is really nice.

I use the inferior shell and magit.

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.

Sounds like cargo cult and a bad build script.

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.

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.

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.

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.

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/

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.

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.

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.

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.

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.

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.

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.

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

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

> 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.

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.

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.

Huh. That's interesting. I guess it's akin to learning a second language...? Thank you for posting this -- it's changed the way I feel about learning Dvorak.

I had similar results, and I never even learned to type very fast on Dvorak. I think the key detail is that it forced me to break all of my bad habits I'd developed, and that carried over to qwerty.

After using Dvorak exclusively for two months I can't touch type Qwerty at all. I think you have to use Qwerty occasionally while learning Dvorak if you want to use both (I don't).

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

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.

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

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/

Does that calculate the way between keys or guess a common hand/finger size to calculate actual hand movements?

How do finger travels affect efficiency? This is not obvious.

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.

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.

Dvorak = old and busted.

Colemak = new hotness.

http://colemak.com/

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

programmer dvorak is even better... :D

Interesting, first I've heard of that.

http://www.kaufmann.no/roland/dvorak/

http://news.ycombinator.com/item?id=351059

https://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard#Pro...

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.

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.

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

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

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.

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.

unix is very user friendly, it's just picky who it's friends are...

(having said that, with unix you can be extremly productive and it is (more or less) designed to be easily understood once you grasp some concepts.)

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")

Those shells still inherits genes from the terminal era where metacircularity wasn't affordable. Emacs got a free meal from lisp so it can inspect itself and suggest to the user even in command line style.

Recent shells have done good efforts to provides some kind of typing and deduction to reduce friction. It's always nice to have a listing of /etc/hosts or ssh known hosts in place. Browsers picked this since the coming of 'smart' url-bars.

I hope one day we would go all-alan-kay on this and simply have a meta-capable system that parse/cache relevant data straight from the source so you don't need to do any extra work to make the system understand a bit your additions.

It's even less fun when the computer talks in English and you don't - no guessing keywords. (as happened to me when I was a kid.)

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.

It would be interesting to use a command line interface that acted like a text adventure game.

  > get file.txt
  YOU PICK UP THE FILE
  > inventory
  YOU ARE HOLDING:
  file.txt
  > gzip file.txt
  FILE.TXT HAS BEEN COMPRESSED
  > inventory
  YOU ARE HOLDING:
  file.txt (compressed)
  > drop file.txt
  YOU CAN'T PUT THAT HERE, THERE IS ALREADY A FILE.TXT HERE
  > rename file.txt file.txt.gz
  FILE.TXT HAS BEEN RENAMED
  > drop file.txt.gz
  YOU PUT DOWN FILE.TXT.GZ

Obviously not ideal, but at the very least the idea of inventory-as-clipboard would be useful on the command line.

That's a very fun idea you have there :)

You are in a twisty set of deeply-nested directories.

This is interesting enough to criticize :)

OK: you can get file.txt; gzip file.txt; rename file.txt file.txt.gz; drop file.txt.gz. However, it requires a get and a drop to fiddle the inventory, which doesn't seem to do anything (you are still specifying all the filenames each time).

And I don't see a reason to generate a gzipped file of 'the same name' and then do a rename, it seems better for the new name to be an argument to the gzip operation.

All you really want is to send information from file.txt through gzip to file.txt.gz. As in "gzip < file.txt > file.txt.gz" or "cat file.txt | gzip > file.txt.gz".

But it feels like there should be cases where the clipboard/temporary holding area is much more useful than it is here, I just can't think of them?

When Windows has a command line tool (Powershell, not their crappy native CLI) that's powerful and like 100x easier to comprehend, you know the Unix command line is due for a disruption.

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.

Back in the 90s Apple had MPW (a command line development environment) and AUX (its own UNIX implementation for 680x0 Mac hardware). Both featured Commando (type a command followed by an ellipsis and hit ENTER and visual dialog would appear letting you condfigure the command). When you clicked OK (or hit return) the resulting command would be typed into your window.

MPW also allowed you to differentiate between target and command windows very easily, so you could keep your favorite commands handy and have the output funneled to other views.

Not Lighttable, but a lot more useful than man pages in 99% of cases and pretty darn nice.

Thanks, I'd not heard of that.

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.

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

Do you use both?

Edit: I wanted to add a few more comments.

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

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.

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

I haven't found that to be the case.

It doesn't get much faster than executing a bash script. A GUI can never hope to match that.

I'm not sure what that's based on. For example, selecting a subset of items from a given list seems to be faster in a GUI than I've ever seen it done on a command line.

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.

Lines of bash? Seems like find all by itself should be enough (one line.. maybe a few pipes)

I don't know how to persuade 'find' to identify files in directory A that are identical to files in directory B. But my point stands - I can accomplish this quickly on the command line, and know of no GUI tools that would let me do it.

See. Your discussion proves my point perfectly. Too much hassle.

I can't work out if you're trolling or not, but your comment doesn't make sense at all. I needed to perform a task, and I did so fairly trivially from the command line. Someone else offered what they thought might be a shorter alternative, I pointed out that the task was more complex than they thought.

You take this as evidence that it can be done from a GUI?

So, let's go back to your comment. You said:

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

If you want to make me take you seriously, please tell me how you would:

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

In other words, given directories A and B, find all filenames f such that:

    $A/$f is less than 10 minutes old
    $B/$f is less than 10 minutes old
    $A/$f is identical to $B/$f

Now tell me how you would do that every hour for a week.

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.

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.

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

That is ever so subtly different.

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

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.)

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.

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.

In other words... learn vim?

Reply on news.ycombinator.com