3 ms·

I get some people use the term that way, but in our case, our guy really did spend ~50-60% of his time developing IaC and other deployment scripts/tools (in var

I get some people use the term that way, but in our case, our guy really did spend ~50-60% of his time developing IaC and other deployment scripts/tools (in various languages), and the rest handling the operational side of things. He occasionally touched the application code as needed (renaming configuration variables etc.), but he didn't do feature-level development, nor was he interested in doing so.

ketzo 4y ago
This was also my experience. I used to work in an org with about 200 engineers, supported by a DevOps team of ~6 devops engineers. They spent (very roughly) half of their time doing operations, and half of their time writing software to make devops easier. Every other month they’d announce some new tool for us to run automated tests or speed up builds. It was awesome, and made our developers more likely to do their own portion of the ops work.
- techsupporter 4y ago
  > They spent (very roughly) half of their time doing operations, and half of their time writing software to make devops easier. This is what happens in my (non-tech-industry, but heavily invested in tech stacks) employer. A previous manager decided we were no longer System Administrators but now DevOps Engineers. But none of us develops code for our features and none of us wants to develop code for features. We want to build and maintain the infrastructure on which the code runs. Some of it has to be run in-house because we deal with medical information and all that entails. Our current manager describes not as Developer Operations but Developing Operations. We develop the infrastructure and tooling that our code writers need and do everything we can to get the moving parts out of their way. If the code written by the code writers fails, it is their responsibility to deal with it but if the infrastructure underpinning that code fails, my team has failed.
dilyevsky 4y ago
Ime this unravels quickly as the team and stack complexity grows and product engineering starts shipping software that’s very difficult/expensive to operate. The whole idea behind devops was to avoid this death spiral by giving engineers ownership and responsibility to run their own software. The problem was (still is) that off-the-shelf tooling is just not there and requires very skilled/experience devs to use it effectively. Hence dedicated teams got created and the whole thing died on the vine. Devops as a movement simply doesn’t scale.
- wizofaus 4y ago
  I don't see it as massively different to specialisation between front and back-end developers though - we're all devs, we're all comfortable with reading/writing code, but whereas my specialty and focus is on application-level (typically backend) code, the DevOps guys are specialised in writing IaC scripts etc. Yes, in principle, any dev could do it all, but there becomes a point that the mental load from juggling too many technologies outweighs your ability to be productive. And some types of development just take different mindsets - I've done my share of front-end/UI-type development in the past, and can easily pick it up again if needed, but I can't say I find it super satisfying, and it's nearly always going to be produce a better result for everyone to hand it off to someone who does. Likewise for CI/CD scripting. And it also happens that if your primary focus is on the scripts and tools necessary to get software deployed to a particular hosting environment, you're likely to have the skills necessary to take care of the day-to-day sysadmin side of things for that environment (indeed, most "manual" changes to the environment are only done as a last resort, and would be wiped by the next deployment anyway, unless the scripts are modified appropriately too).

ketzo 4y ago

This was also my experience. I used to work in an org with about 200 engineers, supported by a DevOps team of ~6 devops engineers. They spent (very roughly) half of their time doing operations, and half of their time writing software to make devops easier. Every other month they’d announce some new tool for us to run automated tests or speed up builds. It was awesome, and made our developers more likely to do their own portion of the ops work.

techsupporter 4y ago
> They spent (very roughly) half of their time doing operations, and half of their time writing software to make devops easier. This is what happens in my (non-tech-industry, but heavily invested in tech stacks) employer. A previous manager decided we were no longer System Administrators but now DevOps Engineers. But none of us develops code for our features and none of us wants to develop code for features. We want to build and maintain the infrastructure on which the code runs. Some of it has to be run in-house because we deal with medical information and all that entails. Our current manager describes not as Developer Operations but Developing Operations. We develop the infrastructure and tooling that our code writers need and do everything we can to get the moving parts out of their way. If the code written by the code writers fails, it is their responsibility to deal with it but if the infrastructure underpinning that code fails, my team has failed.

dilyevsky 4y ago

Ime this unravels quickly as the team and stack complexity grows and product engineering starts shipping software that’s very difficult/expensive to operate. The whole idea behind devops was to avoid this death spiral by giving engineers ownership and responsibility to run their own software. The problem was (still is) that off-the-shelf tooling is just not there and requires very skilled/experience devs to use it effectively. Hence dedicated teams got created and the whole thing died on the vine. Devops as a movement simply doesn’t scale.

wizofaus 4y ago
I don't see it as massively different to specialisation between front and back-end developers though - we're all devs, we're all comfortable with reading/writing code, but whereas my specialty and focus is on application-level (typically backend) code, the DevOps guys are specialised in writing IaC scripts etc. Yes, in principle, any dev could do it all, but there becomes a point that the mental load from juggling too many technologies outweighs your ability to be productive. And some types of development just take different mindsets - I've done my share of front-end/UI-type development in the past, and can easily pick it up again if needed, but I can't say I find it super satisfying, and it's nearly always going to be produce a better result for everyone to hand it off to someone who does. Likewise for CI/CD scripting. And it also happens that if your primary focus is on the scripts and tools necessary to get software deployed to a particular hosting environment, you're likely to have the skills necessary to take care of the day-to-day sysadmin side of things for that environment (indeed, most "manual" changes to the environment are only done as a last resort, and would be wiped by the next deployment anyway, unless the scripts are modified appropriately too).