Ask HN: Should I invest time on mastering the command line or the Jetbrains IDE?

Too many questions, let yourself learn what you like! if you learn one the other will come easier. Start building your style by trial and error. There s no time lost in following your passion

Raw text editor (with syntax highlighting) is definitely not the thing of the past. For me, it's my main operation mode, even though I write code for living for a few years already.

For you at this point, sticking to text editor and command line tools may be the better option. You are exposed to how compilers are called and how things are being built, so you know it's nothing magic. I've seen people who started with IDEs for Java and never learned that there are operations beside F5 [run] and F9 [compile], e.g. that Java program can be packed up to a JAR and run from there, or that some source files can be generated before compilation.

My recommendation is to start with an IDE like what Jetbrains offers, (assuming you're working in a language they support) with a promise to yourself to learn command line tools as well/a bit later. I say this because the productivity benefits from a good IDE are incredibly high, especially when working with something like Java. But like at least one other commenter has said, it's highly useful to know how things are actually working on the command line, or how to run a few quick commands to help you find something your IDE might not be able to find easily, etc. Both are useful tools, but potentially different use cases. (I have a co-worked who programs Java in VIM, so it's not like you can't theoretically mold them to be useful for any case, but it's going to take a lot more work and time to get to a place that likely is not going to offer as many niceties as an IDE will out of the box, like powerful refactoring or debugging)

But make sure that promise to yourself to learn the command line does not go forgotten! It IS important, and knowing how to use something like VIM, even at only a basic level, WILL help you.

IMO it doesn't matter whether one is skilled in command line tooling or graphical tooling these days. Try both and see which makes you more effective.

I use Sublime 80% of the time and Vim the rest. Certain things like refactoring across files and multi-file find and replace I can just do so much faster in Sublime.

I also use Tower over the command line git client to make advanced things much faster (and not require a Google search).

Jetbrains offers Emacs keybinding. Bash uses Emacs like keybinding. There's a package for Sublime. There's Firemacs for Firefox. Emacs bindings for DrRacket. An Emacs package for VScode. And a printed version of the Emacs Documentation from FSF. https://shop.fsf.org/books/gnu-emacs-manual-17th-edition-v-2...

I'm biased of course, but toward something that tends to allow me to reduce cognitive load in a place that doesn't matter. I get Emacs like bindings for writing and editing this comment.

That said, learning Emacs means losing a bit of productivity for a bit of time. It also means continuing to learn for a long time. It might be years before rectangular editing mode becomes natural or creating and destroying abbreviations on the fly is a matter of habit...or looking up documentation in the documentation rather than Googling for it. But every little bit tends to pay off.

I don't have anything against Vim. It does what it does well. It just doesn't do as much and sometimes the Unix design principle of only doing one thing isn't what I want...turing machines, compilers, laptops, web browsers are all examples.

Anyway, it's just my random advice from the internet.

Good luck.

Oh my, this is adorable!.. You're worrying about something you really should not worry about. For a beginner, the marginal benefit of either this or that is negligible.

This is akin to trying to shave milliseconds off of your 100m sprint by carefully choosing aerodynamic clothes and running shoes when your time is 20 seconds. Nobody should worry about that until they're under 10 seconds. In that case, the problem isn't the shoes, it's probably the 40 pounds of fat the beginner runner is packing and should deal with first.

Worrying about productivity at this stage is a 10 year old wondering about the best way to shave his beard.. He just doesn't have that problem yet and should be doing something else..

It's pretty hard for a beginner to get started and the amount of tools is overwhelming and could be distracting from what the beginner should actually be doing, which is reading and writing code.

I'm telling you this because I'm a textbook case of this kind of "Oooh, I want to learn X.. What's the best book?" and the spend a year looking for the best book to learn X, instead of spending that year actually learning X.

I wasn't like this when I was a child. I had a computer, it had something called BASIC. I didn't understand a word of English. I looked words in a dictionary and guessed the most part, copied code examples, ran them, changed stuff, deduced the role of each from the side effects, and just started doing it. Children are like that, they get stuff done. They're great hackers. When we grow up, we start trying to be "clever" about things and doing it "smartly" and get stupid in the process getting less done and learning less.

>Try to master the Unix command line and a terminal based editor

About that.. http://xkcd.com/1168/

I think it'd be more productive for you to know enough to get you comfortable and know your way around it as soon as possible: yak shaving is never the point unless you're trying to unwind in which case, shaving animals can be.. relaxing.

Here's something to get you started but just that:

https://learnpythonthehardway.org/book/appendixa.html

Here's the most pertinent advice I could give you: Get internships. You probably live in a country that actually has software companies where people rely on software for most things.. Get internships at these companies. Real life experience, with real developers and real problems to learn the stuff you can't find elsewhere. Internships.

Also, side projects and reading code.

You think you're slow and a noob? I'm 29 and have been coding for 20 years on and off and I'm still a noob who can't code to save his life. I'm the slow guy here, not you!

All the best!

I'm somewhere around 20 years in. I'm going to share my point of view with you, then let you make up your mind about what to do. :-)

The command line by itself is an old-school text editor, where the default behavior is to write programs that are executed then immediately thrown away [1]. We develop a habit of using the command line in a casual way, without realizing that it's a powerful programming environment.

Once we realize that we're _programming_ with the command line, we can take deliberate steps to write better command line programs. We can:

* learn how to capture our programs and execute them again later. * learn how to improve our programs using the edit -> execute workflow. * learn more about the commands and their options so that we can write more powerful programs * learn how to make our programs play well with other commands

Note that I'm deliberately avoiding recommending a specific editor or programming language for your workflow. You can choose whatever works best for you. Instead I'd like to leave you with this thought:

    A - Always
    B - Be
    P - Programming

Always. Be. Programing.

Always be programming! [2]

Treat every command like a program you intend to keep, and you'll start writing better and better commands; commands that you'll reuse, that will automate your workflow, that will help you spend your precious mental energy on thinking about how to solve important problems because you've delegated as much of the tedious grunt work to the computer as you possibly can.

Best of luck, and enjoy the journey!

[1] This is not strictly true but is useful as a starting point for this thought exercise. See the history command, for example.

[2] (Since it's Christmas) https://www.youtube.com/watch?v=J_vSirIJEsY

  ls -l

I never thought about it as a this or that.

When coding, I prefer an IDE or editor of my choice with autocomplete, syntax highlighting and auto-format.

The command line I see more of an alternative to the window manager. Depending on the type of software CLI(web-server) or GUI(image manipulator) is the way to go.

Wow, this is really good question that I didn't see very often around here. My answer would be try and use both. I learned to use CLI while I was playing with Linux and FreeBSD in High School (and I am using it since than every day). But I like JB products. I use IntelliJ and PyCharm on regular basis (yay for Student Licenses). But Git for example I cannot stand in GUI. I am so used to command line that I have tried just few times.

In terms of CLI, for me, I am thorn. I used vim+tmux+zsh for few years, and 2016's New Year's Resolution was to use Emacs and write Lisp. And I did. Emacs grew on me very fast, and now I am using it for 75% of time as my main text editor, but from time to time, I jump into Vim to skim source code or do some little edit, since vim feels to me much more natural in terminal environment. (Emacs is beast on it's own, where you launch terminal inside Emacs).

So, I think everything is matter of taste. Nothing will make you better programmer than programming and thinking. But for example Emacs was amazing introduction into Lisp for me, since I learned a lot just by playing with emacs and understanding how it works.

So my final recommendation. Install IDE's. If you have some project or homework, do it in them. In your free time, install Linux/macOS/*BSD, tweak system to your liking, install zsh/fish, write a little bit of bash, use git inside it, and you will gradually notice how you are becoming more and more comfortable around it. Until the point where you spin your terminal in full screen and use it for everything, from file searching and managing to programming.

IDE or text editor + CLI tools?

The answer depends on the programming language which you have chosen to use at this stage of your learning process. Each language has its own community, and in some of those communities, IDEs predominate. In others, it is CLI tools.

If you use the tools which are dominant in your community, reading books, blog posts, and StackOverflow answers will be easier. Pairing with other programmers will be easier. You will be able to watch screencasts and apply the tricks which you see. And so on...

My advise is : use whatever works for you.

There was a swift support in emacs on day one when the language was announced.

It depends on whether you want to be more productive today, or tomorrow.

An IDE will be faster to pick up, and will take less time to customize. Command line skills are better for automating more and scripting more, but have a steeper learning curve.

Only you know which is a higher priority for yourself. Personally, I started with an IDE and then eased myself into command line once I had a solid grasp over coding.

I work with both depending on context.

Terminal based ones are very good :

- when you are working on REPL environments.

- small/short programs not involving lot of modules

- when you are learning or trying to learn a language/toolkit/framework

- training yourself for minimum tooling work experience.

IDEs are very good :

- when you are preparing to work on large projects with loads of modules

- when collaboration is more important than learning with insistence of a shared dev eco-system

- to quickly complete boiler plates & refactor larger artifacts

- when you are focused on making not only yourself but a whole team with varying levels of skills productive.

- when working with IDEs is actually productive for a given ecosystem.

The above are not complete but an average approximation of experience i've gained so far. The last point is where experience from someone using a given IDE for a given ecosystem really matters.Some of the IDEs might at times make it counter productive , e.g. in new languages with new IDE features might have a rather slow unproductive experience. I have experience with IDEs (JBs too) when refactoring something in a new plugin or a language,when an IDE would just hang!

It depends on what you want to make, in my opinion. For anything scientific (Python) or web-based (clojure, javascript), I usually choose to use command line / text editor with build tools like webpack or leinengen. If I were to make an Android or iOS app, I would use the IDE that they give you (Android Studio or XCode) since it ends up being a better experience at the end of the day.

Personally, I learned command line first, and I think its the better way to go overall, since IDEs like JetBrains run the same stuff under the hood, so it will be easier to pick up since you know what's going on better.

Vim is a way of text editing that shouldn't be tied to Vim the program. I use Vim emulation with Emacs, Visual Studio, bash (to edit the command line) -- and I cannot imagine not having it.

It's like when you see a non-tech-savvy user slowly mousing around instead of keyboard shortcuts -- that's how I feel watching non-Vim users edit text. So Vim is orthogonal to your other choices. You should get around to playing with it purely as a way to edit text properly. http://vim-adventures.com/ is a great fun way to start to get Vim powers.

I'm not some old Vim user - I only picked it up a couple years ago to see what the fuss was about. I installed it into Visual Studio and left it in insert mode most of the time, then slowly got more powerful over time. Do the same with IntelliJ: https://www.jetbrains.com/help/idea/2016.2/tutorial-using-in....

Edit: As to your actual question, for what it's worth I started with the high-level stuff. Both in languages and tooling. The key is to always be curious about the lower levels, and work over time to understand them and move down the stack to fully understand your tools.

It'd be great if there was a proper survey or study on developer effectiveness vs if they learned top-down or bottom-up.

I went from Windows over various Linux-distributions and BSDs to MacOSX over the last 15 years.

I did my programming (various languages) in vim for several years, after that in TextMate on OSX and now mostly in IntelliJ IDEA (well, and still TextMate).

While I use the terminal the entire day for various commands and tools, I seldomly do any text-editing in it anymore.

I don't miss vim one bit, I wouldn't recommend anyone to learn it. If you have OSX look at TextMate, you can script and "power-use" it too.

Honestly, more than tooling, curiosity, grit, and reading code are the most important.

On curiosity: I was a graduate student in CS and TA'd a lot of courses and now I do a bunch of interviewing at my current job. One of the things that I often find lacking is curiosity. Someone kinda knows "if I put it in this shape, things seem to work." They don't care how it works or what kind of trade-offs might be made. Worse, they often have somewhat magical thinking. Algorithms can be clever, complex, etc., but they can't be magical. I'll give you a more concrete example. A co-worker wanted to make a column in our database searchable by sub-strings (so that a search for "idea" would match something like "IntelliJ IDEA"). They knew that indexes "made looking over a column in a database fast", but never had the curiosity to know how it made it fast. Of course, indexes (generally) are just a sorted data-structure so looking for something not at the beginning doesn't really work. The point of this is to say that curiosity is definitely your best weapon. While others are guessing or finding incantations that "work" (though they might not completely understand why), you can understand why something works or why something won't be a solution (even if it's functionally correct and "works fine" on small data sets).

On grit: often times, you can get to a point where it feels like "I'm nearly there." You then decide to reward yourself with a little kick-back time only to come back to that piece of code and realize that you weren't nearly there. I'm not suggesting that you don't take breaks or that breaks can't be helpful. However, there's a lot to be said about gritting it out and getting through a chunk that might be hard. Often times, something can look like it will work, but then doesn't. Code can be hard and defeating at times, but having the grit to power through some of the hard times can be invaluable.

On reading code: if you want to do serious development, you're going to have to read code more often than you'll write it. Documentation and comments become out-of-date, libraries can be poorly documented, and Stack Overflow won't help you with internal company code. It's easy to fall into the trap of feeling that you're very good at writing code without being able to read it well. Not being able to read code will mean that you're a lot less productive and that you're always leaning on someone else for help. It also means that you're more likely to make mistakes in your development. Reading code is a hard skill. Writing code, you just yourself and the compiler to care about. Reading code, you have to care about the compiler, the other person, and potentially years of changes to the code that have built up little nuances. But it isn't an intractable problem. You can do it and you'll become more productive and

In terms of your specific question, I think you'll learn tooling as you go along. Don't get too obsessed with tooling - it's an easy trap to fall into thinking that you'll finally be productive when you have the right setup. Also don't worry about mastering them. Build something with the tools and you'll naturally find new, useful things. An important thing to remember is that it often doesn't matter if someone knows a way of writing a small piece of code twice as fast if they spend weeks googling how to write it twice as fast, worry about things that don't matter, etc. If it takes you 20 minutes to write it and it takes them 10 minutes after a week of not getting anything done, you've moved on to way better things.

Personally, I wouldn't code in a language like Java without a good IDE. A good IDE will basically write the boring parts of code for you. More importantly, it lets you use libraries without so much googling. I can do `varName.` and Intelli...

ok I'll just cut to the chase: learn the IDE.

There's no absolute rule, since everyone is different; this is just my opinion based on my experience.

I gained knowledge of the command line about 3 decades ago. It's been useful for all that time, and I expect it to be useful for at least the next 20 years, too (assuming I'm still around). That's a span of half a century; seems like a good long-term investment.

I also learned many different development environments; they were very useful, too, but they had a much shorter half-life. At one time I could read source code by reading the pattern of holes in a punched paper tape; very useful for "mastery" of DEC PDP-8 development, not so useful now.

So both command-line and IDE are good things to learn, but in terms of "mastering," it might be good to save that for the command line. I would say definitely learn the IDE, but only enough to get things done with it and to get general knowledge of how IDEs work. Detailed knowledge of every last option, bell, and whistle in one particular IDE may be of limited long-term usefulness.

If those are my choices, then I vote for command-line, hands down. I've been doing this stuff for 20+ years, and if there's anything I've seen in this business that has remained constant, it's unix-ish shells and the presence and usefulness of vi.

Here is my 2 cent: Java developer for about 10 years. CLI is always good to know, Vim, Emacs learn them if you like them. But if you want power and easy overview of large collaborative projects with a lot of code, which mostly working at medium to large companies is all about, you should use an IDE. I didn't have a choice at some places, they just said: "we use IDE x here". Learning Jetbrains IDEA took me a while though but today I love it. If you're only coding small projects for yourself you don't need an IDE but I use an IDE in those cases too.

>Maybe Vim is a thing of the past? Maybe Vim is more useful to learn because it will always remain (it will always be installed on any Unix OS)?

Plenty of people use vim still, and gain a lot of productivity out of it, as others have said here and elsewhere. But it takes time to learn it well enough to get the full benefit. You can learn it incrementally, though and realize benefits as you go along. In fact you can even start with vi, the predecessor to vim (which stands for VI iMproved); vi is quite powerful in its own right (though vim is more), and may be somewhat more universally available than vim (not sure of that last point these days). Anyway, vi's commands wil be mostly a subset of vim's, so any learning of vi will transfer to vim too.

Might want to check out my really basic [1] vi quickstart tutorial for that. It can be read in under 10 to 20 minutes, and you can start applying it right away. I first wrote it for a couple of friends, who were Windows sysadmins in the company where I worked at the time. They tried it and soon after told me it helped them to get up to speed with the basics of vi quickly (they had been given additional responsibility of a few Unix boxes, so needed to know vi - this was before vim was well-known). I later published it as an article in Linux For You (now Open Source For You), an Indian print-format computer magazine.

[1] There are many vi/vim tutorials that are more advanced and cover more than mine. Also, some of them cover vi/vim in a way that really gives the true power, one key such area being understanding different cursor movement commands and text changing commands, and how to combine the two sets together (basically, the Cartesian product of them is mostly possible) to achieve larger / faster editing effects. But mine was purposely kept simple and does not cover that, so you can get started faster with vi using it - since you said (and other commenters advised) that you do not want to spend a lot of time on tools instead of actual programming, which makes sense. You can still read those other vi/vim tutorials later whenever you are ready.

You can get the vi tutorial from here (for free):

https://gumroad.com/l/vi_quick

Vim is very well baked in to our culture. If you have keyboard shortcuts enabled in Gmail, it's vi commands. Not going anywhere soon. And most IDEs have a vi mode if that's your thing. I find the keyboard interface fast, fast, fast.

Vim itself is useful if you have to do anything on the command line and once you learn the basics you'll ditch pico and all the others and never look back for doing any non-trivial editing.

Extending vim (or emacs) is largely the trick - you need the right plugins to support the type of things you're working on - go to github and search for vim config and you'll find 8,050 repos with peoples favorite setups, often with instructional videos or text.

Certain programming jobs are legitimately faster with vim and the right plugins, others, especially if you're working in a team environment that uses an IDE are obviously better with an IDE.

A friend was in your shoes a few years back (young, starting out) became a vim guru, aced a job interview now writes java/clojure with IntelliJ as does the rest of his team. I asked him, he is super glad he learned vim so well but can't imagine working on his current codebase with it, but he still uses vim regularly and often.

And I liked vram22's comment about automation. I learned it as '3 or more use a for' which has boiled out to if you find yourself doing something 3 or more times, think of a way to abstract or automate it.

Wow, I didn't expect so many replies! Thank you very much! I will read (and re-read) all of them.

I don't know about Vim, but Emacs is not strictly terminal-based. In fact, it's GUI mode has way more features! It has modes for pretty much any programming language under the sun, with the functionality that pretty much rivals IDEs. It can also be used to edit files remotely over SSH so you don't even need to have it installed everywhere.