Burnout and Ops | USENIX
mardi 13 janvier 2015 à 16:52@jeekajoo shaarlinks 13/01/2015
Le problème de nos métiers,
c'est notre capacité à prendre de la distance et de savoir dire fuck, tout en restant consciencieux, et surtout en restant fier de son travail.
Cette prez donne quelques pistes pour éviter les pièges qui peuvent mener à un burnout.
"""
Abstract:
Infrastructure engineering is a craft learned outside of classrooms. The discipline is ever-changing. Our value is not in credentials or the recall of accumulated facts, but instead by our capacity to tackle the unknown.
Failures of management, product, development, and QA hit us first, usually in the dead of night. Established industries have begrudigingly accepted the need to pay for 24/7 staffing, but our teams are so small that we can find ourselves permanently on-call. Some organizations delay hiring ops talent for so long that it is impossible for the new hire to improve the infrastructure. Instead the engineer is sacrificed to an all-hours cycle of quick-fixes and looming crises.
The first bout of burnout is inevitable. How are we to know our limits until we run in to them? Burnout, sufficiently advanced, is permanent damage. I've recovered from bad situations in both startups and a huge corporation. I am going to share some war-stories and describe the fixes that I implemented to protect my long-term livelihood.
Lars Lehtonen consults as an engineer for the smallest and largest companies in Los Angeles. He is one year shy of having 20 years of Linux experience.
"""
via Bed.
via https://twitter.com/jpetazzo/status/553271953889304576
(Permalink)
Le problème de nos métiers,
c'est notre capacité à prendre de la distance et de savoir dire fuck, tout en restant consciencieux, et surtout en restant fier de son travail.
Cette prez donne quelques pistes pour éviter les pièges qui peuvent mener à un burnout.
"""
Abstract:
Infrastructure engineering is a craft learned outside of classrooms. The discipline is ever-changing. Our value is not in credentials or the recall of accumulated facts, but instead by our capacity to tackle the unknown.
Failures of management, product, development, and QA hit us first, usually in the dead of night. Established industries have begrudigingly accepted the need to pay for 24/7 staffing, but our teams are so small that we can find ourselves permanently on-call. Some organizations delay hiring ops talent for so long that it is impossible for the new hire to improve the infrastructure. Instead the engineer is sacrificed to an all-hours cycle of quick-fixes and looming crises.
The first bout of burnout is inevitable. How are we to know our limits until we run in to them? Burnout, sufficiently advanced, is permanent damage. I've recovered from bad situations in both startups and a huge corporation. I am going to share some war-stories and describe the fixes that I implemented to protect my long-term livelihood.
Lars Lehtonen consults as an engineer for the smallest and largest companies in Los Angeles. He is one year shy of having 20 years of Linux experience.
"""
via Bed.
via https://twitter.com/jpetazzo/status/553271953889304576
(Permalink)