Years ago, I had been myself a tech support technician 5 years when I got into software development, which was my goal from the start. I had the chance to be hired internally in a new role as a developer (in the same organization), and I had the opportunity to learn modern software development (I had learned programming by myself as a teenager).
Lack of experience or skills may stop you from moving into a new role in another organization, so I agree your best chance is moving laterally where you’re currently working. But be prepared that even then, you may not have the opportunities to learn and grow into your new role. Sometimes, it’s because the organization is pressing the team to deliver more quickly. Or sometimes it’s because the team dynamics plain sucks.
Don’t despair. It takes time. Give yourself time. I’ve been spending these past 12 months learning only Kubernetes administration and security, but I realized I spent way too much time studying on Certified Kubernetes Administrator (got 95% at the exam last June). Pace yourself, take your time, but don’t overdo it like I did.
I moved into a DevOps role myself two years ago (again, hired internally), and that’s what I went through: I didn’t learn infrastructure as code (Iac) with terraform on the job. Nor Kubernetes. I was not given the opportunity.
I took matters into my own hands (like you did), learning by reading books and watching video courses on KodeKloud and Udemy (that’s where I learned about KodeKloud, and Udemy constantly has deals on courses), but also working on projects to apply what I learned.
My suggestion: make sure to follow a roadmap to become a DevOps engineer. For example,
For each subject, find how you could apply this knowledge, and work on some project to put your new knowledge in pratice.
For example, to learn terraform, I decided on making a module to deploy an AWS EC2 instance. And I really had a need for this at work: to automate the creation of an EC2 instance in order to test my Ansible code (in my tasks, I had to configure instances with a bunch of software using Ansible and Packer, and everyone in the team used the AWS web console to create EC2 instances manually). On the way, I learned about best practices on how to structure my terraform code, and how to test it. In the end, I feel I learned more by myself, and contributed to improving my team’s practices.
To conclude:
- these things take time, you’re in for the long haul
- pace yourself, take breaks or you will grow tired, fatigued
- don’t try learning all subjects at once: study one subject at a time. Say focused.
- practice what you learned
- find what could be the main use cases for it
- pick one and try to make something that would be useful in an organization, as if you had to do it at work
- for example, you’re learning CI/CD? Make a pipeline for a real app. You can find example apps as docker images you could use. Do it gradually.
- a simple pipeline, just integration, which ends with building a docker image
- add tests
- etc.
- when you feel you are familiar with the subject, move to the next one
- don’t look at the mountain you’re trying to climb: focus on waypoints along the way
- don’t obsess about the time it takes
Hang on. Cheers.
