4 ms·

Sorry, but not. I keep my 9-5 strict. I'm not into the game of getting more money in exchange for my scarce free time. If the company needs people to work on Su

Sorry, but not. I keep my 9-5 strict. I'm not into the game of getting more money in exchange for my scarce free time. If the company needs people to work on Sunday mornings, they can hire them (i.e., SREs). I can't understand why it is becoming so normal for regular (senior) developers to become slaves of our companies by working more than 40h/week; the general excuse is "you build it, you run it, you fix it". If we are into writing robust software, I'm all in, but that's a totally different thing. Edit: I'm not in my 20s anymore and I have a family.

bogantech 5y ago
The idea of "you build it you fix it" is to make sure things really are fixed because you value your time. And it works. When there's an ops team responsible for on-call nobody gives a shit about fixing the code issues that wake them up.
- Twisol 5y ago
  The current development team didn't always build it, either. And the pressures and incentives are often biased away from improving things, no matter how much individual developers might want to. "You build it, you fix it" has to apply to the powers that be (i.e. the product managers and such), not just the individual contributors.
- afarrell 5y ago
  > nobody gives a shit If you start from the assumption that your employees are not motivated to do a good job and so they need to be punished for doing a bad one… I’m not sure what to tell you.
  - bogantech 5y ago
    More like where I worked where that was a thing the ops team were a slave class in a company mainly staffed by devs
- cgrealy 5y ago
  This is great in principle, BUT.... it only works when the dev team are given the time and automony to prioritise the work. While many organisations pay lip service to uptime and reliability, the reality is that those are not sexy or exciting and Bob in sales just snared this million dollar client that will sign as soon as we implement frobnication with Othr. So dev team can either work on fixing the reliabilty issue that means they don't get paged at 3am or implement the thing that get the company another $1m. Which do you think they get to do?
  - dvtrn 5y ago
    While many organisations pay lip service to uptime and reliability I had a very terse conversation about this, and directly included the words “lip service” to my superiors today about the very topic of on-call and overnight work this morning. I’m fed up, and made it known. Because IMO you’re 100% right, too many orgs pay lip service to availability and SLAs, yet deliberately choose to underinvest in tooling and resources to help mature the capabilities of incident responders. Does it bring it revenue? Probably not, but bailing water doesn’t move a ship across open seas either, you still do it because if you don’t surprise, no more fucking ship. Instead of a well defined monitoring system I get $40/mo for the lowest tier status board that’s generated more false-positives than actual on cable alerts, no matter how I tune it or try to define parameters. Instead of a mature incident response platform I’m demanded to conduct Spreadsheet postmortems. Instead of centralized logging and telemetry I get to troubleshoot exceptions over a bunch of shell windows. Incident response is still a mess of people slapping keyboards, there’s no triage, there’s no sense of structure or command of the process. And here I am, an SRE being prioritized to work on backing up service accounts because we might not get a contract with this trucking company if we don’t have that capacity. Sigh.
    - cgrealy 5y ago
      Unfortunately, this kind of thing is almost impossible to deal with from a grass roots angle. Unless you have a culture that values these things from the top down, you're going to give yourself a concussion banging your head on a brick wall.
- steveBK123 5y ago
  Put the product managers who prioritize new stuff over bug fixes on PagerDuty if you really want stuff fixed for real. It's not like devs choose what to work on & prefer the 70% solution before moving onto the next demand..
- redisman 5y ago
  Sure I’ll fix it. During normal work hours the next day
- kayodelycaon 5y ago
  If no one gives a shit about the ops team, having a "you build it you fix it" rule is just papering over a much larger problem. In every job I’ve been in, I’ve been responsible for bad code I didn’t build and had no authority to fix it. This only gets worse when one team member can’t and never will be on-call. Because everything is focused on “individual responsibility” anyone who isn’t “carrying their weight” gets singled out, instead of actually fixing the systematic problems. It’s much easier to blame people and make examples out of them than to actually address the real issues.
