Learning a new IT skill frequently comes with requirements to learn other stuff not necessarily explicitly declared or obviously related to the new skill when viewed from the curb.
Back at the beginning of the current century, I mentored some mainframers, trying to become Java programmers. I'd done what they were doing and could sympathize. These were mostly, smart, experienced, professional programmers, who hoped to learn Java to expand their existing capabilities and ensure their ongoing value (read employability). The company was hiring new, young Java developers, but thought it a good idea to retain personnel who already owned useful skills and knew the company culture, training them to code Java as well.
The single, most bothersome misunderstanding I identified among these trainees was the belief that their assignment was to learn A language. Some of these people became disillusioned about "learning Java" 'cuz Java was the least part of what they had to learn. These people had learned new languages previously but rarely had to study more than the keywords and syntax in order to employ it.
I suspect that this model generalizes (or will) to some of my current audience. That is, you'll set out to learn a new language, API, library, framework, etc., and get distracted, possibly discouraged, by the fact that there are six other things that you must also learn. When you don't know about those extra requirements beforehand, it can negatively impact your morale and motivation.
Let me detail my extreme, personal example to clarify the point. Think 2003-ish and the proposal that I help someone, who is already a programmer with years of experience in mainframe systems, learn how to program for the Interwebz.
What my company said was, "we're going to teach you Java." What was actually going to be required was:
- Java (what the company said)
- WSAD (complex IDE by IBM)
- AIX (deployment OS)
- some pesky Unix-y word processor
- some pesky Unix-y command language
- CVS (version control system)
- Object Oriented Programming
- Design Patterns
- MVC architectural pattern
- J2EE (not yet rebranded "Java EE")
- JSP-style framework
- JDBC conventions (for talking to IBM DB2 on OS/390)
- the craziness of browsers, so many, many browsers
The shop was raising Full Stack Internet Java developers. The company didn't mean to misrepresent the learning of Java, but failed to teach most of those other topics (brief training in WSAD, CVS, and JDBC). Once I recognized the need, my warnings about the additional baggage served to inoculate these other programmers against confusion about the difficulty of learning Java.
Whatever you've gleaned about studying a new skill, be suspicious there may be other skills, not mentioned or obvious, that are prerequisite or corequisite. Try to ask experts you know whether additional learning demands may lurk in the corners. Don't be discouraged to discover there are extra topics to study in order to gain the specific new skill you seek. Honestly assess whether you have adequate time, if you discover there ARE additional skills to be added beyond your base, target; at least be willing to extend your learning schedule accordingly.
Try to identify as much as possible all of the requirements for gaining a new IT skill. Look twice before you leap and ask advice of people who've trod the path before you.