6 ms·

I don't know how prevalent my opinion is amongst developers, but the reason I will never take another job with a support aspect is not because of some detailed

I don't know how prevalent my opinion is amongst developers, but the reason I will never take another job with a support aspect is not because of some detailed assessment of the software lifecycle. It's because I don't like it. And I can't think of anything more annoying than being on-call for work outside regular work hours. So I think it's awesome that some people want to do this work. I hope they do it full-time, and that lets me do my thing full-time. Obviously many developers like the mixed model or accept it. I'm curious about whether I'm an outlier or lots of others feel the same?

potamic 5y ago
Does having a separate on-call really shield the devs from support? I assume in most cases on-call would need to escalate or reach out to the devs for issues and for that someone needs to be reachable on phone off hours?
- jacksonkmarley 5y ago
  I mean I guess it's pretty dependent on the company and product, I just know if I see "on-call" or "support" in a job ad, I pass. Perhaps I'm just screening myself out of certain business areas. My experience was support during business hours as part of my job as a software engineer. I used to hate hearing the phone ring, and it was rarely if ever a problem directly related to what I was developing. I felt like it was just a huge disruption to my work.
leokennis 5y ago
I understand your attitude, and sort of agree with it. If I take a job with on call duty, it also means I will be woken up at night because of "your" mistakes (in code, testing etc.) and that is fine. But a very important aspect for me is that, if that happens, the developers give the correct priority to fixing the bug that woke me up at night. So, it's fine you only want to work during the day. But if I get woken up at night or in the weekend, you better start fixing the bug that caused it as soon as it's day again.
- jacksonkmarley 5y ago
  I mean sure, it's not like I want to refuse all responsibility. And I'm all for paying the person who does the on-call in line with doing what I consider a tough duty BTW. I guess my point is more that maybe that separation of roles actually also reflects the differences in personality and how different people work.
quicklime 5y ago
You're not an outlier, many people (myself included) feel the same way. > So I think it's awesome that some people want to do this work. I hope they do it full-time, and that lets me do my thing full-time. If you're lucky and your company lets you pick whether you want to apply for a SWE role or an SRE role (like Google), then it will work out ok. But a lot of companies just used "DevOps" as an excuse to get rid of their ops teams and dump the work onto the dev teams. Some places take it a step further and get quite toxic, and have a culture where there's a complete lack of sympathy for engineers who have a heavy oncall load. The idea is that their code is shit so they deserve to be woken up in the middle of the night, as some sort of punishment.
- Aeolun 5y ago
  > The idea is that their code is shit so they deserve to be woken up in the middle of the night, as some sort of punishment. I mean, isn’t that the case to some extend? It certainly incentivizes you to do better. I can see a problem when you don’t get the resources to do better though.
blablabla123 5y ago
For me it's similar'ish. My approach is this: I'm a developer but I want to be involved in all deployment related steps and ideally deploy the app from day 1 myself. The latter step is usually underestimated and helps to keep the timeline. On the other hand I learn early on how the app behaves during runtime on a real environment and can take precautions that maintenance on application level is almost only needed when deploying. A dedicated Ops team is nice when it's limited on the application level to very basic tasks like just restarting the service. If the services are not under-provisioned and have a properly set up process/app orchestration in place this is actually a non-task... Under these conditions I don't mind being on-call every now and then or even all the time if done right.
sdevonoes 5y ago
Feel the same. I do not like to be on-call. In the first stages of a job interview I always ask if on-call is required, and if so I politely decline. Edit: I'm talking about being on-call outside of business hours. I have no problem being on-call 9-5.
nijave 5y ago
Now imagine being on call for someone else's code! That's ops. Unless your company has a very strong relationship between ops and devs, the ops side gets stuck supporting whatever the developer side creates and the developer side is incentivized to jam as many features into code as quickly as possible. It's very expensive and customer impactful when you find issues in production versus prevent them in the first place with code that's a little more "runnable" (like testable code, I'm also convinced there's "runnable" or "operable" code)
- sdevonoes 5y ago
  "Move fast and break things" is the mantra of many of the startups out there. If only companies realise that pushing features to production like there is no tomorrow is NOT the way to go.
  - Lutger 5y ago
    That's just the ops side of the fence being talked about here. The other side is having endless gating, change advisory boards, batching up work, gruesome change approval processes etc. that the ops protect themselves with against development, which now grinds to a halt. This will not only make the business slow to a halt, ironically it will also produce more errors. The really productive companies that deliver fast, are also way more robust.