- xboxnolifes 5y ago
  Which is great, but would also require time given to teams to fix all issues they see in the code and not work on new features.
Ancalagon 5y ago
Its not even a good excuse. Both of my last roles had on-call rotations, and they were really shitty. The code wasn't even mine and I was expected to support it because the original developers had up and left ages ago.

bogantech 5y ago

The idea of "you build it you fix it" is to make sure things really are fixed because you value your time. And it works. When there's an ops team responsible for on-call nobody gives a shit about fixing the code issues that wake them up.

Twisol 5y ago
The current development team didn't always build it, either. And the pressures and incentives are often biased away from improving things, no matter how much individual developers might want to. "You build it, you fix it" has to apply to the powers that be (i.e. the product managers and such), not just the individual contributors.
afarrell 5y ago
> nobody gives a shit If you start from the assumption that your employees are not motivated to do a good job and so they need to be punished for doing a bad one… I’m not sure what to tell you.
- bogantech 5y ago
  More like where I worked where that was a thing the ops team were a slave class in a company mainly staffed by devs
cgrealy 5y ago
This is great in principle, BUT.... it only works when the dev team are given the time and automony to prioritise the work. While many organisations pay lip service to uptime and reliability, the reality is that those are not sexy or exciting and Bob in sales just snared this million dollar client that will sign as soon as we implement frobnication with Othr. So dev team can either work on fixing the reliabilty issue that means they don't get paged at 3am or implement the thing that get the company another $1m. Which do you think they get to do?
- dvtrn 5y ago
  While many organisations pay lip service to uptime and reliability I had a very terse conversation about this, and directly included the words “lip service” to my superiors today about the very topic of on-call and overnight work this morning. I’m fed up, and made it known. Because IMO you’re 100% right, too many orgs pay lip service to availability and SLAs, yet deliberately choose to underinvest in tooling and resources to help mature the capabilities of incident responders. Does it bring it revenue? Probably not, but bailing water doesn’t move a ship across open seas either, you still do it because if you don’t surprise, no more fucking ship. Instead of a well defined monitoring system I get $40/mo for the lowest tier status board that’s generated more false-positives than actual on cable alerts, no matter how I tune it or try to define parameters. Instead of a mature incident response platform I’m demanded to conduct Spreadsheet postmortems. Instead of centralized logging and telemetry I get to troubleshoot exceptions over a bunch of shell windows. Incident response is still a mess of people slapping keyboards, there’s no triage, there’s no sense of structure or command of the process. And here I am, an SRE being prioritized to work on backing up service accounts because we might not get a contract with this trucking company if we don’t have that capacity. Sigh.
  - cgrealy 5y ago
    Unfortunately, this kind of thing is almost impossible to deal with from a grass roots angle. Unless you have a culture that values these things from the top down, you're going to give yourself a concussion banging your head on a brick wall.
steveBK123 5y ago
Put the product managers who prioritize new stuff over bug fixes on PagerDuty if you really want stuff fixed for real. It's not like devs choose what to work on & prefer the 70% solution before moving onto the next demand..
redisman 5y ago
Sure I’ll fix it. During normal work hours the next day
kayodelycaon 5y ago
If no one gives a shit about the ops team, having a "you build it you fix it" rule is just papering over a much larger problem. In every job I’ve been in, I’ve been responsible for bad code I didn’t build and had no authority to fix it. This only gets worse when one team member can’t and never will be on-call. Because everything is focused on “individual responsibility” anyone who isn’t “carrying their weight” gets singled out, instead of actually fixing the systematic problems. It’s much easier to blame people and make examples out of them than to actually address the real issues.
xboxnolifes 5y ago
Which is great, but would also require time given to teams to fix all issues they see in the code and not work on new features.

Ancalagon 5y ago

Its not even a good excuse. Both of my last roles had on-call rotations, and they were really shitty. The code wasn't even mine and I was expected to support it because the original developers had up and left ages ago.