
Ask HN: Should I invest time on mastering the command line or the Jetbrains IDE? - skdotdan
Hi! I was a self-taught, beginner, developer. Now I&#x27;m studying computer science&#x2F;computer engineering. Currently I code on Ubuntu using Sublime Text, and I know a few bash tricks to compile, diff and so on. I know that, apart from learning programming and algorithms, I should invest time on mastering some programming tools in order to boost my productivity, because I&#x27;m damn slow.<p>I reckon that I have two options:
-Try to master the Unix command line and a terminal based editor (Vim or Emacs).
-Try to master the Jetbrains IDEs (all of them are equal, so if you know Intellij tricks, you know how to use PyCharm).<p>Please don&#x27;t tell me other options because I&#x27;m already overwhelmed with having to choose between these two :P<p>And I think that both are excellent options, and there is no univesal answer but...<p>Could you, as master developers, give me a piece of advice? I&#x27;ve been coding for 2 years now, but I&#x27;m still uber noob.<p>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)?<p>Thank you very much! I have been reading HN for years (specially the comments), I really appreciate your opinion. I have just signed up to ask this question.
======
mdasen
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
IntelliJ will tell me all the methods, what their parameters are, etc. If I
have a method and I'm wondering about it, I can command-click to jump right to
the code for that method. That makes it really easy to figure things out
without googling or guess-and-checking. It will highlight a lot of errors and
prevent a lot of problems. However, this value decreased for non-statically-
typed languages (or statically typed languages without the same tooling).

The JetBrains tools are quite reasonable and you certainly won't be learning
something useless using them. Don't get obsessed with tooling, build things,
stay curious, have grit, and read code.

~~~
btschaegg
I agree with the basic premise, except for the tooling bit. Yes, tools aren't
everything and you shouldn't obsess about them. But just picking one and
calling it a day is - at least in my opinion - a waste, if you havent even
considered the alternatives. Curiosity also plays into the environment you use
to develop: I've known a couple of people who would almost recoil from any
tool that was not part of the IDE they learned a decade ago. This is not
helpful. So, if you can: Try what interests you. See what you like after a day
or two.

For example, I like the *NIX command line very much, just because I can
quickly improvise (at least temporary) solutions for a specific problem. This
doesn't mean that it is a silver bullet, but it's helpful to know your way
around it, and without some curiosity, I would never have tried it.

Also: You dont have to be an expert - you'll get good at the things you use
most, which should be those that you enjoy working with. If it doesn't
"click", you'll find something else that suits you. Sometimes it's just useful
to have tried something for a day or two - even Vim becomes quite usable after
a couple of hours of figuring out the basic control scheme.

Oh, and also: It's not unlikely the tooling you use will change over time, so
clinging to a specific IDE is not necessarily going to help you. Maybe you'll
work at a place that only allows certain software on some systems. In which
case, knowing your way around the basic system (Bash, Windows CMD/Powershell)
will almost certainly be really helpful at some point. So just try to be open
for new things :)

------
MichaelGG
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/](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...](https://www.jetbrains.com/help/idea/2016.2/tutorial-using-intellij-
idea-as-the-vim-editor).

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.

~~~
btschaegg
I guess it's not so much top-down vs bottom-up per se - it's just that some
people stop after the top level. Yes, that's not possible if you start from
the bottom, but then those people most likely would have gotten frustrated at
the bottom anyway...

On the other hand, I guess someone reading HN is rather likely of the kind
that likes to open the lid and find out how things work.

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

~~~
vram22
>And I liked vram22's comment about automation.

Thanks.

>I learned it as '3 or more use a for'

Nice mnemonic way of putting it, hearing it for the first time :)

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

~~~
skdotdan
I really appreciate your recommendation.

So, I should definitely learn both, but start with the IDE way, because it's
easier.

~~~
wilwade
Not just easier, but less cognitive load. You are still learning a ton about
programming (we all are, but). You also hopefully have a life outside of
programming. JetBrains (and others) allow you to easily learn the IDE along
the way, but also can help with good practices. That is worth a lot of
valuable time.

~~~
skdotdan
Okay. Thank you.

------
jt2190
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](https://www.youtube.com/watch?v=J_vSirIJEsY)

~~~
skdotdan
I appreciate your advice. I will try to apply it!

I've already automated some tasks. However, I find it difficult to write
useful bash commands that I will reuse later. Maybe I should learn a scripting
programming language.

~~~
macavity23
Learning Bash is both incredibly useful and will also make you richly
appreciate more modern languages :)

~~~
skdotdan
Okay :)

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