- fatnoah 5y ago
  >Unless your company has a very strong relationship between ops and devs, the ops side gets stuck supporting whatever the developer side creates and the developer side is incentivized to jam as many features into code as quickly as possible. >like testable code, I'm also convinced there's "runnable" or "operable" code 1000% this. For me, this has been a huge focus in my past startup lives. Software and infrastructure are very related. Infra design impacts software design and vice versa. By working closely together, it's possible to try to get the best of both worlds. As a VP Eng, I expended a lot of political capital with my "why aren't you building more features" CEO boss so that my dev team could focus on significantly enhancing the stability and observability of our platform, including ensuring our log messages were informative and at the appropriate level. i.e. CRITICAL = Fix Now, ERROR = someone should check into this at earliest convenience, INFO = here's how things are generally running. Stability saved everyone time and effort, and observability allowed (and empowered) the ops team to efficiently triage, and let Engineers quickly understand what's going on and how to fix it when things went wrong. The net result was multiple nightly on-call alerts for Engineers dwindling to "I can't remember the last one" and ops folks were able to focus far more on infra than triaging software alerts. It was a battle and I had to fight to make it happen, and even have my teams "ninja" a bunch of the work via an 18 month inside-out refactor of the codebase, but the result was 200% worth it. The cherry on top was the two full-day grilling by tech leaders during due-diligence during our acquisition. They dug deep into the operational aspects of the business and came away very impressed, and that operational maturity (this was a company that highly valued such things) was highlighted as one of two key factors that swayed the decision to acquire.
zippergz 5y ago
Yup. In fact, I transitioned out of development in part because of the prevalence of this. I have learned the hard way that my work/life boundary is absolutely critical to my mental health and wellbeing. Even if it's relatively infrequent, any period of being on-call is incredibly stressful to me. I am willing to work some periods of long hours (within reason), but I am not willing to be in a position where I can be called or paged at night or on a weekend. No job is worth that to me. Hats off to the folks who can tolerate it. We need those people! But I am definitely not one of them.

potamic 5y ago

Does having a separate on-call really shield the devs from support? I assume in most cases on-call would need to escalate or reach out to the devs for issues and for that someone needs to be reachable on phone off hours?

jacksonkmarley 5y ago
I mean I guess it's pretty dependent on the company and product, I just know if I see "on-call" or "support" in a job ad, I pass. Perhaps I'm just screening myself out of certain business areas. My experience was support during business hours as part of my job as a software engineer. I used to hate hearing the phone ring, and it was rarely if ever a problem directly related to what I was developing. I felt like it was just a huge disruption to my work.

leokennis 5y ago

I understand your attitude, and sort of agree with it. If I take a job with on call duty, it also means I will be woken up at night because of "your" mistakes (in code, testing etc.) and that is fine. But a very important aspect for me is that, if that happens, the developers give the correct priority to fixing the bug that woke me up at night. So, it's fine you only want to work during the day. But if I get woken up at night or in the weekend, you better start fixing the bug that caused it as soon as it's day again.

jacksonkmarley 5y ago
I mean sure, it's not like I want to refuse all responsibility. And I'm all for paying the person who does the on-call in line with doing what I consider a tough duty BTW. I guess my point is more that maybe that separation of roles actually also reflects the differences in personality and how different people work.

quicklime 5y ago

You're not an outlier, many people (myself included) feel the same way. > So I think it's awesome that some people want to do this work. I hope they do it full-time, and that lets me do my thing full-time. If you're lucky and your company lets you pick whether you want to apply for a SWE role or an SRE role (like Google), then it will work out ok. But a lot of companies just used "DevOps" as an excuse to get rid of their ops teams and dump the work onto the dev teams. Some places take it a step further and get quite toxic, and have a culture where there's a complete lack of sympathy for engineers who have a heavy oncall load. The idea is that their code is shit so they deserve to be woken up in the middle of the night, as some sort of punishment.

