As a beginner I would think that given how constrained learning time (and effort) is, learning to use a particular IDE (in any kind of depth) has the lowest priority. But that's just my opinion.
In the end you'll likely have to learn the IDE that's already in use by the team you are joining; that may be VS Code but that's not guaranteed.
Also being able to use a prevalent basic editor like nano in a text-only terminal (via SSH) can be incredibly useful.
Maybe it's because I've always had a bit more standing after joining the industry (was freelance and public service prior), but I've always had the option to use my own IDE. I've rarely found teams using IDE features that were a) unique to the IDE and b) necessary for the process. So there was (beyond licensing issues) never any need to strictly use the team's IDE.
Getting comfortable with an IDE is very useful insofar as it gets you comfortable with your own workflow, which you then need to integrate with the team's workflow. I don't think that's a consideration for beginners, though.
Edit: I very much agree on the closing point, though: Please, for the love of god, get comfortable with a CLI editor. No matter which, but using the CLI for things such as version control and conflict resolution is very very useful. I've stunned juniors with my decision to just open a shell on their PC and resolve conflicts in nano, because it just works a lot better for me than the IDE GUI tools.
Sharing basic competence over a common, endorsed set of tools (whatever individual preferences there may be) should lower the friction for collaboration among team members.
Oh, I do agree on that (hence the edit about using nano for conflict resolution). But generally I expect trainers or Senior devs to be able to cope with the difference or at least take the time to aid in figuring the details out. Using a shared toolkit is very helpful, but it shouldn't be a barrier to entry, is my point I suppose.
If you're just getting into things or you jump between different sets of languages (or even if you just want something relatively lightweight), this is definitely what I'd recommend. There are a lot of things it can be configured for just because of the ecosystem.
Since I know I'm gonna be in the PHP ecosystem for a while, I finally made the jump to PhpStorm. But I still have VS Code installed in case I want to try something else.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In my opinion, vscode is a very efficient, compact and powerful editor
I agree!
IDE divide (2004)
As a beginner I would think that given how constrained learning time (and effort) is, learning to use a particular IDE (in any kind of depth) has the lowest priority. But that's just my opinion.
In the end you'll likely have to learn the IDE that's already in use by the team you are joining; that may be VS Code but that's not guaranteed.
Also being able to use a prevalent basic editor like nano in a text-only terminal (via SSH) can be incredibly useful.
Completely off-topic: The Rule of Least Power - i.e. more powerful isn't always better.
Maybe it's because I've always had a bit more standing after joining the industry (was freelance and public service prior), but I've always had the option to use my own IDE. I've rarely found teams using IDE features that were a) unique to the IDE and b) necessary for the process. So there was (beyond licensing issues) never any need to strictly use the team's IDE.
Getting comfortable with an IDE is very useful insofar as it gets you comfortable with your own workflow, which you then need to integrate with the team's workflow. I don't think that's a consideration for beginners, though.
Edit: I very much agree on the closing point, though: Please, for the love of god, get comfortable with a CLI editor. No matter which, but using the CLI for things such as version control and conflict resolution is very very useful. I've stunned juniors with my decision to just open a shell on their PC and resolve conflicts in nano, because it just works a lot better for me than the IDE GUI tools.
Sharing basic competence over a common, endorsed set of tools (whatever individual preferences there may be) should lower the friction for collaboration among team members.
Oh, I do agree on that (hence the edit about using nano for conflict resolution). But generally I expect trainers or Senior devs to be able to cope with the difference or at least take the time to aid in figuring the details out. Using a shared toolkit is very helpful, but it shouldn't be a barrier to entry, is my point I suppose.
If you're just getting into things or you jump between different sets of languages (or even if you just want something relatively lightweight), this is definitely what I'd recommend. There are a lot of things it can be configured for just because of the ecosystem.
Since I know I'm gonna be in the PHP ecosystem for a while, I finally made the jump to PhpStorm. But I still have VS Code installed in case I want to try something else.