Burnout
Rupert Wolfe Murray
Nov 2 '17
ă»5 min read
I'm a blogger and travel writer and have been writing a series of articles from Nepal. One of the reasons I do this is to encourage other people to write and explore their creativity, but this rarely happens as people are so tied up in their own lives.
When walking a little bit of the Annapurna Trek I got a message from Claire Pollard who said she was inspired by the things I was posting from Nepal and decided to write something of her own. She published it on dev.to
Claire Pollard is a coder who works in Cambridge. She describes herself on Twitter as a âFORTRANS programmer for @CADfix by day, BMX rider by night, robotics tweeter for @pi_borg on the side.â
I met Claire in a pub in Wales. We were introduced by a Hollywood actor called Xander Berkeley, a common friend. We became friends on Twitter, stayed in touch a lot more than I do with my other Twitter connections and I saw glimpses of her creativity: her article on dev.to was really well written and her commentary on Youtube for a Formula Pi race of tiny robot cars is dry and witty.
But I was shocked by her dev.to article she wrote on burnout and I was prompted to reply â with this article. The first sentence says, âI like to think of myself as a regular hard working person, and regularly work 14 hour days.â
Hang on a minute: fourteen hours a day? That means if she starts work at 8am sheâll still be there at 10pm. That is totally outrageous, inhumane, insane.
Whatever happened to the 8 hour day? Isnât that the legal norm in the UK? How can you have any kind of social life if youâre getting home so late at night?
What shocked me the most about her article, and the comments, was that these hours seem normal for those in the programming and coding business. And, come to think of it, I can think of designers, bankers, lawyers and other professionals in London who work these kind of hours.
Whatâs going on? Aren't they aware of burnout? Is this becoming the norm? Whatever happened to the 19th Century slogan that only came about after years of global protest: â8 hours work, 8 hours leisure, 8 hours sleep.â
In her article, Claire says â2017 was a blizzard of deadlines,â and âI very rarely fully unwind and chill out.â She is obviously a ball of energy. I take my hat off to her and really hope she can handle all that work.
This all reminds me of Nepal where people in the mountains break rocks into gravel. In every mountain village I came across there were groups of women hammering on rocks, breaking them into smaller stones so they can be used in concrete. They put the rock into a metal hoop and then bash it with a small hammer until it breaks up. They work all day, under tarpaulins stretched out like tents. These people remind me of coders, working away all day on a job that I struggle to understand.
In one village I came across two men doing this stone-breaking job. Itâs unusual to see men doing this work, as most men in Nepali villagers have migrated to the Middle East. I got chatting (one of them spoke English) and found out that they were both Tibetan Lamas (priests) and they liked doing this work as it enables them to meditate and chant on the job.
A solution for stress
Therapists say the first step towards getting better is recognising the problem. I spent years working for a rehab clinic and the first step in the 12 steps of Alcoholics Anonymous is to admit that you have lost control over alcohol. Most alcoholics canât do this and thatâs why so many of them die prematurely, clinging to their pride and denial until the grave.
But Claire is one step ahead. She recognises the problem (workaholism?) and wrote her article in a doctor's waiting room: âIâm the first to admit itâs not healthy and Burnout is a regular worry for me.â
But I question Claireâs solution. The bulk of her article is about various Apps which send mindfulness quotes to your desktop and âgently remind you to take care of yourself when coding.â
I have nothing against mindfulness. On the contrary, itâs great, but to use it in the way that Claire describes seems wrong. Mindfulness should be done as a separate activity, away from the computer, in a quiet room or under a tree. Itâs a great way of shedding excess thoughts, stilling the mind and overcoming stress.
It doesn't seem right to add mindfulness to the workload or do it in short breaks. All this would do is enable the coder to keep going, to extend their working day and to stave off burnout for a bit.
Speaking to an Expert
Before writing this article I called a therapist and writer called Chris Burn to get his perspective. Maybe I was barking up the wrong tree? Maybe the 8 hour day is a thing of the past and the 14 hour day is a norm in our neo-con world? Is this the only way we can compete with the Indians and Chinese?
Chris didnât condemn this way of life as I might have done. Therapists tend to be very considered in their replies. He asked if Claire worked like this out of choice? I canât really answer for Claire but I can make an assumption -- that many people in the nether world of coding (and many other professions) work these inhumane hours as it has become the norm. Like alcoholism, there is an element of choice at the beginning but once youâre in the grip of the bottle (or the work routine) you canât stop.
We talked about workaholism, a subject that Chris has written about. âIn Japan,â he says, âthey have a word which means Death by workaholism.â He also said that, for some, workaholism is a âbadge of honourâ even though it can drive people to suicide.
I asked him what is burnout and he said âitâs like a nervous breakdown. Your body just canât handle all the stress and pressure any more. You just stop. Itâs often linked to depression and the result is that people canât work, or eat or sleep properly. If you donât get it treated it can last for years.â
Heavy stuff. On the one hand, burnout seems so remote and unlikely for someone as dynamic and successful as Claire Pollard. On the other hand, working so many hours a day surely makes it a possibility. Someone needs to tell her that itâs perfectly okay, in fact itâs very healthy, just to chill out and do nothing for a day or two. My wee brother is the same -- heâs so dynamic he doesnât know how to stop; heâs like a runaway train.
My advice to Claire is to try something radical. From what Iâve read on this issue, people who work less can achieve more -- and this makes sense when you realise that the brain isnât designed to work for 14 hours at a stretch (writers often say they canât write for more than 4 hours a day).
Or consider doing something else. There is life outside coding and programming. Maybe Claire could go to Nepal? I know of a stunning village in the Himalayas called Haku that is a 5 hour trek from the road; they need someone to help them understand tourism, solve problems, communicate with the outside world, learn English and set up a website. Someone with Claireâs skills and energies could transform the place and I could imagine that within a few years the kids would be coding rather than breaking rocks for a living.
Postcript: I would be very grateful if you would go to my blog, where this article was first published, and leave a comment under it: www.wolfemurray.com
Great article. I think this is related to conversations we need to have with the businesses we work for about technical debt. The first thing that happens when technical debt goes unaddressed is developers end up working longer hours, under more pressure, which snowballs quickly. (Family, friends, and and health are compromised, weekends skipped, etc.)
Thanks for that Chris
Good point
But it raises a challenge:
How to structure that conversation?
It risks being one of those things we
SHOULD DO...
I think tech people should just explain to business people the consequences of ignoring the tech debt.
From what I've seen, managers and product owners tend to ignore tech debt, because repaying it usually means performing refactoring, and refactoring doesn't bring any new features to the product. So it appears useless to people who are interested in revenue. And if those people come to understand that tech debt will eventually lead to decrease in revenue then it's likely they will do something about it (or so I hope).
It would be great if developers could have a fixed amount of time (and budget) to do tech tasks.
Other problem which I've encountered in some teams is that developers are required to estimate the time for completing a task in hours and after that those estimates are treated as deadlines. Add tech debt and missing knowledge about some parts of the project you're working on to the mix, and say 'hi' to overtimes, because you have to meet deadlines somehow.
I wish it were that simple. But I think the problem is tougher than that.
I think that the most productive way forward is to start from the premise that the business does understand technical debt, but that they don't have enough visibility into how much has been accumulated, and what the likely effects of that debt load are. They need to be kept updated about how the technical debt is slowing development, causing more issues to be found in QA, requiring developers to work extra hours, increasing the frequency of production issues, etc. I'm a believer that open, clear communication really does improve decision-making and relationships within the business.
Unfortunately, I think it's often true that the business does understand technical debt, and it's consequences, and that they've consciously decided that those consequences are acceptable, even if they make the dev team miserable. If that's the case, your best option is to keep an eye out for a happier place to work, and move if/when you can.
I agree. I think the trick lies in finding a way to measure technical debt, either directly (using something like Code Climate, or something else that can track the "spaghettiness" of a codebase) or indirectly (maybe by tracking the drop in team velocity as tech debt accumulates?)
A team I used to work on used to create actual tickets (we used Jira) to track technical debt. If a feature was needed on a given deadline, we'd cut whatever corners we had to, and create a second ticket to remediate the technical debt. That tied the debt to specific features (so it could be canceled if those features were removed), and gave management visibility into the general health of the code, and the impact of aggressive scheduling demanded by the business.