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.
One month command line challenge
31–40 of 48 posts
Re: One month command line challenge
#32>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 a…
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.
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...
Re: One month command line challenge
#33Earlier quoted context omitted.
>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
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.
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).
Re: One month command line challenge
#34Good 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).
Re: One month command line challenge
#35but 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
I've read that before. To be honest, it seems kind of whiny.
If what you are using is in a mature (not likely a field of research) domain, then yes, just click on install.exe and grunt (click) at [Next] once or twice, or on *nix go to Debian/Ubuntu style package manager and click on "install that" (and all its dependencies). BUT, if what you are doing is research that involves some newer tools, you might have to get a little bit dirty.
Maybe we can have a discussion about "dialog box bullshittery" (or registry bullshittery)? And how if you are stuck in that tar pit, there is no easy way out such as rolling up a tar of several packages which includes a top level "install.sh" script. You simply have to include the instructions of all the dialogs in a sequence and all the arcane buttons, checkboxes and radio buttons to be selected "just so", of you're SOL.
Yeah, cry me a river about the mean old command line.
There's some interesting comments in the "anti-forward" of the Unix Hater's Handbook suggesting that the "former prisoners" offer some commentary about the "facilities" to which they have been reassigned. ... "a system whose content and tone are set by Sonic the Hedgehog" indeed :-)
Re: One month command line challenge
#36Earlier quoted context omitted.
> 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…
>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
This is the reason I used the qualifier "hardly". Unfortunately I quite a few Java developers who can't cd their way out of their home directory.
Re: One month command line challenge
#37Earlier quoted context omitted.
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.
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
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.
Re: One month command line challenge
#38>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 a…
Heh, I got rejected once, a long time ago, for almost exactly this. I was asked to whiteboard a C function to convert an ascii character to an integer, and I wrote one that just returned the result of atoi(). I thought it showed knowledge of the best way to get the job done, but I guess they disagreed.
How does a rejection like that work in practice? Was that the question the interview hinged on?
A reasonable interviewer could just say "Alright, now can you do it without using the standard library?".
Re: One month command line challenge
#39WORD!
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.
Re: One month command line challenge
#40"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.