As a parent I know first hand the effects of prolonged sleep deprivation on my ability to program and the marked increase in resulting bugs. I find it a lot more difficult to program with sleep deprivation than under the influence of alcohol; At least when tipsy you’re not fighting your bodies increasing efforts to rest.
I’ve been on one call where a maintenance window got backed out specifically because it dragged out too long and we decided to throw in the towel rather than risk fatigue-related mistakes.
This is one of the downsides of not having scheduled deploys and maintenance windows…you lose the ability to say “Hey, look, we have a deploy tonight, don’t get too fucked up at the bar. Hey, look, in two weeks we have a big migration, please make sure you’re well-rested ahead of time.”
This is also why I’m a huge fan of runbooks for ops; you basically frontload the executive functioning/decisionmaking to a known good time, and then you have a greater margin of error at runtime–the dumbest code I’ve ever written was when I was too tired to pop up a level and reorient, but energetic enough (the borderline mania of the sleep-deprived) to keep trying different stuff.
(It’d be a bit interesting to also see the answers for high, stoned, tripping, or what have you–I’ve known folks to do hot work while under the influence of all kinds of interesting substances.)
the dumbest code I’ve ever written was when I was too tired to pop up a level and reorient, but energetic enough (the borderline mania of the sleep-deprived) to keep trying different stuff.
Oh god yes, I’ve been there many times. You spend hours tweaking and tuning and trying different things, often changing multiple things at the same time (which is almost never wise). And then the next day after a proper rest you need 5 minutes and come up with the “obvious” fix.
If we value production operations, we should adopt the following rule: friends don’t let friends work on the production databases tired.
How?
I agree with the general thesis, though without any recommendations for how to remedy the problem we remain where we began. Managing engineering teams is hard as it is. I’m generally aware of how engineers on my teams are feeling based on regular one-on-ones, but those are not nearly sufficient to implement this, “don’t let friends work on the production database tired” rule.
One thing that can improve this organizationally is have engineers regularly meet one on one to discuss both technical challenges and non-technical softer challenges like team cohesion, personal life disruptions, etc. In a high-trust environment, these discussions can lead to real organizational change and technical projects.
The real crux comes with how to turn these conversations into engineers willingly pulling themselves out of the on call rotation without stigma. It’s challenging. Not to mention how to implement pulling engineers out of the on call rotation unwillingly without stigma. I’m curious to hear if anyone here has implemented anything similar in their organizations.
Not to mention how to implement pulling engineers out of the on call rotation unwillingly without stigma.
I have not-seriously thought about using MarioKart as a mechanism for measuring fairly objectively whether I’m tired or not at any given time, and that decision could then be used to lock out ssh keys. ;)
I think the problem is more that this is a slippery slope to the employer blaming the employee for not sleeping enough (or well enough) and thus, if you’re in a less privileged position you might just suck it up and have to plan extensive resting periods, only cutting into your recreational time.
To be fair, if someone’s tired all the time due to their own fault (be it nights on the town or bingewatching Netflix or late-night coding on a “side hustle”), an employer should be able to tell them to get their shit together.
But this is indeed a very slippery slope, because it could also be due to a medical condition like sleep apnea or having kids (although in the latter case typically the employer would at least know the cause and know not to complain).
In the case of kids the correct solution is to grant sufficient parental leave to get the employee over the sleepless nights hump. In general it is better all around for a new parent to be freed from work responsibilities for a few months at least these days.
The current problem is we put the kids to sleep in their own beds, and then they wake up and get in our bed in the middle of the night. We need to just give in to the terrorists and buy a king size bed so we can sleep.
If an employer can hold an employee responsible for their performance then they already have all the power they need to tackle poor work due to sleep deprivation or any other private cause.
There’s no need for the employer to know about or have any say over the particular causes of poor performance.
Depends on whether it’s “the employer” or “the people you work with”. “The employer” can get bent. “The people you work with” usually are pretty friendly and interested in helping you through tough times.
Tricky if the person has anxiety. Maybe their anxiety triggers their insomnia. Getting called out by their manager could cause a spike in anxiety and that could cause a negative feedback loop.
This is some great comedy material. I’d say being tired has probably not even caused bugs in databases, but literally killed more people as a side effect, either as a user of any software or as a programmer writing any software. All I see is a person pulling 18 hour days thinking they’re saving the company. But slowly they see some flickering outside the rims of their computer screens, until finally the tunnel vision is broken: the whole damn building’s on fire! Devs are always talking about putting out fires, when the reality is, these guys are feeding them :)!
It’s been known for a while that moderate sleep deprivation produces impairments in cognitive and motor performance equivalent to legally prescribed levels of alcohol intoxication.
As a parent I know first hand the effects of prolonged sleep deprivation on my ability to program and the marked increase in resulting bugs. I find it a lot more difficult to program with sleep deprivation than under the influence of alcohol; At least when tipsy you’re not fighting your bodies increasing efforts to rest.
I’ve been on one call where a maintenance window got backed out specifically because it dragged out too long and we decided to throw in the towel rather than risk fatigue-related mistakes.
This is one of the downsides of not having scheduled deploys and maintenance windows…you lose the ability to say “Hey, look, we have a deploy tonight, don’t get too fucked up at the bar. Hey, look, in two weeks we have a big migration, please make sure you’re well-rested ahead of time.”
This is also why I’m a huge fan of runbooks for ops; you basically frontload the executive functioning/decisionmaking to a known good time, and then you have a greater margin of error at runtime–the dumbest code I’ve ever written was when I was too tired to pop up a level and reorient, but energetic enough (the borderline mania of the sleep-deprived) to keep trying different stuff.
(It’d be a bit interesting to also see the answers for high, stoned, tripping, or what have you–I’ve known folks to do hot work while under the influence of all kinds of interesting substances.)
Oh god yes, I’ve been there many times. You spend hours tweaking and tuning and trying different things, often changing multiple things at the same time (which is almost never wise). And then the next day after a proper rest you need 5 minutes and come up with the “obvious” fix.
Runbooks are great. If you can make it a testable script, even better.
Alcohol is essential for dealing with finicky concurrent code.
Thanks to the Ballmer Peak!
Nod
How?
I agree with the general thesis, though without any recommendations for how to remedy the problem we remain where we began. Managing engineering teams is hard as it is. I’m generally aware of how engineers on my teams are feeling based on regular one-on-ones, but those are not nearly sufficient to implement this, “don’t let friends work on the production database tired” rule.
One thing that can improve this organizationally is have engineers regularly meet one on one to discuss both technical challenges and non-technical softer challenges like team cohesion, personal life disruptions, etc. In a high-trust environment, these discussions can lead to real organizational change and technical projects.
The real crux comes with how to turn these conversations into engineers willingly pulling themselves out of the on call rotation without stigma. It’s challenging. Not to mention how to implement pulling engineers out of the on call rotation unwillingly without stigma. I’m curious to hear if anyone here has implemented anything similar in their organizations.
I have not-seriously thought about using MarioKart as a mechanism for measuring fairly objectively whether I’m tired or not at any given time, and that decision could then be used to lock out ssh keys. ;)
Sounds like a win all around to me!
I think the problem is more that this is a slippery slope to the employer blaming the employee for not sleeping enough (or well enough) and thus, if you’re in a less privileged position you might just suck it up and have to plan extensive resting periods, only cutting into your recreational time.
To be fair, if someone’s tired all the time due to their own fault (be it nights on the town or bingewatching Netflix or late-night coding on a “side hustle”), an employer should be able to tell them to get their shit together.
But this is indeed a very slippery slope, because it could also be due to a medical condition like sleep apnea or having kids (although in the latter case typically the employer would at least know the cause and know not to complain).
In the case of kids the correct solution is to grant sufficient parental leave to get the employee over the sleepless nights hump. In general it is better all around for a new parent to be freed from work responsibilities for a few months at least these days.
4 years in, I still have poor sleep due to kids. But yes, parental leave should cover at least the first three months if not first year.
Hey, same! Mostly because we keep ours at home and I end up making up for lost productivity at night.
Also, I found out from my Canadian friends that the first year is covered for them, which is a constant source of envy for me: https://www.canada.ca/en/services/benefits/ei/ei-maternity-parental.html
Canada, shmanada, I worked with Romanians, who work in a supposedly “developing country,” and they got a whole year of maternity leave. 😭
USA! USA! 🇺🇸🇺🇸🇺🇸🦅🎆🗽🇺🇸🇺🇸🇺🇸
Oooff. That sounds like an extreme case. I have 5 children and my experience wasn’t like that. I hope you reach stability soon.
The current problem is we put the kids to sleep in their own beds, and then they wake up and get in our bed in the middle of the night. We need to just give in to the terrorists and buy a king size bed so we can sleep.
If an employer can hold an employee responsible for their performance then they already have all the power they need to tackle poor work due to sleep deprivation or any other private cause.
There’s no need for the employer to know about or have any say over the particular causes of poor performance.
Depends on whether it’s “the employer” or “the people you work with”. “The employer” can get bent. “The people you work with” usually are pretty friendly and interested in helping you through tough times.
Tricky if the person has anxiety. Maybe their anxiety triggers their insomnia. Getting called out by their manager could cause a spike in anxiety and that could cause a negative feedback loop.
This is some great comedy material. I’d say being tired has probably not even caused bugs in databases, but literally killed more people as a side effect, either as a user of any software or as a programmer writing any software. All I see is a person pulling 18 hour days thinking they’re saving the company. But slowly they see some flickering outside the rims of their computer screens, until finally the tunnel vision is broken: the whole damn building’s on fire! Devs are always talking about putting out fires, when the reality is, these guys are feeding them :)!