Warning: Contains mentions of depression, anxiety and panic
I’m giving a talk at Alterconf London soon about mental health in the tech workplace. After giving it a test drive at work I’ve decided to rewrite it, but thought it would be worth putting the draft up on here. It’s not bad, it just doesn’t work so well when speeding through a talk. So it doesn’t really have an ending, and it’s a bit rough.
I want to look at the average day of a developer (need better word for this), point out difficulties that might occur at certain points, look at what could be done to make this part of the day easier to navigate. Some of these points come from my own experience, and some come from a small survey I did in the community.
Let’s start at the very beginning, walking through the door and getting to the desk. Open office layouts are very popular; in my 6 years of experience I haven’t worked or even interviewed at anywhere that does it differently. Open offices are supposed to encourage collaboration, and can have more dynamic layouts. Hotdesking is also popular; you have no fixed desk which makes it really easily to work with different people and teams as needed.
The main problem with open offices is that they are noisy. My anxiety is highly triggered by sensory overload; by which I mean I struggle to be in environments with multiple sound sources. At best this means I’m probably not able to hear or understand what is being said to me and at worst makes me snappish and have panic attacks. This makes meetings very difficult and requires me to use headphones otherwise; eliminating the supposed benefits of being in a shared space. People may feel that they are unable to come to the office at all and need to work from home.
What can we do about this? The alternative is offices and cubicles, which some will find very isolating and too quiet. Office design needs to take into consideration the needs of the users; things like acoustic management, quiet spaces for individuals and for meetings and the ability to work from home when required. Improve online communication so that in person conversations are less required, this will also help companies with remote staff.
Ok, so now I’m at my desk. First order of the day in an agile workplace is the standup. Standups are meetings where members of the team quickly talk about what they did yesterday, what they are doing today and if they have any issues that they need to talk about outside the meeting. Having a daily touchpoint like this helps the team stay connected, and give visibility of the progress of work. Around half the respondents of my survey find them useful. I like standups, I feel that they are the easiest place to have permission to say “I need work” or “I need help”.
How might a standup cause issues? While you say your piece, the entire team’s attention is on you and that can be very unsettling. I find I am prone to panic attacks during standups, which is unpleasant and increases paranoia. If the previous day was difficult or unproductive, I find I can spend a lot of the afternoon worrying about what I’m going to say in the standup. Because they are times when I can ask for work or help, I often find that I put off issues and questions until the standup. Make your standups short and to the point. Don’t chat or linger. If you’re a manager of some kind, take note of people who look like they may need help and speak to them quietly after the standup. Don’t skip the standup. Routine helps a lot of people, and missing something like the standup, especially if it starts the day, can throw people out of focus. Focusing a standup on tickets rather than people can cause people to fall through the cracks; so make sure you check in with everyone if you can.
What am I even working on today? Picking work to do is an issue. Confidence can be a factor here. Depression and anxiety lead to avoidance behaviours, we avoid doing things we think may hurt or threaten us. We are plagued by worst case scenarios. An example; I hate deployment. I’ve always hated deployment. I’ve deployed a lot of code in my career and it never gets easier. The first deployment I did here made me throw up with nerves. This means I naturally avoid tasks that require deployment. This doesn’t make life easier for me, or for workmates.
Pairing might be a good solution here, or if the person doesn’t work well with pairing, mentoring can also be good. The aim is to help the person do things which they may find difficult, and to give them someone they feel safe asking questions to. It’s not about doing the work for them, more about helping and supporting them. These techniques may also help new people in the team.
Code reviews. Even when the motto is “crit the code not the coder”. Code reviews can be a good tool to help with code quality and can serve as a first QA go-over. Coding is creative, and we get protective over creative works. Problems with confidence again cause difficulty here. Communicating over github comments is less than ideal, it is easy for context and tone to be lost. Time waiting for replies can cause worry. Having a mentor to be a neutral third party is useful to help avoid reality distortion. Do a code review in person with the developer, that way they can highlight areas that might need discussion and actually discuss them, demo the feature. Then the github code review can just be syntax and typos.