What I mean is, I'm currently job searching and I've been developing hobby projects to put on my Github.

I want to create a command line utility, because I've never done so before, and I think it might be interesting.

Would it be intimidating and a bad idea? After all, command line isn't for everybody and there is the possibility that who ever is looking at my code might get frustrated.

A GUI could also be frustrating to use as well, if it isn't properly designed.

If a potential employer does in fact look at a Github profile, I assume they're more interested in if the person can produce well documented, clean, maintainable code, than if it's a GUI or command line utility.

I could be wrong, just wanted to get your feedback.

The command line is always faster than the GUI, once you know the commands. Also, the command line tools will be the same, regardless of the GUI or the distro (note that not all distros install the same base-set of command line tools, but you can find the rest in their repos).

The command line is the lowest common denominator of Linux. That's why you will often find posters at LQ asking for command-line output and suggesting command-line solutions.

You don't mention what field you are job-hunting in, but, if it's at all *nix related, knowledge of command-line tools will be a big plus.

Data entry or junior developer type roles. I enjoy working with and prefer using command line. Problem is, if any potential employer is looking at my code, would it be more convenient to have a GUI? I mean, I assume they want to see if I can write clean, well documented, maintainable code, and able to explain it, regardless if it's command line or not.

I just don't want to frustrate any potential employer when they look at my Github expecting to find GUI utilities but instead see command line utilties.

This command-line tool is very impressive.

https://github.com/BurntSushi/ripgrep

I can't speak for potential employers, but I would certainly hope they would be favorably impressed by your knowledge of computing as demonstrated by the projects that you embrace as a hobby, to use your term, certainly more than if your hobby was, say, building model airplanes or hiking. I would also point out that what lies underneath any GUI is code.

Good luck to you.

Since your intention is to use your Github postings as a reference and an affidavit of your talents and prior work, I think this is a great idea.

Of course, do not post something owned by someone else, or a former employer. You never implied this at all.

Why I think it is a great idea is when people ask you about your knowledge and you say something like, "I wrote ...", "I did a project about ..." you can then POINT them to exactly your work and then talk profusely about it.

As far as hiring decisions go, the person who I talk to who can cite something complex they did on their own and talk my ear off about it, stands a much better chance. If you talk my ear off about using a ruler to draw a straight line ... probably not. If you talk my ear off about a program you wrote that is a bit more complex than Hello World, sure! If you next point me to a website or GitHub project and say, "There! I did that!", I truly will appreciate your efforts, even if whatever you did was highly simplistic to me personally, if I feel you put in an honest effort at something complex, you clearly are someone who I would consider engaged in their work and therefore someone I would appreciate working with.

build the cli tool, then wrap a java gui around it. voila, you are now ready on both fronts. and if you can code the cli tool, java gui should be a snap. i cant advocate java in terms of security, but at least you'll have a gui that can easily port if need be.

Naturally, it is advantageous to have something by which to demonstrate that you actually do know how to write source-code, but realize that I am probably never going to actually look at your examples: I simply don't have time.

(Have you ever in your life been confronted with a stack of resumes? It isn't a pretty sight. Those HR-department people are animals, and recruiters are even worse. Ick.)

Personally, I would be most interested in what you decided to do, and why. What as-yet unsolved problem did you endeavor to solve? Why is your mousetrap better (for you)? Briefly describe the thought-process that led you to do it. Now, how did you actually go about developing it and seeing that it actually works in all cases? And, so on. Those are the interview-questions that immediately come to my mind, if we were sitting across the table from one another right now. Maybe I would dream up some off-the-wall "fee-chur" and say that the Marketing Department loves your tool but they want this added to it yesterday. (It happens. A lot.)

I think of "programmer types" as being tool-builders, and I am interested to know how they identified a problem, devised a solution, executed their solution, and meticulously verified that it worked. I'm also interested to see their response to a request for change that wasn't their idea.

Most of the tools that they do build, except for Marketing Departments , will be command-line scripts. And they are much, much more likely to be scripts than binary executables.