[InvaderFizz]

Yes. I spent about 10 years doing military Satellite Communications, took a year off after a few years in the sandbox. I then switched to IT. Pivoted from Sysadmin to SRE/DevOps five years later.

Five more years after that and I make 10x what I did 10 years ago and am working towards FIRE. My family lives on <30% of my income, the rest goes to savings and investments. We should reach our FIRE number before I turn 50.

I love the work I do (DevOps with a Security focus), and that year off I took I was miserable. I'll probably never really retire, just be to the point where I can do the work I need to in under four hours per day and travel.

[MichaelMug]

There are a lot of varying definitions of DevOps? Care to elaborate?

Also any tips on how to 10x? I'm happily employed but I would be open to moving. I've sent quite a few resumes out but no offers that are outside of what I already make.

[InvaderFizz]

My DevOps world revolves around IaC to support developers and their products. Pipelines, terraform module development and upkeep, security reviews, threat mitigation and static code scanning, keeping all the infrastructure up to date and everything within current and supported software versions. Most of what I do code wise is terraform and python. Operationally, I'm the guy that comes in to RCA all the weird edge cases. That is the most fun part of the job for me, constant dopamine hits in solving issue that have been plaguing others for weeks.

The easiest way to 10x is to work 80 hours per week, but make sure you get paid for 80 hours per week, not just 40. I'm a workaholic, so I've been doing that for years on end.

I work multiple C2C contracts and make sure that the work that I do overlaps heavily between clients. I only take on clients that are all in on terraform and lean heavily on AWS managed services. With those two keystones in place, the value I can provide clients is far in excess of what they normally would get because I get to see it all. I run into an issue at Client A, and I put things in place at Client B to mitigate that issue before it even occurs. The DR solution I design for Client B is mostly copy/paste for Client C with minor adjustments and all the lessons from having just completed a DR failover test for Client A.