Samsung Internet Dev Hub - Resources for developers

Developer Hub

The Economics of Empathy

2018-12-06 Jo FranchettiWeb Development

The Economics of Empathy

All I need to be a software developer is coding skills, right?!

A short while ago I sent out a tweet saying that in order to remain relevant as software engineers then we needed to focus on our skills of empathy, cognitive diversity and self-care.

I’d like to expand a little upon my thoughts behind this tweet and explain why, as some of the replies assumed, it isn’t all “airy fairy cotton candy wishes”.

When we’re developing software it is easy to get carried away with the tech. We want to use the most up to date techniques, the hot new libraries and packages. We sometimes forget that we’re building things that a whole spectrum of people will be using.

Empathy

Icons illustrating See, Think, Feel, DoIcons illustrating See, Think, Feel, Do

Understanding how and why people use the products and services we’re building makes economic sense. Understanding their needs, their lifestyles, their reasons for using your software can make the difference between building software that they enjoy using and software that they hate. It shouldn’t be surprising that enjoyment leads to better engagement. Empathy allows us to understand the feelings and experiences of others without their having to tell us directly, usually because we’ve experienced them ourselves and we can recognise them and relate. For example; waiting on a page that is loading slowly, being made to queue for something you really want to purchase, frustration at confusing or misleading UX or being bombarded with notifications. You’ve likely experienced one or more of these and therefore would hesitate to write code that might cause similar feelings for others.

Bruce Lawson standing on stage presenting at DeltaV conference. His slide shows the number of hours, on average, people from different countries have to work in order to afford 500MB of data. [Germany 1 hour, United States 5.7 hours, South Africa 18hours, Nigeria 26.2 hours and Brazil 34.4 hours]Bruce Lawson standing on stage presenting at DeltaV conference. His slide shows the number of hours, on average, people from different countries have to work in order to afford 500MB of data. [Germany 1 hour, United States 5.7 hours, South Africa 18hours, Nigeria 26.2 hours and Brazil 34.4 hours]

Take a look at the image above, of a slide from a talk by Bruce Lawson. In this slide, he presented the number of hours that people on an average wage for their country have to work in order to afford 500MB of data a month. As developers, we tend to be pretty heavy data users. I know I’m thankful for my unlimited data contract and the fact that, not only is that available to me but I can afford it. I value that ability to consume as much data as I want, to not have to worry about giant downloads or 3rd party libraries. When I see that people in Nigeria have to work 28.2 hours to afford just 500MB and for those in Brazil it costs almost a week’s worth of work I can start to understand how important it is that I build websites that aren’t bloated, that are optimised to be as small a download as possible. In doing so I make my website accessible to a global audience, meaning not only can I reach more people, but I also greatly increase the size of my potential customer base.

Microsoft recently brought out their ‘Inclusive Design Toolkit’ which aims to help developers to build accessible websites. Accessibility is something that is often overlooked by development teams or botched in as an afterthought. This is usually because everyone on the team is a tech-literate, mouse and keyboard user with good sight, mobility and cognitive functionality. They don’t necessarily consider the people that they’re excluding with their work because they’ve not experienced the way in which people with accessibility requirements use their website.

As the toolkit explains- temporary and situational impairments can help all of us to empathise with those who experience impairments or disabilities. Situational impairments describe those which cause difficulties due to a change in environment, imagine trying to use a website with a low contrast colour scheme when you’re on your phone in bright daylight, or trying to use your computer while also holding a baby, or even trying to find your route home while drunk. Temporary impairments refer to shorter-term issues like a broken arm, concussion or other injuries. Now I’m not suggesting that all web developers should go out and break their arms, but I am saying that these are issues that many of us can relate to. Once we’ve experienced the frustration that low contrast, poor keyboard navigation and tiny buttons can bring, we can start considering these things when we’re building in order to make our work usable by everyone, again increasing the size of our potential user base. (For more information on how to improve the accessibility of your sites check out this great blog by our very own Amy Dickens)

