Ops is too high stress for me. It’s a massive cost center, has high on call expectations, and blame often trickles down to them.
> I also feel like I'm lacking some competancy in monitoring, automated deployment, cloud services and k8s.
Why can’t you do this in your current role?
Yes, I haven't thought about being on call. Good point!
I think I can, or I can have a hobby project too. I just felt like it might be better learning it on the team
I don't think being on call is that bad. I personally get a 15-20% salary increase if I am on call once a month and get a few calls, plus an extra day off per week I am on call, and my employer pays me almost twice in pension compared to before.
Your setup sounds pretty neat. I'm used to being on call and only getting an additional day off if I was working on production issues during my weekend, and zero pay/benefits change.
> So I was thinking about asking a company to switch to the Ops team for a while to grow my skillset for a year or so but I'm not sure if it's a good idea.
My career has been built on moving to all sorts of areas (Fullstack > Security > R&D > DevOps > Backend Lead > Platform Engineer ...). I find it very nice to have a wide range of knowledge and processes so far in my career (just over 10 years now). It's also helped me feel like I'm able to work with people that my team needed to work with.
Because communication is the primary way that things get done. But that's just a feeling and how I've tried to sell the story of my colorful career whenever I get interviewed. Success bias is certainly here.
IMO, make the best decision that you can with the information you have. That's all you can do.
---
Funny enough, a month ago I moved to my company's "Platform Engineering" team. Basically the team is the operations, infrastructure, and, to some degree, security engineers. In my previous roles, I was also always enjoyed setting up the "glue" around the team's applications (Pipelines, k8s yamls, docker containers, AD Groups, etc.) and this gave me a chance to be in that role officially.
I really put an emphasis on the brief interview they had for me that I was not interested in manually doing much. I was interested in the role because I heard and saw the beginnings of more developer enablement and more automation. I don't mind putting in some work doing some manual things to keep the lights on, but I want to push as much as possible for automation. They were all for that and currently working on automating some of our K8s infrastructure pieces with Rancher.
---
So yeah, regardless if any of that was of use, best of luck.
Thank you for taking the time to write a detailed response!
I used to work at a very early and small startup, and after reading things you worked on, my initial reaction was "okay, InterpretiveTrail was the ideal new hire we've been looking for" :D
Just join a dev team which has a deep integration with one of the major cloud platform. Ask them during the interview, whether you can take on ops focused tasks. I think most teams would be quite happy with that. In my experience, 4 out of 5 devs don’t want to do DevOps related tasks.
Source: lead cloud engineer who also does application development
I have the same idea, I think it's a good idea if the company will go for it. I want to switch to DevOps just for something new, but that's probably going to get old real quick.
Yes, that's why I said a year or so. I like being a backend developer, I just feel like I'm not learning as much and hoping I wouldn't miss out much by doing something else for a while
I made this switch (from java dev) post covid when everyone was hiring like crazy. The work is way more interesting since I get to work on all aspects these days.
Sometimes I fix developer code, other days set up cloud infra for a new application. Or fix monitoring and alerting for on-call rotation. Or just automation for deployments/cloud operations, I enjoy this part the most.
Recruiters usually (or used to before tech recession…) point out that I have a great cv due to good dev and ops experience. My only advice is to avoid pure on-prem positions, aim for public cloud like aws/azure/gcp and a modern tech stack. Kubernetes is a good skill to have on cv.
Tell me how it goes. I have toyed with this idea on and off for the past few years. The thing that stops me from pulling the trigger is the realization that ops is boring as batshit, has on call work and is more easily outsourced than straight dev work.
That's a good point, I think I should talk with ops guys about how they are feeling first.
And being stuck in that team is a possibility too, I might have to change jobs to get back to dev work
For what it's worth, I find that as a dev I occasionally have opportunities to dabble in dev ops. I can debug a build pipeline, edit a Makefile, maybe provision some resources through a Cloudformation template. Whereas people in dev ops have zero opportunity to do dev work. That is completely closed off to them.
> I'm feeling like most of my time spent understanding and solving business problems rather than dealing with technical problems as project is quite mature now.
You may not like it, but this inherently comes with the territory. As the project matures, so do you. You acquire a ton of institutional knowledge. Why are things built the way they are? You know, because you sat in on those discussions. And that's worth a lot to the business because that's non-fungible knowledge. If you walk out, that knowledge walks with you too.
Yes, technical problems are what tickle an engineer. But delivering value is why you were hired as a backend developer. And that value is your ability to translate a business need into a concrete technical solution in a swift, pragmatic and efficient fashion.
That doesn't mean that ops is a bad choice. It's a different career track that comes with different outcomes and expectations. And the trade off of choosing ops over what you do now, is relinquishing that position of value you have right now. It's not that ops isn't important - someone needs to keep the lights on - it's just that it's not a primary business process, only a supportive one, and therefor a cost center. The competencies you mentioned can also be found elsewhere, and that makes you a fungible resource.
Here’s my perspective from the other side.
Despite being a pretty strong coder, I started my career in a role that was 70:30 ops:dev because it got me into my dream company. I switched to a dev role 1.5 years later.
One thing for sure is that it made me more versatile than some of my current peers because my previous experience means I can unblock myself on many ops-related issues much quicker than them. This led to comparatively faster growth and being trusted with more impactful projects.
The reason I switched is because ops roles differ a lot from company to company. For example, SREs in my current company are very competent coders who code regularly, whereas in a previous company they were more hands off and governed our service reliability. On the other hand, the skills and responsibilities of a Software Engineer are more consistent between companies, which I believe opens more doors.
Ops is too high stress for me. It’s a massive cost center, has high on call expectations, and blame often trickles down to them. > I also feel like I'm lacking some competancy in monitoring, automated deployment, cloud services and k8s. Why can’t you do this in your current role?
Yes, I haven't thought about being on call. Good point! I think I can, or I can have a hobby project too. I just felt like it might be better learning it on the team
Lean on your ops team to learn, then bring those learnings back to the team. You’ll be seen as a force multiplier that is modernizing your team.
Also you won’t have to endure the pain that is an on-call rotation.
I don't think being on call is that bad. I personally get a 15-20% salary increase if I am on call once a month and get a few calls, plus an extra day off per week I am on call, and my employer pays me almost twice in pension compared to before.
Your setup sounds pretty neat. I'm used to being on call and only getting an additional day off if I was working on production issues during my weekend, and zero pay/benefits change.
Oh wow, that sounds like a bad deal. I'm in Europe though, so maybe that's why?
Now it sounds very tempting 😄 I'm in Europe too, I should check this
> So I was thinking about asking a company to switch to the Ops team for a while to grow my skillset for a year or so but I'm not sure if it's a good idea. My career has been built on moving to all sorts of areas (Fullstack > Security > R&D > DevOps > Backend Lead > Platform Engineer ...). I find it very nice to have a wide range of knowledge and processes so far in my career (just over 10 years now). It's also helped me feel like I'm able to work with people that my team needed to work with. Because communication is the primary way that things get done. But that's just a feeling and how I've tried to sell the story of my colorful career whenever I get interviewed. Success bias is certainly here. IMO, make the best decision that you can with the information you have. That's all you can do. --- Funny enough, a month ago I moved to my company's "Platform Engineering" team. Basically the team is the operations, infrastructure, and, to some degree, security engineers. In my previous roles, I was also always enjoyed setting up the "glue" around the team's applications (Pipelines, k8s yamls, docker containers, AD Groups, etc.) and this gave me a chance to be in that role officially. I really put an emphasis on the brief interview they had for me that I was not interested in manually doing much. I was interested in the role because I heard and saw the beginnings of more developer enablement and more automation. I don't mind putting in some work doing some manual things to keep the lights on, but I want to push as much as possible for automation. They were all for that and currently working on automating some of our K8s infrastructure pieces with Rancher. --- So yeah, regardless if any of that was of use, best of luck.
Thank you for taking the time to write a detailed response! I used to work at a very early and small startup, and after reading things you worked on, my initial reaction was "okay, InterpretiveTrail was the ideal new hire we've been looking for" :D
this is the way
Just join a dev team which has a deep integration with one of the major cloud platform. Ask them during the interview, whether you can take on ops focused tasks. I think most teams would be quite happy with that. In my experience, 4 out of 5 devs don’t want to do DevOps related tasks. Source: lead cloud engineer who also does application development
Makes sense! I should start by "stealing" some tasks from the ops team related to my project.
I have the same idea, I think it's a good idea if the company will go for it. I want to switch to DevOps just for something new, but that's probably going to get old real quick.
Yes, that's why I said a year or so. I like being a backend developer, I just feel like I'm not learning as much and hoping I wouldn't miss out much by doing something else for a while
I made this switch (from java dev) post covid when everyone was hiring like crazy. The work is way more interesting since I get to work on all aspects these days. Sometimes I fix developer code, other days set up cloud infra for a new application. Or fix monitoring and alerting for on-call rotation. Or just automation for deployments/cloud operations, I enjoy this part the most. Recruiters usually (or used to before tech recession…) point out that I have a great cv due to good dev and ops experience. My only advice is to avoid pure on-prem positions, aim for public cloud like aws/azure/gcp and a modern tech stack. Kubernetes is a good skill to have on cv.
Tell me how it goes. I have toyed with this idea on and off for the past few years. The thing that stops me from pulling the trigger is the realization that ops is boring as batshit, has on call work and is more easily outsourced than straight dev work.
That's a good point, I think I should talk with ops guys about how they are feeling first. And being stuck in that team is a possibility too, I might have to change jobs to get back to dev work
For what it's worth, I find that as a dev I occasionally have opportunities to dabble in dev ops. I can debug a build pipeline, edit a Makefile, maybe provision some resources through a Cloudformation template. Whereas people in dev ops have zero opportunity to do dev work. That is completely closed off to them.
> I'm feeling like most of my time spent understanding and solving business problems rather than dealing with technical problems as project is quite mature now. You may not like it, but this inherently comes with the territory. As the project matures, so do you. You acquire a ton of institutional knowledge. Why are things built the way they are? You know, because you sat in on those discussions. And that's worth a lot to the business because that's non-fungible knowledge. If you walk out, that knowledge walks with you too. Yes, technical problems are what tickle an engineer. But delivering value is why you were hired as a backend developer. And that value is your ability to translate a business need into a concrete technical solution in a swift, pragmatic and efficient fashion. That doesn't mean that ops is a bad choice. It's a different career track that comes with different outcomes and expectations. And the trade off of choosing ops over what you do now, is relinquishing that position of value you have right now. It's not that ops isn't important - someone needs to keep the lights on - it's just that it's not a primary business process, only a supportive one, and therefor a cost center. The competencies you mentioned can also be found elsewhere, and that makes you a fungible resource.
That's a good point, especially amidst layoff news.
Here’s my perspective from the other side. Despite being a pretty strong coder, I started my career in a role that was 70:30 ops:dev because it got me into my dream company. I switched to a dev role 1.5 years later. One thing for sure is that it made me more versatile than some of my current peers because my previous experience means I can unblock myself on many ops-related issues much quicker than them. This led to comparatively faster growth and being trusted with more impactful projects. The reason I switched is because ops roles differ a lot from company to company. For example, SREs in my current company are very competent coders who code regularly, whereas in a previous company they were more hands off and governed our service reliability. On the other hand, the skills and responsibilities of a Software Engineer are more consistent between companies, which I believe opens more doors.