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
Top comments (5)
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.