Well, I don't fully understand your background from your post, but I call tell you my views on mastering technology and I have been applying UNIX/Linux technology in real-world applications since the mid 1980s until now. I coded this morning over a coffee.
First, it is important to understand there are two basic approaches,
top down and
bottom up and a lot of people get stuck in one or the other approach, but the key to success is to combine both together.
Top Down:
This is basically learning and understanding theory, high level concepts, overall system architectures (and standards), and all the "less than hands" knowledge. This could also include a number of classes and tutorials in "theory".
Bottoms Up:
This is the realm of the hands-on approach where we actually build working systems and applications. This is also taught in universities and in the educational system in general in "lab work"and other assignments where you apply your knowledge to solve a real-world problem your teacher gave you.
So having said that, I can tell you that while both are very important, I consider the "bottoms up" approach to be the most valuable (by a long shot) in terms of really accelerating your knowledge and skills. I mean really, think about; you can watch 100 YouTube videos on downhill skiing or motorcycle racing and that is all good knowledge, but you will never be a great skier or motorcycle racer. However, you can become a great skier or racer and never watch a single YT video or have a single "How to Ski" or "Motorcycle Racing 101" certification.
For me, I have been writing software for real-world applications all my life; and I am currently well on my way to mastering
Vue.js over the past 30 days. Let me tell you how I did it.
- First of all, I watched a lot of YouTube video tutorials (months ago before "going in"). This was before I ever coded my view Vue.js application.
- Then, I started coding some simple Vue.js applications and installed Vue.js apps that others had built.
- Then, I found a template for a very large Vue.js application I liked (after weeks of research), and I started to modify the components for a real-world project.
- Then, I started writing my own components.
- Then, I started optimizing my code, rewriting all the things which "worked" but as I learned Vue.js I realized there were better ways to do things, or I simply "realized" based on past experience how to improve things.
- I still watch a YouTube video every day or so and refresh on theory or learn some subtle variance.
- Now, I'm getting very close to mastering Vue.js at the intermediate level (in around 30 days). I am very comfortable with Vue.js these days (and absolutely love creating in Vue.js).
Now, going back four decades, my first UNIX project, with zero prior UNIX training was to interface a Chicago-based radio manufacturers production line test equipment (all HP) with our HP-UX servers and record all test results in a (Progress) database. This was on a full production system where the company would lose huge sums of money if the production line was down for an hour. I learned the UNIX shell, vi, and UNIX IPCs, system programming, Rocky Mountain Basic (RMB, the language I had to use to get HP-UX to talk to the HP test gear), network communications, client-server coding on UNIX, and more with zero prior hands on UNIX background. I did have experience in computers, and of course had a EE degree, so I was no dummy at the time. HP engineers in Mountain View told me I was the first person they knew of that used the HP-UX shared memory features of RMB to work a in real-world HP-UX app (many decades ago) and so I ended up teaching HP system engineers how to use their own RMB system calls in a real-world app.
So, for my entire career, from pre university to post grad to professional life, in every step, I have coded logic on computers to build solutions to problems. From the TRS-80 to the Amiga, to the C-64 to HP-UX, to Solaris, ATT (3B2s), AIX, Linux and more, more, more. I think I have worked on (or at least examined the code or logged in to) most types of (but not all) UNIX system at least once in my life. All my work was on some "tech of the time". I have being told by many that I have forgotten more tech than most people know, LOL. So, let me tell you this:
The way to master technology is to build working applications that solve real-world problems. You must write code. Code is the language of information technology; and people who do not write code solving real-world problems are "posers', like the consultants who never code but try to tell us how to secure a server or admin a system. There are people who pose as experts, for example, cybersecurity experts, who have never been a real-world cyber attack where they had to defend against hackers in real-time. Imagine that! In fact, the entire industry is pregnant with these posers. I would venture to say that some very high percentage of "cybersecurity experts" on LinkedIn have never written a single line of defensive code, and even far less have ever been hands-on in a real-time cyber-battle. I have written millions of lines of code in my life, and nearly all of it was "not based on some standard or theory or certification" and almost none of it was "not very pretty" but it got the job done during an emergency / situational crisis.
Instead of telling you story after story of what I have coded and why (it's mind boggling, actually), let me tell you this:
Anytime you examine code written by others before you, you will see things that could be written better.
Everyone who writes code does this under some constraint, time, money or both. No one has the luxury in the real-world to write perfectly beautiful code which meets all standards and would make his software-engineering professor proud. Companies do not pay for perfection and "pretty", in general. Code evolves based on the need. It starts out messy, in general, and is optimized as time and resources permit (if it ever does).
I code real-world projects everyday. My code can always be improved. But I have to decide what is the "critical path" and often optimizing code is not the best use of time, but then again, when I have time, I go back and optimize. I did this just this morning, and eliminated a single AJAX network call to a REST API because I dreamed that it needed to be done and woke up with solution in mind, made a coffee, fired up my development environment, and re-coded a working solution (I wrote a few weeks ago) to eliminate a slow network call and optimize the user experience. Actually, I laid the groundwork (in code) for this yesterday, optimizing a back-end PHP MySQL method.
SO
CODE.
Create a project and code it. Dream of a project and do it.
If your work does not permit that, then code your own project at home. If you can't think of a project, then join a volunteer project and code for someone else.
CODE. CODE. CODE.
Coding is fun. It is a great way to express yourself, creatively and artistically, from a digital and logical perspective. Coding is good for the brain. Just don't forget to go outside and get some exercise and enjoy the non-coding world.
Just do it.
And never forget, there are around 100 billion stars in a single galaxy and you have around 100 billion neurons in your brain; so your brain has as many neurons as a galaxy has stars - and that is not including the connections between your brain's neurons! Wow. Think about the gift you have between your ears! Each one of us has this amazing "expensive" living, biological computing creation between our own ears! It's true!
Just use it and enjoy!
Life is a GIFT and a blessing!
Don't get hung up on dogma and belief systems, traditions and social memes, just enjoy your 100 billion neurons and use them wisely every day of your life, in whatever you choose to do.