

One month command line challenge - winash
http://blog.expertinamonth.com/post/110437403117/learning-to-love-the-command-line

======
FLUX-YOU
>Many candidates will immediately start writing a program in Java or Python,
if they get it right, then they will start optimizing the algorithm

> and in most cases programmers who are comfortable with the command line
> version are also the ones who are better at writing code

These two statements indicate to me that you are ineffective at communicating
what skills you are looking for in a programmer.

The reason they are coding a sorting algorithm is that you're interviewing a
programmer for a programming position. The assumption is that they are being
tested on the knowledge in that domain, which includes sorting algorithms.

If I answered the exact same question by putting the file lines in a data
structure and calling Sort() in someone else's interview, I might be thrown
out for not giving them the actual algorithm that Sort() implements.

Or maybe you just want people calling system()/exec()/execvp() or whatever. I
dunno.

~~~
winash
Hi OP here, I am sorry! I should have added more context to the post. I have
never rejected candidates solely on this basis.

Its just that I appreciate programmers who think of simpler solutions first.

~~~
plug
I can appreciate this also. Your `sort` question reminds me of an interview
where I asked the candidate to give me an example of where he used his general
coding knowledge to solve a problem. He told me how he had two long lists of
email addresses with duplicates that he needed to sort and merge into one
unique list.

He explained his solution in which he spent considerable time writing a C++
program to do this - iirc it even wrote the unique entries to a db. He seemed
stunned when I explained that he could have achieved this easily with
something like `sort -u a.txt b.txt > sorted.txt`. Sorted! To be fair he was
inexperienced, but there is a lot of power in the command line that some
developers don't seem to be aware of at all.

In other cases, some developers who do know will still grab to the new and
shiny solution every time. The simplest solution is usually good enough, and
the most maintainable (if that's a concern).

Ted Dziuba's 'Taco Bell Programming' nails this perspective pretty well. I'm
sure it has been posted on HN many times already:

[http://widgetsandshit.com/teddziuba/2010/10/taco-bell-
progra...](http://widgetsandshit.com/teddziuba/2010/10/taco-bell-
programming.html)

------
theyoungestgun
I was asked a variant of this sorting question (with the same expected answer)
a while back. I think it's utter horseshit, just on principle that in 99% of
cases the interviewer will be pissed at the answer "call the standard
library's implementation that solves this problem". Why is this some
exception?

~~~
omni
I agree, it's really important to set the context for the question correctly
so they don't think you are trying to ask them a question to showcase their
programming abilities.

------
fitzwatermellow
Once, Ubuntu Desktop issued an update that hosed my fglxr drivers.

I needed to get some work done on a remote machine. I didn't have time to
download and re-install graphics drivers so I just soldiered. GNU Screen,
elinks, vim, ssh, rsync, irssi, et al. I was amazed how much distraction free
actual programming I could do. On an aesthetic full-screen bash console, no
less. Was even have tempted to setup Gmail in pine.

Until I needed a browser to test a layout. Finally, I had reached the limits
of CLI. Believing I could merely surf to amd.com, download the appropriate
tarball (linux x64 supported), unpack install reboot and rejoin modern civ.

Fired up elinks, went to amd.com and was properly re-buffed. There was a
javascript "system detection" routine that could not be bypassed to navigate
directly to the download urls!

In the end, apt saved the day. Moral of the story: always test your http works
in elinks, please ;)

------
fndrplayer13
I'm not sure how I feel about the sort question being a super simple
"fizzbuzz" type command line question in an interview. The problem with some
of the CLI stuff is that its really a simple yes/no "do you remember that
command name" type thing. For something like grep that makes sense. But as
somebody who also lives in the terminal, I have mixed feelings about expecting
things like wc, sort, xargs, etc out of a potential candidate.

Although, I do actually totally agree that the more a person knows about the
CLI in general, the better they sometimes appear to be. I feel like learning
to use command line tools also sort of inspires that general DRY attitude
about software in general. Don't reinvent the wheel!

~~~
dllthomas
Yeah, "sort" is a super esoteric name...

(I probably agree with you more than I disagree, and I'd rate "can read a man
page" more important than "remembers -n for sort", I just thought the
particular objection somewhat humorous)

------
dllthomas
_" I would ask the candidate a simple sounding question

"You have a file on your computer with 100,000 unsorted numbers, each number
on a new line, Sort them and write the output into a new file.

"Many candidates will immediately start writing a program in Java or Python,
if they get it right, then they will start optimizing the algorithm, some of
them even start talking about big data and how they need Hadoop to solve the
problem.

"I am looking for the candidate who can give me this simple command line
solution [...]"_

I live at the command line. I spent a year at a gig maintaining 90k lines of
bash. And yet I think I stand a substantial chance of failing this test.

