If a programmer is a knight, then their integrated development environment (IDE) is their legendary sword. Under the cover of dark mode, they speed through the plains at 200 wpm, reining their horse with custom key bindings from an ergonomic gaming saddle.
If you really can type that fast and spend eight hours a day coding, putting so much emphasis on your setup may benefit you. If not, It’s probably a waste of time.
Right after the allure of choosing the “perfect programming language” comes the “perfect environment” for it. Or worse, for all languages you intend to learn. It is laughably easy to get trapped in pondering what programs you should install to optimize your productivity… even before actually learning the languages you want to use. Such a view is based on a flawed concept of an end goal, where you believe you know exactly what tools you will need in the distant future. Coding at any meaningful capacity will never be predictable. The vast majority of time spent by a programmer is on testing, debugging, and looking up the errors on online forums, rather than writing new code.
IDEs tend to have way more features than code editors, but for most purposes, there are only two significant differences: 1) IDEs often require you to set up “projects” before you can run any code, and 2) they have a compile button for languages that require compiling. VSCode and Atom are examples of code editors. You can technically run, say, Java on VSCode, but setting it up to compile the files before running them is usually a headache. Since scripting languages tend to be easy to run, you can usually work with them using just a simple text editor and a terminal without much grief.
Speaking of terminals, there is another category of text editors that has its own following. Terminal-based text editors such as Vim are known for being some of the most efficient, due to their many key bindings. Vim in particular has quite a high learning curve and can be customized to the point of being an IDE. I don’t believe that it’s worth the learning curve if you don’t already code for many hours a week, but I would suggest learning just the very basic keys for editing, saving, and exiting. It’s useful when you work with servers since it tends to be pre-installed in Linux-based operating systems. It’s also kind of a meme that Windows users don’t know how to exit Vim.
But wait! There’s one important detail I left out: setting up this stuff is ~fun~. Yes, I spent the past several paragraphs explaining why it probably won’t give you any practical benefits, but that doesn’t make it boring to do so. If you just enjoy searching for lists of “Top Ten Best IDEs in 2021,” there isn’t much harm in over-engineering your setup; to say otherwise would just be a call for conformity. In my book, if you have fun with it, then it isn’t inherently a waste of time.
Entering the world of competitive programming can be an exciting moment. The possibility of being awarded for a skill you have honed in on for years is incredibly intriguing, but at the same time, it is the beginning of your competitive programming career, and as always, there are a couple of novice mistakes to be made.
The most difficult part of a good programming project is coming up with a good idea in the first place. Why? Because millions of people know how to code and some of them are very good at it, and there are countless ways to efficiently learn how to code but any tips for coming up with ideas are inevitably vague.