[starttoaster]

It usually doesn't work that way, in my experience. My title is "Senior DevOps Engineer" and I do my fair share of writing code as well as maintaining infra. But honestly, hiring for people who do what I do seems to be very hit and miss. Most people excel at one or the other, and so they only pick up tickets that fit their skillset. They might dive into a ticket outside their comfort zone here or there, but not commonly. It would seem to me that many DevOps engineering teams are just one team who has a manager that hired and manages some Devs and some Ops folk, and just wrangles each of them into doing tasks that fit the goal of the team and their individual talents. And from an outsider's perspective it would seem like one team of jacks of all trades, but internally it's very much known who is going to take on certain kinds of tasks and the siloes are all very much in place.

[diarrhea]

That situation sounds reasonable though. I don’t believe in tearing down all silos. Expertise and preferences exist, it’s human nature. I always thought the DevOps mantra of having one person be good at both was a fruitless endeavour. Have Dev and Ops collaborate closely, yes, but let them be separate people (not teams!). It’s fine. You know how to dev and ops, and I don’t doubt it. I do too. But if we focused that same energy and expertise, we’d be double the devs/ops. Nevertheless, people like us are excellent glue for organisations. At the same time, teams and organisations of only us would be quite pointless.

I feel similarly about fullstack. You’re a front end dev that has written a controller and used an ORM before. Often not too inspiring. Backend devs are still needed, whereas full stack devs form excellent glue.

[starttoaster]

You’re right. And it wasn’t my intent to editorialize (to imply I feel one way or the other about the subject.) But I can read how an opinion could be inferred. Anyway, my actual opinion is that people like us tend to be more useful than not, but also it definitely takes people with more specialized knowledge to make progress with some organization goals. For example, at my current role we have a team of people with a much deeper background in mathematics (we’re in the financial sector), algorithms, and computer science in general. Due to a life event, I dropped out of my computer science degree towards the end of my second year, and ended up pulling myself through operations roles (which I typically found comparatively boring) until I landed in DevOps after a lot of open source work and networking. But I am not as strong as some of my peers in mathematics, algorithms, and computer science topics (what is a big/little endian lol?)

Anyway, cheers. In short, I agree with your take.

[jahewson]

> Have Dev and Ops collaborate closely

That’s what DevOps is… or, was. I remember when it was new; that was the whole thing: dev and ops should work together. A break from the norm of the time that dev throws it over the wall to ops and never thinks about it again. What a tragedy that it’s been cargo-culted into its current meaning of “devs do ops” (poorly).

[_jal]

I came in to my current gig as the first devops hire. We were a lot smaller then. 8 years on, I'm managing an infrastructure team alongside ops and devops teams. We also draw lines a little differently; infrastructure manages core services like auth, logging, instrumentation, etc.

In my experience, devops folks usually come from the dev side, not the ops side, and their experience and curiosity reflects that. So we let them focus on shipping line-of-business code while making sure what they ship runs in a competently managed environment, as well as handling data centers and all the more traditional infra stuff.

[dionian]

my experience hasnt always been this, but generally speaking, this is the way to be successful - you need developer-oriented people doing the work. in some ways its harder than coding, coding has more structure than devops automation