~~~
skdotdan
Thank you very much for your answer. I believe I will follow your advice.

------
brudgers
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...](https://shop.fsf.org/books/gnu-emacs-manual-17th-
edition-v-245)

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.

~~~
skdotdan
First of all, I appreciate your comment.

I haven't decided if I will try to learn Vim or Emacs, yet. I'm still in a
previous phase: should I prioritize improving my command line/terminal editors
skills or mastering the Jetbrains set of IDEs?

I know that you can use both Emacs and Vim bindings on Intellij IDEA (and on
many other programs). However, at this point I really can't take both (Emacs
and an IDE), because I'm a beginner and I can't learn everything at the same
time.

But I take your advice. I have to admit that I was a bit biased against Emacs,
but if follow the "terminal way", I will definitely give it a try.

~~~
brudgers
[http://norvig.com/21-days.html](http://norvig.com/21-days.html)

To me the best thing a beginner can do is to recognize that being a beginner
means not being in a position to make expert judgments. Learning both Emacs
and IntelliJ along side the command line allows each process to inform the
other. Not learning Emacs and the command line does not mean that you will
learn IntelliJ much more deeply or quickly. It's going to take considerable
time no matter what. Learning other things along side it will provide context
for judging what IntelliJ offers.

~~~
skdotdan
That's very true. It was just a fancy assumption that I did.

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

~~~
skdotdan
Thank you for your answer. I see. Sometimes, CLI is my only option (when I
code on my Android tablet, with Termux).

~~~
vram22
How comfortable do you find it to code on your Android tablet, compared to on
a laptop or desktop? Never done it and interested in such an option. Sorry for
the partly off-topic question.

~~~
skdotdan
I only do it sometimes. I don't see it as an alternative, but as a bonus. It's
nice to be able to quickly edit a file and commit to your giy repository.
However, I'm not very fast at it, because you have to use Vim or Emacs.

I recommend you take a look at the list of available packages:
[https://github.com/termux/termux-
packages/tree/master/packag...](https://github.com/termux/termux-
packages/tree/master/packages)

clang, git, emacs, vim, go, erlang, ssh,...

But it won't replace your main laptop.

~~~
vram22
Thanks, will check that.

~~~
skdotdan
You are welcome.

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

~~~
skdotdan
That's very true, although I would say that mastering an IDE must be way
easier than mastering, say, Emacs or Vim.

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

~~~
skdotdan
I see. Thank you for your advice.

However, while it's true that some programmers are (too) locked in their IDE,
maybe this allow them to focus on the code itself, in a more abstract way.

~~~
dozzie
Not really. Those of my acquaintances who didn't understand how the
compilation and deployment processes worked, weren't that good programmers
either (though I wouldn't go as far as to draw a causation relation here).

~~~
skdotdan
Ok, I see. Good point. Thank you.

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

~~~
skdotdan
That's very true, but it seems to me that today Jetbrains IDEs are becoming a
sort of standard. They have even an IDE for Go.

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

~~~
skdotdan
I will take a look at Tower, thanks!

I know that I should try both, but which should I start with first? Because in
order to be able to really try a tool such as Vim, I reckon that you have to
spend at leat several months. So maybe the order is important.

~~~
tedmiston
With Vim, you're right, but that's also one of the most extreme examples.

I would stay start with whichever has a lower upfront learning curve, which in
most cases means the GUI.

~~~
skdotdan
Good point.

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

~~~
skdotdan
I'm thinking about using IDEs for university projects and trying the command
line tools for my side projects.

~~~
bigmanwalter
I tend to use one tool for everything I'm doing and then when I switch it's
everything at once.

------
th3iedkid
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!

~~~
skdotdan
Great explanation. Since at the end of the day they are only tools, I will try
to learn both.

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

~~~
skdotdan
I see. I reckon that it's not even possible to develop for iOS or Android
without the official IDE.

~~~
headcanon
Android and iOS have command-line tools available to build projects, but
they're usually meant for CI tools. You can do it, but its not worth the
hassle unless you know what you're doing and why. Android may be easier since
more of their build process is text-editor-friendly, but IntelliJ is such a
pleasant tool to work with why bother?

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

~~~
skdotdan
Okay, I see.

------
vram22
>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](https://gumroad.com/l/vi_quick)

~~~
skdotdan
Thank you very much. I'm going to read the tutorial, for sure.

~~~
vram22
You're welcome :) If you have any feedback on it after reading it and using vi
for a bit, feel free to send me an email (address in my HN profile). I may be
updating the tutorial after a while, to add a few other useful beginner vi
(and maybe vim) features, and to include my own brief take on the "true power
of vi" topics I mentioned in my earlier comment; so I would appreciate any
feedback, and will try to incorporate it in the next version.

~~~
skdotdan
If I have any suggestion, I will tell you. However, I'm slow, so don't expect
immediate feedback ;)

~~~
vram22
No problem, take your time :)

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

