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.