One of the ways that we can work on our empathy skills is by running user testing. Observing people using what we’ve built, especially on with a range of devices with a range of processing power is a great way to understand the ways you could be excluding people or making their experience frustrating.

Empathy doesn’t only help us connect with our users either it helps inside our work environments too. The majority of us will be working with other people when we’re programming, whether they’re other programmers, designers, product developers, testers, clients, you name it. Empathy and understanding of the people you work with will make you a much more pleasant colleague and will aid in collaboration and making your work environment a constructive and effective place to be. Practising empathy, walking that proverbial mile in our colleagues’ shoes, will make reaching solutions easier, make communication between disciplines less tense and, especially if you’re managing or mentoring, will allow you to support those under you much better. (If you’d like more information on how to support your mentees with empathy, and improve your own skills at the same time, check out my talk on mentoring).

April Wensel, the founder of Compassionate Coding, gave an incredible keynote talk at Node+JS Interactive conf on empathy, inclusion and self-care titled “Programmers Don’t Like People… Or Do They?” in which she outlined where many of problems with the lack of empathy in the tech industry originated, and how to better employ empathy and compassion in your teams. I highly recommend watching it!

Cognitive Diversity

The second skill I mentioned in the tweet was Cognitive Diversity. This is the idea that different people think in different ways and will process information differently to how you do because they’ve had different life experiences to you. Understanding and applying cognitive diversity differs slightly from empathy in so far as that to improve your own cognitive diversity you don’t necessarily have to have experienced the same thing as someone to be able to understand that their view is valid and reasonable. There are far too many examples of products being built that not only exclude people but are sometimes even harmful. Be it smart products that don’t recognise women’s voices, soap dispensers that don’t detect the hands of people of colour or voice assistants that aren’t equipped to assist someone who is suicidal. There are some situations that we’ll never be able to empathise with, because we can’t or haven’t experienced them, and that is where we can employ cognitive diversity. Not only does it allow us to understand that there might be different viewpoints out there, but that if those viewpoints aren’t represented in the spaces that we’re working in and the people that we’re working with, then we can’t help but build uninclusive, inaccessible technology.

It has been proven time and time again that a diverse team makes better products, solves problems faster and, in the end, will bring you a better bottom line. Cognitive diversity doesn’t mean “Well, we’ve got one developer who graduated from Cambridge and one from Oxford”, it means that you’ve got people from all different walks of life, from different races, genders and abilities working on your team. If you look around your office or your team and you only see people who look like you then it is time to consider how you can increase your cognitive diversity, both your own and that of your entire team.

Self Care

selfcare.jsselfcare.js

The final thing I mentioned was self-care. Our industry can often promote unhealthy lifestyles. Being a developer, no matter how exciting or competitive, is a sedentary job, we sit down and stare at screens for much of the day. Taking time to stretch, to raise your heart rate and to give your eyes a break is very important to staying healthy. The tech industry also has an unfortunate association with greasy food and copious quantities of alcohol, while I’m not shaming anyone for enjoying either of these things, a poor diet can reduce your ability to concentrate and to sleep well, which impacts both your physical and mental health over time.

Which brings me neatly on to mental health in the tech industry. As I mentioned before, the industry is competitive, it is intense, there are always new things to learn, developers are constantly building new and exciting tools, libraries and frameworks. Many developers suffer anxiety around keeping up to date, they’re pushed to working longer hours, to feel like they’re not good enough. I’ve spoken to developers from all around the world who suffer from impostor syndrome, perfectionism, anxiety, stress and depression because of their careers. Eventually, all of these can take a toll on your physical health and can lead to burnout, leaving you physically, mentally and emotionally exhausted. Practising self care — taking time for yourself, checking your emotional state, eating well and switching off from work to maintain a healthy work-life balance — might seem like a pause in productivity at the time, but in the long run will ensure that you’re able to keep going, to keep being productive and to still be a functioning, relevant developer (and human being!) in 10 years time.

By Jo Franchetti on December 6, 2018.

Canonical link