So coding is only a small part of DevOps. DevOps can be thought of as a way to think and do stuff, rather than a tool or something you “use”. You don’t just suddenly “do” DevOps, you need really buy into the idea.
So one of the first things you’d want to know about DevOps is why it matters compared to more traditional approaches to software development. Traditionally you’d take a waterfall approach, but with DevOps you take a vastly more “iterative approach”, where you get feedback, and automate as much as possible. This is a super condensed simplified example, but that’s the main idea driving DevOps. The idea is to iterate and respond to user needs faster, and more efficiently
Now being a DevOps engineer is more or less the same as any other engineer, except you will have to communicate with more people than just your project manager. You might have to interact with operations (IT, tech support etc), other developers, security specialists, etc. DevOps isn’t where you do both development and operations, even though it could be, it’s where everyone with stake into the product gets to provide input at as often as possible.
Generally you will find companies will perform DevOps differently, but the core ideas should always be there.
If you like the sound of being a DevOps engineer, then just stick with learning how to code/program, while also spending some time on getting familiar with more tooling. Stuff like Linux, using the cloud, automation tools, testing, git, Docker are all used heavily in DevOps.
I usually don’t reference paid-for stuff, but I’ve been interested in DevOps since I started out as a dev and never found anything better than The Phoenix Project which is actually a novel about DevOps. It’s a great novel that goes into DevOps in a fun an engaging way. I learned a lot about DevOps without actually trying haha.
The novel follows a lower level IT manager who gets assigned an impossible project to be completed in a few months. The manager is helped by a “guru” like board member who teaches him the “three ways”. Its a fun novel, it does get technical, but I wouldn’t consider it a requirement to actually reading it. Anyone who has ever worked in a job filled with bureaucracy will see themselves somewhere in the book
There is a handbook that goes into the hard-core details about how to go about DevOps as an organization, but its definitely aimed toward management.
So go out and keep learning, read into what sort of stuff DevOps focuses on and keep on learning those things. Just remember DevOps isn’t some technology, its an idea, hell you could even say its a culture.