3 ms·

I lead a fairly large team and I agree with this comment. It is certainly possible and healthier to disconnect from work after 17:00. Unless you’re in charge of

I lead a fairly large team and I agree with this comment. It is certainly possible and healthier to disconnect from work after 17:00. Unless you’re in charge of coding a nuclear reactor core or similar, your CRUD app can always wait. A streamlined on-call process should be in place instead. Taking care of your headspace and unwinding at end of the day should be one of the most important routines in a programmer’s life.

pc86 4y ago
> A streamlined on-call process should be in place instead. Honestly even 99% of non-nuclear reactor code doesn't need on call. Most of the time it can wait until the morning. Amazon? Sure, have on call. Your app that's used by businesses during the business day? Fix it tomorrow.
- quanticle 4y ago
  The part of the paragraph that really bothered me wasn't the hours, actually. It was the implication that you would be expected to code during those hours. Even when I've been on-call, I've never expected to write code, outside of business hours, during my on-call shifts. Update configuration? Sure. Roll back a broken deployment? Absolutely. But if devs are writing significant amounts of code (beyond 10-line patches, or updates to config files) in order to put out operational fires, that's a big red flag. It means that the codebase hasn't been designed to be easily changed with configuration. It means that deployments are so difficult, it's easier to try to write a patch in the moment than it is to roll back and see what went wrong in the morning. Furthermore, any code that is written under that kind of pressure isn't going to be high quality. It's going to be code that does the minimum necessary, with no documentation or unit tests. It's tech-debt equivalent of a high-interest payday loan.
tigerlily 4y ago
> Unless you’re in charge of coding a nuclear reactor core or similar If I'm managing this one, then you're definitely going home on time and getting a break from work each day.

pc86 4y ago

> A streamlined on-call process should be in place instead. Honestly even 99% of non-nuclear reactor code doesn't need on call. Most of the time it can wait until the morning. Amazon? Sure, have on call. Your app that's used by businesses during the business day? Fix it tomorrow.

quanticle 4y ago
The part of the paragraph that really bothered me wasn't the hours, actually. It was the implication that you would be expected to code during those hours. Even when I've been on-call, I've never expected to write code, outside of business hours, during my on-call shifts. Update configuration? Sure. Roll back a broken deployment? Absolutely. But if devs are writing significant amounts of code (beyond 10-line patches, or updates to config files) in order to put out operational fires, that's a big red flag. It means that the codebase hasn't been designed to be easily changed with configuration. It means that deployments are so difficult, it's easier to try to write a patch in the moment than it is to roll back and see what went wrong in the morning. Furthermore, any code that is written under that kind of pressure isn't going to be high quality. It's going to be code that does the minimum necessary, with no documentation or unit tests. It's tech-debt equivalent of a high-interest payday loan.

tigerlily 4y ago

> Unless you’re in charge of coding a nuclear reactor core or similar If I'm managing this one, then you're definitely going home on time and getting a break from work each day.