~~~
skdotdan
Thank you. I may buy a Mac this month.

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

~~~
skdotdan
I didn't know that. I will take a look at Emacs, definitely.

------
jitendrac
My advice will be to use IDE as main development work, and make a handy habit
of using the command line tools.For example use some editor while using
development,use command line gradually, learn a new trick every week well
implement it. For small tasks like editing configuration files, viewing logs
use command line etc.

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

~~~
skdotdan
Good point.

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

~~~
skdotdan
Thanks for your reply. My passion is actually coding. Although I'm still a
noob, I find it very interesting and I really want to be a good programmer.

However, I'm pretty slow at translating my thoughts to code. Not only because
I have much to learn, but also because I don't master the tools that we
programmers use to write our thoughts. I mean, sometimes I have the code on my
mind, or I know what should I (for example, debugging a particular function),
but I'm so slow at doing it.

A friend of mine has used Intellij IDEA since he was a teen and he can do
incredible things. He can refactor a class in seconds. He can find extremely
fast a particular bug by debugging step by step. I also know people (older
than me, by the way) that master vim, and they say that thanks to it they have
experimented a huge productivity boost.

I'm afraid that if I invest time on understanding Vim, I will be investing to
much time on the tool itself (which is not the end, but the mean), instead of
focusing on learning algorithms and programming skills. But I really don't
know.

Also, this could also influence my decision on which computer should I buy.
With Vim/Emacs it's ok to have a light notebook (portable, with great battery,
but no powerful), while if I choose the Jetbrains way, I should definitely buy
a powerful computer.

(by the way, sorry for my English, I'm not good at languages)

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

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

~~~
skdotdan
Right. That's what other students tell me.

------
Jugurtha
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/](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](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!

~~~
skdotdan
Thank you very much for your comment!

Maybe my original post focused too much on productivity. It's very true that
it makes no sense to be worried about these things when I'm still a beginner.

However:

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

Ok, but, I still have to use some tools in order to be able to read and write
code. And it's not neutral. Put it this way: should I code and read code with
the command line + Vim/Emacs or with IDEs ala Jetbrains? I mean, in my
original question, replace "productivity" with "ease of coding learning". I
must focus on learning how to code, but: -If I do it with Vim/terminal, maybe
I focus on the tool instead of the code itself. -If I do it with a powerful
IDE, maybe I can't learn the basics properly.

I don't know if I'm being clear enough (English is not my native language and
I'm bad at languages).

I will definitely try to get as many internships as possible. However, it's
difficult for me to get the first one, because they look if you have had any
experience before, and of course I haven't. I just need the first one to
demonstrate that I can be a good intern.

~~~
Jugurtha
This is a false dilemma. It's not this XOR that. You will definitely use
different tools. This is practically an unavoidable true fact, or a false one
that is not practically avoidable.

People don't learn to use a screwdriver to the exception of wrenches; soldiers
don't learn to use pistols to the exception of rifles; surgeons don't learn to
use scalpels to the exception of forceps. It's not realistic, so using one
will not seal your fate.

I think the reason it may be causing you trouble is that you think learning
these tools is hard which makes you think you have to _manage_ resources and
make tradeoffs. It's hard to study Engineering and Medicine because the time
commitment and effort for each almost make them mutually exclusive
simultaneously, and rarely done sequentially.

The good news is that learning CLI/IDE is not hard. The fact it's not hard is
also the bad news, because the hardest is yet to come. This is similar to a
person finding learning the alphabet of a language hard when it's just the
apéritif.

The reality is that you can learn about 80% of what you will be doing in the
CLI in less than an hour. The remaining 20% will take you 40 years or
something (well, you find people on Stack Overflow who know so much about
these editors and tools, that the only technical question your ask yourself is
which one they've used to draft the contract with the Devil).

As in most things, few things are used the most. The number of words you know
is the millions; the number of words you actively use is more in the tens of
thousands. The number of biomechanically possible movements is important, the
number of movements we end up doing daily is less impressive.

My point is: neither constitutes that big of an investment, and you will end
up using different ones anyway, so don't worry about it. I wouldn't hold my
breath if you were to look for someone who's used a tool exclusively.

~~~
skdotdan
Great answer. Thank you very much.

