4 ms·

In my opinion, it’s almost mandatory for a well functioning software development environment to have developers on call (next to ops people). Bugs that get you

In my opinion, it’s almost mandatory for a well functioning software development environment to have developers on call (next to ops people). Bugs that get you woken up in the middle of the night are fixed in no time. Documentation that is lacking, or spaghetti code, both preventing you from quickly fixing an issue instead of spending hours on it? Fixed the next day. If the stakes of writing bad code are low, code quality will suffer. No better fix for those low stakes than being on call.

sdevonoes 6y ago
> No better fix for those low stakes than being on call. I prefer a company with a strong tech culture: code review, thinkg long-term (marathons instead of sprints) and design systems with architecture-first on mind (instead of feature-first), automated testing, QA people, don't deploy on Fridays...
- pc86 6y ago
  If you've got testing, code reviews, QA, and CI/CD, Friday deployments should be totally fine.
  - sdevonoes 6y ago
    The point is "Friday deployments" are not needed (unless we are talking about hotfixes). What's the use case? Can't it wait until Monday? Why are all in such a rush?
    - pc86 6y ago
      I would say that if things are tested appropriately (it's a big if, and not an easy thing to do honestly), when you commit a new feature it should go through the testing process and right into production. If that makes you nervous then there's more testing that needs to be added. Canary deployments with extensive monitoring and automated rollbacks and make this almost entirely hands-off. For most software systems the goal should be to abstract away the actual act of "deploying" and let the infrastructure handle that on its own.
    - tharkun__ 6y ago
      Because the company makes your rating/pay dependent on BS metrics that drive the wrong behavior, such as merging on Friday so that your cycle time isn't too high. Might mean a paycut. Friday deploy gone wrong? Fix the issue, issue another PR that is approved and also deployed in no time? You're the hero and your metrics are also awesome. Cycle time baby! :(
    - potatoz2 6y ago
      Because then you have double the changes to deploy on Monday. And if you push that logic further (no deploys on Thursday, no deploys after 3pm, no deploys +-3 days around holidays, etc.) you end up with very high density deploys, which are riskier.
pc86 6y ago
There are absolutely some industries where this makes sense (life-saving health care, national defense, things like Amazon where you literally stop making money when things go down). 90% of developers don't work in these industries or on these types of projects. Hell, I work in healthcare, for a private company, and there is zero reason for any of us to be on call. Patient quality doesn't suffer one iota if our software is down, which it rarely is. It really sounds like you're advocating that developers be on call to "fix" the "problem" that there's no reason for them to be on call?
- potatoz2 6y ago
  What they're saying is that if someone else is oncall, you tend not to deal with the quality issues of the system (it's a negative externality). If the system you own doesn't require any on-call at all, then great. But for those that do (let's say your a web developer for nytimes.com), the code and system owners should be on-call, not a separate ops team. Ideally being on-call is something you barely notice because nothing happens.

sdevonoes 6y ago

> No better fix for those low stakes than being on call. I prefer a company with a strong tech culture: code review, thinkg long-term (marathons instead of sprints) and design systems with architecture-first on mind (instead of feature-first), automated testing, QA people, don't deploy on Fridays...

pc86 6y ago
If you've got testing, code reviews, QA, and CI/CD, Friday deployments should be totally fine.
- sdevonoes 6y ago
  The point is "Friday deployments" are not needed (unless we are talking about hotfixes). What's the use case? Can't it wait until Monday? Why are all in such a rush?
  - pc86 6y ago
    I would say that if things are tested appropriately (it's a big if, and not an easy thing to do honestly), when you commit a new feature it should go through the testing process and right into production. If that makes you nervous then there's more testing that needs to be added. Canary deployments with extensive monitoring and automated rollbacks and make this almost entirely hands-off. For most software systems the goal should be to abstract away the actual act of "deploying" and let the infrastructure handle that on its own.
  - tharkun__ 6y ago
    Because the company makes your rating/pay dependent on BS metrics that drive the wrong behavior, such as merging on Friday so that your cycle time isn't too high. Might mean a paycut. Friday deploy gone wrong? Fix the issue, issue another PR that is approved and also deployed in no time? You're the hero and your metrics are also awesome. Cycle time baby! :(
  - potatoz2 6y ago
    Because then you have double the changes to deploy on Monday. And if you push that logic further (no deploys on Thursday, no deploys after 3pm, no deploys +-3 days around holidays, etc.) you end up with very high density deploys, which are riskier.

pc86 6y ago

There are absolutely some industries where this makes sense (life-saving health care, national defense, things like Amazon where you literally stop making money when things go down). 90% of developers don't work in these industries or on these types of projects. Hell, I work in healthcare, for a private company, and there is zero reason for any of us to be on call. Patient quality doesn't suffer one iota if our software is down, which it rarely is. It really sounds like you're advocating that developers be on call to "fix" the "problem" that there's no reason for them to be on call?

potatoz2 6y ago
What they're saying is that if someone else is oncall, you tend not to deal with the quality issues of the system (it's a negative externality). If the system you own doesn't require any on-call at all, then great. But for those that do (let's say your a web developer for nytimes.com), the code and system owners should be on-call, not a separate ops team. Ideally being on-call is something you barely notice because nothing happens.