3 ms·

Oh man, that's the trap. I do like to learn new things, I swear. But at work I want to focus on what I do best: feature development. Sure, I do know terraform a

Oh man, that's the trap. I do like to learn new things, I swear. But at work I want to focus on what I do best: feature development. Sure, I do know terraform and k8s and what not (because I play with them via my side projects), but at work don't give me the Ops/Platform hat please! It's cheap labor (your company doesn't want to hire a dedicated platform engineer to handle terraform/k8s/etc. and instead assigns you (the developer) that responsibility claiming "you are gonna have fun learning" and paying you 25% more in the best scenario)

MetaWhirledPeas 4y ago
I don't know if you're right or not, but I do think your hesitancy mirrors why a lot of organizations are unable to adopt DevOps fully: many people don't want to wear a bunch of hats. They just want to do their one thing, and I can't really blame them.
- tremon 4y ago
  But I don't think the original DevOps (TM) specified that every person was required to work on every part of the stack? Just that you need to have full-stack skills and responsibilities within the same team? That said, I probably wouldn't want to hire someone with just one hat. It's ok to have a preferential hat, it's not ok to refuse to wear any other.
  - BlargMcLarg 4y ago
    This sounds like a manager's ideal. It's a luxury to demand people wear multiple hats up to the point the market allows you to turn the luxury into a commonality. If it was up to bosses, they'd rather have jokers ready to switch from customer support, to development, to sales, and back. It's ok until the market decide it is no longer ok. So far, it looks like all these "hats" are complicated enough for the average to make the market think twice about demanding that combination of breadth and depth of skills.
  - 0x457 4y ago
    > But I don't think the original DevOps (TM) specified that every person was required to work on every part of the stack? Just that you need to have full-stack skills and responsibilities within the same team? Then you have Ops person integrated in every dev team/squad, then those Ops people have their own meetings to talk about Ops things. Then there aren't enough Ops people to staff every dev team (maybe they are on vacation, perhaps just not enough in general), so they start sharing them. Next they need to work on some special Ops tasks, so they want to have their own board. Oops, now you have Ops team. The point of DevOps is that the team is responsible for code being shipped, and after they shipped it, so everyone needs to know how to work in the stack that runs your app (Kubernetes, Nomad, AWS Beanstalk, bare-metal with Ansible or whatever it is you use). That means devs don't go to some other team to fix their CI or CD pipeline. I worked in a company that was doing DevOps, we had no Ops team, we had a few people who only worked on infra, but they were part of our team. We didn't call it anything, it was just how to work, about 3/4 of the team was capable of setting up infrastructure and working on Jenkins. I also worked in the company that "did DevOps" had a "DevOps team" and devs knew absolutely nothing about what happens to their code after they did `git push` (that if they knew how to do `git push` without asking "DevOps team"). Another company "for sure did DevOps right", they didn't have "DevOps team" instead they had "Infra team" and infra team was responsible for bare metal provisioning. Devs could write CI pipelines and stuff. However, devs had zero responsibility for code after they shipped it - it was infra team that would be woken up by nightly Pager Duty alert.
spaetzleesser 4y ago
Same here. I recently had to take on some more roles. It’s fun learning but I don’t perform at the level I could perform when I was mainly writing C# code. Its not even close. It’s good to have some insights into all aspects of the work but somebody who can focus on one area but can perform there with multiple productive of someone who constantly jumps around.
62951413 4y ago
I'm with you with a minor adjustment. I'd call it not "feature development" but software development and programming languages. Two majors points: * as a developer my free time should be spent on keeping up with my ecosystem (e.g. new JDK versions, Scala/Kotlin taking over Java, Akka-like modern libraries, the latest Flink features) and keeping an eye on possible alternatives (e.g. are golang generics good enough to make it competitive with Java?). * once they standardize on a single DSL sign me up. I don't want to constantly waste my time on switching to CloudFormation, then to Terraform, then to Helm charts. Sometimes even moving to a different team in the same company requires it. Life is too short to be a full time YAML developer. Also, AWS CDK is the only option that at least resembles programming and it's apparently the least popular one.

MetaWhirledPeas 4y ago

I don't know if you're right or not, but I do think your hesitancy mirrors why a lot of organizations are unable to adopt DevOps fully: many people don't want to wear a bunch of hats. They just want to do their one thing, and I can't really blame them.

tremon 4y ago
But I don't think the original DevOps (TM) specified that every person was required to work on every part of the stack? Just that you need to have full-stack skills and responsibilities within the same team? That said, I probably wouldn't want to hire someone with just one hat. It's ok to have a preferential hat, it's not ok to refuse to wear any other.
- BlargMcLarg 4y ago
  This sounds like a manager's ideal. It's a luxury to demand people wear multiple hats up to the point the market allows you to turn the luxury into a commonality. If it was up to bosses, they'd rather have jokers ready to switch from customer support, to development, to sales, and back. It's ok until the market decide it is no longer ok. So far, it looks like all these "hats" are complicated enough for the average to make the market think twice about demanding that combination of breadth and depth of skills.
- 0x457 4y ago
  > But I don't think the original DevOps (TM) specified that every person was required to work on every part of the stack? Just that you need to have full-stack skills and responsibilities within the same team? Then you have Ops person integrated in every dev team/squad, then those Ops people have their own meetings to talk about Ops things. Then there aren't enough Ops people to staff every dev team (maybe they are on vacation, perhaps just not enough in general), so they start sharing them. Next they need to work on some special Ops tasks, so they want to have their own board. Oops, now you have Ops team. The point of DevOps is that the team is responsible for code being shipped, and after they shipped it, so everyone needs to know how to work in the stack that runs your app (Kubernetes, Nomad, AWS Beanstalk, bare-metal with Ansible or whatever it is you use). That means devs don't go to some other team to fix their CI or CD pipeline. I worked in a company that was doing DevOps, we had no Ops team, we had a few people who only worked on infra, but they were part of our team. We didn't call it anything, it was just how to work, about 3/4 of the team was capable of setting up infrastructure and working on Jenkins. I also worked in the company that "did DevOps" had a "DevOps team" and devs knew absolutely nothing about what happens to their code after they did `git push` (that if they knew how to do `git push` without asking "DevOps team"). Another company "for sure did DevOps right", they didn't have "DevOps team" instead they had "Infra team" and infra team was responsible for bare metal provisioning. Devs could write CI pipelines and stuff. However, devs had zero responsibility for code after they shipped it - it was infra team that would be woken up by nightly Pager Duty alert.

spaetzleesser 4y ago

Same here. I recently had to take on some more roles. It’s fun learning but I don’t perform at the level I could perform when I was mainly writing C# code. Its not even close. It’s good to have some insights into all aspects of the work but somebody who can focus on one area but can perform there with multiple productive of someone who constantly jumps around.

62951413 4y ago

I'm with you with a minor adjustment. I'd call it not "feature development" but software development and programming languages. Two majors points: * as a developer my free time should be spent on keeping up with my ecosystem (e.g. new JDK versions, Scala/Kotlin taking over Java, Akka-like modern libraries, the latest Flink features) and keeping an eye on possible alternatives (e.g. are golang generics good enough to make it competitive with Java?). * once they standardize on a single DSL sign me up. I don't want to constantly waste my time on switching to CloudFormation, then to Terraform, then to Helm charts. Sometimes even moving to a different team in the same company requires it. Life is too short to be a full time YAML developer. Also, AWS CDK is the only option that at least resembles programming and it's apparently the least popular one.