Not because I am incapable of trivially producing the line in question (even
without recourse to the manual). But because interviewers usually aren't
looking for "I would run the code someone else wrote to solve your problem".
Of course, in practice, reusing code is great - and that _should_ be the
answer where it's applicable! But in an interview asking for a solution to a
problem where existing code cannot be the bulk of the solution is likely to be
too big a question.

------
Roboprog
WORD!

Generally, programmers who are afraid of the command line aren't very good at
putting textual commands into a program text file, either.

They will cling for dear life to code generators and other such facilities in
an IDE. (but not the good kind of code generators that define an original
source DSL to be expanded into otherwise unseen code by the build process
itself, always the IDE based code generators that generate mountains of crap
code that now must be read and saved in source control)

They will cling to rigid, bloated, frameworks that require that they fill in
parameters in an XML file, and write (many, scattered) tiny pieces of code to
fill in the blanks for that framework, but which allow little variation from
the application style which the framework mandates.

Beware the illiterate, programmer, grunting at cave paintings on the wall
(clicking pictures on the screen, only).

See also: Pragmatic Programmers - power of text/shells sections; Neil
Stephenson - "In the Beginning was the Command Line" essay.

------
zwetan
Good and sound advice but imho poorly illustrated.

I do believe that a programmer ignoring the CLI would not go far, it's not a
MUST know it is a HAVE TO know.

First it is about tooling, you will unlikely use a programming language that
does not work first on the command-line: the compiler(s), even for non-
compiled languages like JS things like grunt, gulp, closure, etc. are part of
what you have to know to be efficient.

But most importantly it is about the Unix tools philosophy, the classic "do
one thing, and do it well", when you do know how those different tools are
unique independently but can also connect (pipe) with each others it helps
tremendously to write better code in general.

Last but not least, every single languages we take for granted now (like PHP,
Python, Ruby, etc.) have all started with the CLI and with CGI, the basic
abstraction of standard I/O (as in stdin, stdout) is the root of many many
more complex problems.

I don't see how a programmer could have a deep understanding of HTTP for
example if he/she does not grasp the CLI first, sure you may not need it all
the time or to know it that deep but really knowing the details of the CLI is
a bit like knowing a bit of "assembler", it is a layer of tech you really HAVE
TO know to become really really good opposed as to just know enough to write
some code and make it works.

Now to test it like that in an interview I would go more blunt about it "do
you know the CLI, give me examples how you use it (or which tools) in
different daily programming tasks?", anything CLI-related that shows knowledge
of the operating system, of the compilers or other programming tools, of
automating tasks, etc. is imho a sign of a damn good developper, any lack of
it is probably a sign that you are either a junior dev (didn't discovered the
CLI yet) and certainly not senior (can't be if you don't know the CLI).

------
smoyer
I agree that knowing the CLI (of whatever OS you use) is a good idea but ...

I'm not going to take the challenge as I have the opposite problem. Since I
wrote software for 20 years before I had a GUI, I find myself using the CLI
too much in certain cases. I've been trying to learn more of the hot-keys for
the windowed tools that I do use ... and how to do some of my CLI tasks in a
windowed environment.

One curious note: I could live with 8.3 file names (since I did for years) but
I ditched Mac OSX because I couldn't tolerate it being case-insensitive.

~~~
winash
Maybe you should take the "One month GUI challenge" :), I wrote this for folks
who are just getting started I believe that once knlowing the CLI gives you
some confidence about uour computer and sets you up for easier learning in the
future.

~~~
smoyer
A "one month GUI challenge" would be interesting ... I'm not sure I could do
it though. Would we exclude interactions with remote servers? If I use a GUI
editor to create Ansible playbooks that are run against a server farm, that
feels a bit like cheating.

The example in your article was great (sort) - what other tools can't you live
without on the CLI? Here are a few of my favorites:

\- unique \- sed \- grep \- wc

~~~
winash
I usually get a lot of this, can you find me number of x from this file and y
that DB table for December .

I find myself using 'join' a lot.

------
stegosaurus
I have used CLI based interfaces with fluxbox and urxvt wherever possible for
a long time now. It started when I found myself with only a laptop with low
resources.

Nowadays I have a half-decent machine but I still keep resource usage low
where possible. The only 'GUI' application I use on a regular basis is the web
browser. Media is handled by cmus/mpv.

Widescreen monitors make it easy to have a permanent tmux sidebar. So 20-30%
of the screen is made up of terminals at all times, the rest can be a web
browser/IDE. Or, three panes side by side with terminals at left, vim at
centre, firefox at right.

I find it cathartic. It's also really easy to knock together scripts and run
them with watch. For example I have one that shows me clockspeeds, battery
life, uptime, etc and takes up 2 lines on the screen.

I also find hotkey based navigation easier than futzing around with the mouse
- goes doubly when i'm working mobile on a laptop.

------
munin
but that isn't the command line, that's unix... windows has its own sort
utility but the flags are different...