Aeolun 5y ago
> The idea is that their code is shit so they deserve to be woken up in the middle of the night, as some sort of punishment. I mean, isn’t that the case to some extend? It certainly incentivizes you to do better. I can see a problem when you don’t get the resources to do better though.

blablabla123 5y ago

For me it's similar'ish. My approach is this: I'm a developer but I want to be involved in all deployment related steps and ideally deploy the app from day 1 myself. The latter step is usually underestimated and helps to keep the timeline. On the other hand I learn early on how the app behaves during runtime on a real environment and can take precautions that maintenance on application level is almost only needed when deploying. A dedicated Ops team is nice when it's limited on the application level to very basic tasks like just restarting the service. If the services are not under-provisioned and have a properly set up process/app orchestration in place this is actually a non-task... Under these conditions I don't mind being on-call every now and then or even all the time if done right.

sdevonoes 5y ago

Feel the same. I do not like to be on-call. In the first stages of a job interview I always ask if on-call is required, and if so I politely decline. Edit: I'm talking about being on-call outside of business hours. I have no problem being on-call 9-5.

nijave 5y ago

Now imagine being on call for someone else's code! That's ops. Unless your company has a very strong relationship between ops and devs, the ops side gets stuck supporting whatever the developer side creates and the developer side is incentivized to jam as many features into code as quickly as possible. It's very expensive and customer impactful when you find issues in production versus prevent them in the first place with code that's a little more "runnable" (like testable code, I'm also convinced there's "runnable" or "operable" code)

sdevonoes 5y ago
"Move fast and break things" is the mantra of many of the startups out there. If only companies realise that pushing features to production like there is no tomorrow is NOT the way to go.
- Lutger 5y ago
  That's just the ops side of the fence being talked about here. The other side is having endless gating, change advisory boards, batching up work, gruesome change approval processes etc. that the ops protect themselves with against development, which now grinds to a halt. This will not only make the business slow to a halt, ironically it will also produce more errors. The really productive companies that deliver fast, are also way more robust.
fatnoah 5y ago
>Unless your company has a very strong relationship between ops and devs, the ops side gets stuck supporting whatever the developer side creates and the developer side is incentivized to jam as many features into code as quickly as possible. >like testable code, I'm also convinced there's "runnable" or "operable" code 1000% this. For me, this has been a huge focus in my past startup lives. Software and infrastructure are very related. Infra design impacts software design and vice versa. By working closely together, it's possible to try to get the best of both worlds. As a VP Eng, I expended a lot of political capital with my "why aren't you building more features" CEO boss so that my dev team could focus on significantly enhancing the stability and observability of our platform, including ensuring our log messages were informative and at the appropriate level. i.e. CRITICAL = Fix Now, ERROR = someone should check into this at earliest convenience, INFO = here's how things are generally running. Stability saved everyone time and effort, and observability allowed (and empowered) the ops team to efficiently triage, and let Engineers quickly understand what's going on and how to fix it when things went wrong. The net result was multiple nightly on-call alerts for Engineers dwindling to "I can't remember the last one" and ops folks were able to focus far more on infra than triaging software alerts. It was a battle and I had to fight to make it happen, and even have my teams "ninja" a bunch of the work via an 18 month inside-out refactor of the codebase, but the result was 200% worth it. The cherry on top was the two full-day grilling by tech leaders during due-diligence during our acquisition. They dug deep into the operational aspects of the business and came away very impressed, and that operational maturity (this was a company that highly valued such things) was highlighted as one of two key factors that swayed the decision to acquire.

zippergz 5y ago

Yup. In fact, I transitioned out of development in part because of the prevalence of this. I have learned the hard way that my work/life boundary is absolutely critical to my mental health and wellbeing. Even if it's relatively infrequent, any period of being on-call is incredibly stressful to me. I am willing to work some periods of long hours (within reason), but I am not willing to be in a position where I can be called or paged at night or on a weekend. No job is worth that to me. Hats off to the folks who can tolerate it. We need those people! But I am definitely not one of them.