A step by step guide on how to become a DevOps engineer

As someone that has never worked at a startup before, this seems to be the list of skills a startup might find reasonable for a 'DevOps Engineer'. Every other place I've interviewed or have worked has DevOps Engineer and Site Reliability Engineer being distinctly different roles (SRE focusing on monitoring and logging and DevOps engineer focusing on pipeline and build).

There are also other places like where I am now where every team that works on backend infrastructure (Windows, Linux, Virtualization, Networking) also works on their own automation for their platform. We do have a Platform Engineering team that focuses on K8s and Dev tools such as Artifactory, Gitlab, Puppet.

I have an opinion that if a company has a specific role of 'DevOps Engineer' they are doing DevOps wrong. Also Jira and Scrum are absolutely not needed at all to do DevOps.

devops or sre might as well be a euphemism for sysadmin that can write a little python

Professional devops/infra/ops whatever we're called these days engineer here. I have feelings about this.

1. Learn a programming language first. Pick something common. Ecosystems are more important than the quality of the language. If you feel overwhelmed by choice learn Python. The ideal learning path is high-level -> low-level -> low-level (advanced) -> high-level (advanced). You want the language to get out of your way at first so you can learn concepts, then get in your way as you learn how things really work, and then back out as you learn real software development. Learning version control first will feel completely unmotivated without knowing why the tools the way they are.

2. Absolutely 100% learn Linux. The best infra people have a strong strong background in sysadmin work. And learn networking through the lens of the kernel/low level userspace. Don't try to learn network protocols in a vacuum, learn how they're actually used on real systems.

3. From this point skip right to IaC. You are at the point where this will make the most sense. And unless you have quite the setup this is when you're gonna learn a cloud provider. Pick AWS. This isn't a bias toward them -- knowing AWS will make learning other clouds easier, the reverse isn't true. And tooling, guides, and documentation for AWS is more plentiful. Explore using the console but don't do anything except play around. Assembling the Cloudformation/Terraform will teach you much much more about how the pieces fit together.

4. Now learn CI/CD, and you'll find yourself reaching for containers here because it's such a huge pain without them. Now you have a real motivation to learn them that isn't contrived. Once it "clicks" you'll understand why you might want to deploy other things with it.

6. Don't bother learning "devops the process" -- it's worthless, nobody agrees what it even is, and every company will do it differently anyway. You want your "knowledge" about the process to be as rich as the flavor in a La Croix. All these processes are at their best when everyone only vaguely knows what they are because any sort of strict adherence only makes you lose sight of your real goals.

7. Do not learn k8s until the very end. It is literally the final boss that combines all the other knowledge you acquire in your devops journey and you genuinely cannot understand the architecture, the tools, and decisions until you experience the pain points of not using it.

8. If you can swing a job as a junior then don't bother to learn how to run production systems, you will learn so much better and faster on the job than anywhere else. Have a "homelab" running some semi-production services to play around with and talk about in the interview but be ready that the big leagues will be a lot more involved. Once you are reasonably self-sufficient at your job and ready to move from maintainer to architect then look toward sre books.

This will get you ready to work at shops in the cloud. If you want to do on-prem work it's a different path.

To be fair, that's the last bullet point after all the other (pretty relevant) topics.

And I agree, that's "certified agile". Pretty useless. You can pick whatever "agile" processes are being done in your company in 15min and just go with the flow. A "devops engineer" (whatever that is) hardly needs to know more than that to deliver.

That a fair point, but the whole thing is "learn yourself some devops". If that list ends up building up to that, then you've not gotten the point of any of it and you can't honestly call that last section "devops". There's also some weird excursions on that list, like securing a CI/CD pipeline before we've even gotten to that or getting to k8s way too early.

Spivak's approach is much more in line with what I'd suggest folks do: https://news.ycombinator.com/item?id=33398284