TLDR: And that I think is the real shift of thinking:
When you shift from being a learner to a problem-solver.
I realized that when you finished a course and learn some stuff and then work on actual projects, you seldom go back to the course and re-watch particular sections related to the issue you're troubleshooting.
Instead, you either a) go to your own notes or documentation to see if you've resolved it before (if you trust your documentation well enough), or you take the much easier and quicker route, b) you google it or search for sample use-cases in Youtube.
So, I think structured courses are really great when you're at the stage of discovery. But when you are trying to implement it to solve your own problems, you follow your own instinct to google it and hope someone has raised the same specific issues in Stackoverflow or hope that someone has made a video of it in Youtube.
Another thing, courses tend to get outdated easily especially when technologies grow at a really, really quick pace.
One day EC2 instances are limited to 20 instances per region, the next day its now based on number of vCPUs. Today you have a Zookeeper that handles all the syncing stuff, tomorrow it's removed entirely. Some changes may be small and some changes may be just a button moved in the UI, but add it up to all the other stuff that you're working on and they start to become significant.
One day you have weeks to play around on this fascinating new tech you just discovered, tomorrow you just have two weeks to explore it and come up with a bare minimum, usable solution.
I guess my point is, it took me almost 4 years (even now I'm still trying) to shift from a structured, college-tailored type of kind learning to the actual industry-setup of acquiring knowledge. I'm calling the college-type courses kind because you have a clear outline of what you need to follow, starting from the baby steps of firing up your first terminal, to eventually going through harder and more difficult stuff. You have a clear picture of what the problem is and what you need to accomplish first.
On the other hand, the actual industry doesn't lay out all the variables you need. It just presents a list of requirements, and it's up to you figure out what tools you need to use. It doesn't even give you a real problem, and it's up to you to come up with the questions and eventually, with the answers.
I guess this is what you might call ill-defined problems, where an almost perfect and unique solution oftentimes doesn't exist. During my stint at my previous job and in my current job, I've learned so much about how solutions are pieced together. You might have vendor's assistance or external professional services helping you out, but you'll come to realize that solving problems are not as straightforward as they seem. Some tasks need to be prioritized over others and some pressure from the business side may arise midway the sprint, which then prompts you to re-think which of the questions you have on your plate needs to be answered first.
So, the industry's way of learning tend to be a bit messy. You search what you need at the moment and you try it immediately on your test environment to see if it works. If it does, you try to incorporate piece-by-piece to your code. If it doesn't cause too much noise in the logs, if it passed all the unit tests, OAT, and such, and ultimately if everything seems to work smoothly, it might just find its way into production. But wait, here's the catch: you need to have all of it done in four sprints or less.
Now, this could introduce what you might call technical debt which is incurred when you prioritized a quick delivery over a perfect code.
Is this bad? Yes. No. I don't know. On one hand, you can't really perfect a code because it may depend on other factors that's out of your control such as the version of the platform you're running it on or the system updates that other teams are rolling out.
On the other, the quicker something fails, the quicker you can correct it. So it's as if we're always looking for ways to break the system so we can optimize it quickly.
Wait. Where was I?
Oh, yes, a shift of thinking. I guess I've laid out my take on how "learning-on-the-job" differs so much with "learning-on-demand".
So, should I stop taking courses and instead focus on projects and go straight to specifics?
If something's entirely new to you, you will need to build a solid foundation on it. That's what courses are for. They equip you with the basic tools that you (might) need to solve problems.
Along the way, you get to use these tools to answer your own questions. Other times, situations may require you to drop these tools altogether to adapt other tools better suited for the challenge at hand.
I am still confused.
Well, you're not alone. I still haven't figured all of it out yet. I still have a ton of courses in my laptop which I've yet to take. And since time is a limited commodity, I developed a strategy on how I could learn things better and apply them.
If my goal is to take a certification exam, I try to breeze through the course, do the labs, jot down notes, and prep up with some final practice tests. Once I passed the exam, I delete the course.
Yes. No hesitations. I know I wouldn't come back to it anymore and if I try to implement it on a project I'm working on, I'll just do a quick Google search on any error that I might encounter. I also get to pick just the specifics.
Just like when you're picking apples, you get the good ones and enjoy it later.
Bottom line is, I've equipped myself (I really hope I did) with the fundamentals during the discovery and review stage using the course as a tool. For the application stage, it's time to make use of my own tool: my Google-fu.
Currently, I'm prepping up to take RHCSA for next year. So by next year, I'm expecting to have any of the RHEL-related courses completely deleted from my hard drive.
By doing this, I'm forcing myself to think on my own instead of following the same exact steps that the instructor did. If I want to recall how I did a lab, I check my notes. If it's not on my notes, it's probably on Google.
Okay, I think I got it.
If you did, then you're already one step ahead of me and you did a great job. Again, I don't have all the answers yet, I don't even know what the specific questions are. But I do hope and expect to learn more as I go out and try new labs, fail on my code, tail the logs, test out solutions, and then document them. Along the way, I don't just learn. I solve problems.
And that I think is the real shift of thinking:
When you shift from being a learner to a problem-solver.
And when you've solved enough problems, you next shift to a much higher form of learning: passing it onto others.
Top comments (0)