Okay, there's more than one. Alot more. But there's one skill in particular that will help with all of the rest and that's typically the easiest the implement, but the hardest to develop.
Difficult because there's no real way to learn it from books. You sort of have to develop your own workflows and implementations yourself when it comes to this. And typically, it does take years for you to "master" it, though I do use the term loosely.
This cryptic skill isn't a programming language, or a framework or a design pattern. And it isn't a super technical skill that requires a graduate degree. It's simpler than that.
It's the ability to debug your code fast. And by fast, I mean fast. The faster the better.
I emphasize fast, because every developer essentially has to debug their code as they type it. There's no going around that. You write a function, you add some parameters, you return a value and you at some point (hopefully) run it to make sure that your values are valid.
And if they aren't valid, how long it takes you to find the reason why is the thing that you need to improve.
When I used to teach for a coding bootcamp, I would often have students get stuck on various errors in their code, to the point where they were pretty sure that either the browser broke or that React was the cause.
I'll say this. In my 5 years of solely working with React, I've never had the framework fatally corrupt itself and cause me errors. Not that it can't happen. I've just never seen it. And the same is true in my 15 years as a .NET developer.
After reviewing my students code, it would normally take me around 5 to 10 minutes on average to figure out where they had developed errors. And more often than not, it was caused by something very trivial, like an undeclared variable or a typo, or a misunderstanding of how to format a function call.
And the issue isn't that they wrote a typo accidentally, because that happens to everyone regardless of skill level and seniority. No, the real issue was that they had spent hours upon hours trying to figure out why their code wasn't working. Sometimes, even days would pass.
And that's going to hurt you in the long run, both in your learning and in your career. Because in a corporate environment, people do look at your code output frequently, and having written zero code in the span of a week (which does happen) because of an unknown error places you in a bad light with your employer.
And now that you know the skill (or lack thereof), I want to go into a few solutions to the problem. These are the things that essentially alot of new developers fail to do as they attempt to figure out cryptic error messages themselves. And these are the same things that I do now pretty much in order to get it figured out in under 10 minutes. Starting with the most quoted answer ever.
Google it. And I don't mean Google what you think the error is. I mean Google the exact error message. Copy that entire line and throw it into the browser because I assure you, you are not the first human to have caused this error. That may have been true when StackOverflow first came out over a decade ago, sure. But this day and age, you are going to have to work to get a brand new unique error.
If the answers that you find aren't to your liking, or they don't quite fit your particular situation, then it's time to figure out exactly what caused the error. Instead of logging variable after variable (which helps, but not yet), start commenting out your code until the error is gone. Sure, you might need to make some adjustments and add some temporary data to make your now broken code work. That's fine.
The goal here isn't to have fully functional code while you debug. It's safe to assume that your code doesn't work if there's an error present. So the goal is to find that error and then to work your way back to where your code was working.
Once you find the line that is causing your headaches though, there's a good chance that you'll need to dive deeper as to why that line isn't working. If you're dealing with a web request for example, then you might need to log your response to see that it matches your expectations. Often times, you have invalid request headers, but the response might still return a 200 tricking you into thinking that everything is just fine.
Because logging data takes the longest amount of time, I typically add it to the trail end of my debugging. And often times, it isn't even a required step if the previous 2 methods worked out.
You might also want to be careful with logging too many errors, especially if you are working with client side code, as that might reveal too much information to the wrong people. And inevitably, you are going to have to spend more time removing those logs before they get pushed to production.
And lastly, there's a good chance that you will encounter the same errors time and time again. So being able to remember the error messages, possible solutions and being able to run through each one of those solutions to test is key to saving some time. And by remember, I really mean write it down somewhere.
I personally use Notion for all of my personal note taking. Even if you don't ever look back on your notes on a specific error, when the time comes, you will wish you had remembered just what you did to solve for something.
Debugging ability is equally as important as programming itself. A good comparison that I like to use is that of a car maker, who can put together an entire engine, but they can't diagnose a problem with the car later on.
Both things go hand in hand. And if you practice at it, just like you do with your coding, eventually you just get faster and more efficient at the whole process.