Oh hey, it's something actually relevant to my interests. Seasoned DevOps Profeshnal hat goes on...nnnnow. > I came to the realization recently that I haven't

Oh hey, it's something actually relevant to my interests. Seasoned DevOps Profeshnal hat goes on...nnnnow. > I came to the realization recently that I haven't really felt like I'm working towards mastery of any skills and it's making me depressed. "DevOps engineers" get the short end of the stick on the wide-vs-deep thing because "DevOps", at present, is constantly changing. And by "changing," I mostly mean "thrashing," though we have found a decent local maximum with some of the container stuff that's out there that I think will last, even on the leading edge, for at least a few years. Which is to say, this is endemic. Best way out, IMO, is to have other professional outlets. I write a lot of not-DevOps code, both at my current gig and on the side, because DevOps requires the Dev side as well as the Ops side to be worth a fart. > and helping people with infrastructure issues (aka being distracted). ... I rarely get the feeling that I'm in any sort of good work "flow", Interruptive time/distractions are a universal problem. They're never going to go away. What you can and should do (and this requires a manager who Gets It, so, y'know, YMMV) is set up office hours for those interruptions. "I am available between X and Y on days A, B, and C to help with your DevOps problems." Obviously this doesn't apply to stuff like production outages, but it does apply to stuff like "how should we best accomplish this task?" or "I need this thing run against the dev environment." Bonus points, for the last one above, if you can use those requests to build data to present a business case upward. If you get a lot of requests to do one or two related things, you can use that data to push your boss to find time for you automate it (or to find developer help for it, whatever). > rather that I'm just cleaning up and making incremental dents in backlogs of tech debt. There are two kinds of DevOps engineering, in my experience: the first one and the second one. No, that's not right--janitorial and architectural. You (and I'm cheating a bit, 'cause I know who is really beneath that tremendous hat) are stuck with a lot of the janitorial stuff because, I think, you tend to come into established shops that have a Way Of Doing Things and, incidentally, don't offer a lot of ways to move upward. The architectural roles at companies like that tend to already be filled (and DevOps, while not hierarchical, does seem to tend to concentrate a lot of the architectural decision-making to people like...well...me). Smaller companies might benefit you, in that you get to take a big swing or two at the full stack of problems. > I'm not sure if I'm not being assertive enough with my needs and ideas You're not, but most people aren't. Big personalities (hi) tend to fill the space. You don't have to be a jerk, but you do have to kinda push to get what you want to be yours. Oh, and get out of owning CI/CD. Make developers own that stuff. You'll be happier. They won't be, until they actually learn what they're doing, but, y'know. It's good for them. ;)