also contrast the submission with this post: [http://pgbovine.net/command-
line-bullshittery.htm](http://pgbovine.net/command-line-bullshittery.htm)

~~~
readme
I read the post you linked and I disagree with it because familiarity with the
*nix command line is very useful for a developer working in industry. This guy
sees it as a roadblock because he believes that the complicated nature of it
will turn students away who would otherwise be good computer science
researchers. This could be true. In any event, the post linked here seems
aimed at people who want quick vocational education.

This is the difference between being a craftsman or being an academic. If
you're a craftsman, you'd better know how to use your tools well. They're not
an "obstacle" in the way of interesting research. They're a means to an end in
accomplishing a goal.

At some point one should realize not every programmer is a computer scientist.
Many of us are so much of computer scientists as a carpenter is an architect.
For those of us who like to build things rapidly, familiarity with the posix
shell and variants is a huge asset.

~~~
falcolas
> familiarity with the _nix command line is very useful for a developer
> working in industry.

Depends on the industry. Familiarity with the command line for a Java
developer is hardly required. Familiarity with the _nix command line for a C#
developer is utterly useless. Ditto that for video game developers.

On the other hand, if you're writing for linux, then yes, knowing the *nix
command line is going to be incredibly useful. That said, there's a lot to
"know" \- it is its own programming language after all. How much familiarity
do you want them to have, and what tradeoffs are you willing to assume if they
have that familiarity?

~~~
winash
>Familiarity with the command line for a Java developer is hardly required.

You are assuming that developers would never require to grep app/db logs etc,
I think in practice Java developers have to deal with the command line, I
would partly agree with the C# bit

~~~
_asummers
I'm a Java developer that touches the command line for something besides git
almost every single day. Just because you're in a higher level language does
not mean you don't need tooling or don't have repetitive tasks. I refuse to
start a JVM just so I can do some arbitrary task.

~~~
zo1
It's also partly the case of "everything looks like a nail". I personally feel
that we are problem solvers first, and "programmers" second. So using a tool
is a perfectly valid way to solve a problem. In fact, it works towards one of
our key programming tenets of "reusability".

As an interesting aside to that; I have recently worked with a very peculiar
older developer (his age isn't related, btw). He lives, and breathes the
entire Microsoft stack. Knows all the buzzwords, configs, arcane incantations,
etc. Whatever problem he comes across, his first response is "write a C#
program". He has riddled our source control with arbitrary little executables,
sitting next to *.pdb and app.config files.

Luckily, he doesn't work on our backend which runs on AIX (and we haven't
pioneered trying Mono on it, yet).

------
tootie
Meh. It's useful, but the "no true scotsman" argument is just wrong. Coding
solutions is usually better in the long-term. It's why Perl was invented.
Command-line is all about learning thousands of arcane details that anyone can
just google the answer to.

~~~
serverholic
I tend to agree. There have been approximately zero times I've been given a
file with 100,000 numbers that needed to be sorted. Similar tasks are honestly
rare enough that my intermediate command line skill has gotten me by just
fine. Every once in a while a complex task pops up but I just google it and
figure it out fairly quickly.

------
dllthomas
_" If you don’t know how to do a certain task with the command line, you can
look up the man pages or look it up online."_

If you know the name of the command you need, read the man page. If you don't,
search for the man page using apropos. If you don't know how to use apropos,
read its man page.

------
dllthomas
_" Of course, you can use your browser and media player etc, but for all other
tasks such are writing and editing files, copying files, launching programs
etc, you must use the CLI exclusively."_

Although, forgoing the web browser might do more for your productivity than
anything else...

/me closes HN

------
sumitviii
> After one month, you will be surprised at how inferior and cumbersome the
> graphical interface seems compared to the command line.

Maybe because one does not need to change the way he/she is interacting with
machine?

~~~
falcolas
Depends on your goals. If you're ever asked to debug a problem on a remote
Linux machine with no X, you'll be lost if all you know is the GUI.

Even if you never have to step outside of Windows, you might still benefit
from learning Powershell, simply because it allows for a surprising amount of
automation of routine workflows.

------
joncalhoun
You may want to consider a new name, especially since you just registered this
one in Jan.

Onemonth.com is in a very similar space and the conflicting names will likely
hurt you.

------
mtrn
Reminds me a bit of "Learn X in 21 days" \- but then, the way we learn might
got more effective.

------
gesman
It is always a good exercise to try to accomplish more with less.

It stimulate creativity like nothing else.

------
slaction
This is the perfect example of the whole hipster culture making it's way into
web and software development.

I literally expect to see people like this writing about how they're
experimenting with punch card input any day now.

~~~
boomlinde
What exactly is hipster culture in this context? The challenge seems like a
good way for some people to learn something new. If you are familiar with the
UNIX tools you can solve some problems faster than without them.

