4 ms·

It doesn't help that, at least in my experience, a lot of "pure" software developers absolutely want nothing to do with the ops side, preferring to work on new

It doesn't help that, at least in my experience, a lot of "pure" software developers absolutely want nothing to do with the ops side, preferring to work on new features and just code, and vice versa.

trog 4y ago
> It doesn't help that, at least in my experience, a lot of "pure" software developers absolutely want nothing to do with the ops side, preferring to work on new features and just code, and vice versa. I have almost the exact opposite problem with some of my team, where they want to spend a lot more time on the Operational side. This is a mixed blessing - they'll learn the depths of various AWS things that are painfully boring to me - but I'd rather they were writing code instead of mucking around looking for some magic AWS solution to solve some specific use case.
- macintux 4y ago
  > but I'd rather they were writing code instead of mucking around looking for some magic AWS solution to solve some specific use case. Really? To my mind, code is a last resort from a business perspective: I’d much rather developers use AWS features when available.
  - iasay 4y ago
    There’s a happy medium somewhere.
  - pojzon 4y ago
    > from a business perspective This is true that from business perspective if there was a way to completely cut off engineers and replace them with low-code / saas offerings -> we all would be out of the job next week. Fortunately for us engineering is quite complicated.
clouded 4y ago
I happily also work on bugs, not just new features. The thing is, bugs and features completely fries my brain. Especially if you want it done right and not introduce bugs somewhere else. Forget devops for a second, what I'm saying is that what I described is _already_ enough to fry me. I'm done. You're getting nothing else out of me. When you hire an electrician to wire your house, ask him to also do the plumbing while he's at it. He should really "own" the entire house stack. Let's see how he takes it.
Sebb767 4y ago
A DevOps position is partially sales role. Telling devs that their well-known and understood scp workflow is bad and instead the should use this tool they don't know to look at logs and this completely different tool to deploy the app is bound to fail. If you want to change the way developers work, you need to show them why the new way is better and make the switch as painless as possible. And if you can't do this, you should think hard about why you want them to make that change.
- hedora 4y ago
  Telling developers to [do the ops team's job, the way the ops team would, assuming the ops people were actually doing their jobs and not just swamping the dev with weird high priority but boring bugs] is an extremely hard sell. I greatly prefer it when the ops team tracks the time they spend on incidents, then stack ranks the ways in which my software sucks (in terms of hours of their time wasted), then asks me to fix it. The same thing goes for $/perf discussions. I don't care if they want to SCP or ftp or send my code over a QUIC tunnel through a bastion host on the moon. If developers have to know there is a new or old way of doing that, then the CI/CD team has failed. If you want me (the dev) to fix CI/CD, then I'll happily reimplement it with make and a fault tolerant NFS share. I'll even explain why that has been the best available approach since ~1985.
marssaxman 4y ago
I actually prefer to "just code" by cleaning up old messes than by working on new features, but regardless - I absolutely want nothing to do with the ops side, and I will quit on the spot if anyone tries to hand me a pager. It's a different skill set; it's not what I do, nor want to do.
- convolvatron 4y ago
  seems like that shouldn't be that hard to understand....but someone is always standing behind you trying to sneak a pager into your bag.

It doesn't help that, at least in my experience, a lot of "pure" software developers absolutely want nothing to do with the ops side, preferring to work on new features and just code, and vice versa.

trog 4y ago

> It doesn't help that, at least in my experience, a lot of "pure" software developers absolutely want nothing to do with the ops side, preferring to work on new features and just code, and vice versa. I have almost the exact opposite problem with some of my team, where they want to spend a lot more time on the Operational side. This is a mixed blessing - they'll learn the depths of various AWS things that are painfully boring to me - but I'd rather they were writing code instead of mucking around looking for some magic AWS solution to solve some specific use case.

macintux 4y ago
> but I'd rather they were writing code instead of mucking around looking for some magic AWS solution to solve some specific use case. Really? To my mind, code is a last resort from a business perspective: I’d much rather developers use AWS features when available.
- iasay 4y ago
  There’s a happy medium somewhere.
- pojzon 4y ago
  > from a business perspective This is true that from business perspective if there was a way to completely cut off engineers and replace them with low-code / saas offerings -> we all would be out of the job next week. Fortunately for us engineering is quite complicated.

clouded 4y ago

I happily also work on bugs, not just new features. The thing is, bugs and features completely fries my brain. Especially if you want it done right and not introduce bugs somewhere else. Forget devops for a second, what I'm saying is that what I described is _already_ enough to fry me. I'm done. You're getting nothing else out of me. When you hire an electrician to wire your house, ask him to also do the plumbing while he's at it. He should really "own" the entire house stack. Let's see how he takes it.

Sebb767 4y ago

A DevOps position is partially sales role. Telling devs that their well-known and understood scp workflow is bad and instead the should use this tool they don't know to look at logs and this completely different tool to deploy the app is bound to fail. If you want to change the way developers work, you need to show them why the new way is better and make the switch as painless as possible. And if you can't do this, you should think hard about why you want them to make that change.

hedora 4y ago
Telling developers to [do the ops team's job, the way the ops team would, assuming the ops people were actually doing their jobs and not just swamping the dev with weird high priority but boring bugs] is an extremely hard sell. I greatly prefer it when the ops team tracks the time they spend on incidents, then stack ranks the ways in which my software sucks (in terms of hours of their time wasted), then asks me to fix it. The same thing goes for $/perf discussions. I don't care if they want to SCP or ftp or send my code over a QUIC tunnel through a bastion host on the moon. If developers have to know there is a new or old way of doing that, then the CI/CD team has failed. If you want me (the dev) to fix CI/CD, then I'll happily reimplement it with make and a fault tolerant NFS share. I'll even explain why that has been the best available approach since ~1985.

marssaxman 4y ago

I actually prefer to "just code" by cleaning up old messes than by working on new features, but regardless - I absolutely want nothing to do with the ops side, and I will quit on the spot if anyone tries to hand me a pager. It's a different skill set; it's not what I do, nor want to do.

convolvatron 4y ago
seems like that shouldn't be that hard to understand....but someone is always standing behind you trying to sneak a pager into your bag.