No Flex Zone: Empathy Driven Development
This is a distillation of my ForwardJS talk, “No Flex Zone: Empathy Driven Development”. My basic premise:
Software development is losing sight of what it could be. Technology, at its heart, has always been aspirational — about dreaming up the impossible and willing it into existence. However, triviality in our products, sexism, racism, and misogyny consistently threaten to erode software engineering as an industry. Let’s discuss what can bring us back from the brink: empathy. Empathy for the people that use the things we make, for our non-technical teammates, and for our fellow engineers.
We’re going to start with a bit of a history lesson.
This is Margaret Hamilton; she was the lead engineer on the Apollo 11 mission, and coined the term “software engineering”.
She was 31 when the Apollo 11 landed on moon. Apollo 11 was able to land at all only because she designed the software so robustly .
Hamilton worked on all of the Apollo manned missions and a couple of the unmanned missions. Hamilton herself says that at the time, software was seen as ✨art and magic✨, not a science — which she firmly felt it was.
When we examine software built at the time, we find that it’s chiefly built for machines as well as for the sheer machinery of it; less for people. Today? Computers don’t take up a full room, we can fit them in our pockets. We need to remember we build things for people. As such, we’re going to talk about the secret sauce of building things for people: empathy.
Now, when we talk about empathy, we’re not talking about hysterics, or the act of experiencing high-intensity emotions.
Rather, empathy is about understanding and sharing in the feelings of others.
Brené Brown is a shame and empathy researcher and professor based in Texas. She calls herself a “qualitative researcher”, which I like because it means she’s focused on the whole story, as opposed to a single data points. She defines empathy as having four components:
- to be able to see the world as others see it
- to be nonjudgmental
- to understand another person’s feelings
- to communicate your understanding of that person’s feelings back to them
Overwhelmingly, empathy is a skill. We have to practice it; it’s a choice. We can’t just assume that we are “good” people, and therefore implicitly empathetic. In fact, one of the main reasons empathy is difficult is due to the high quotient of vulnerability involved — and being truly vulnerable is hard.
Conversely, we have sympathy, which is characterized by a sense of pity and distance. To quote Brown, “[n]o empathetic sentence ever started with the words ‘at least’.” If someone you know tells you they’ve lost their job, an empathetic response is not “at least you’ll be able to find a new one,” but rather something more along the lines of, “that sounds scary.”
Empathy drives connection, while sympathy drives disconnection. — Brené Brown
If we’re able to be vulnerable and feel with people, we’ll create connection. According to Brown, “a sense of connection is what gives purpose and meaning to our lives.” Feeling connected to others inevitably leads to collaboration. Collaboration is, of course, what allowed early humans to become apex predators, and lets us do cool stuff like live completely outside of the food chain, as well as have best friends.
Now that we have some background on empathy, let’s apply it!
Empathy for our customers
Software these days is much more customer oriented. We build things like apps, store fronts, and social networks, and then want people to like it so much that they give us money. Software as a service is a thing in our industry, and the operative word should be “service”.
HOWEVER, have you ever tried to use software you didn’t build? It can be incredibly difficult. I’ve definitely felt this way, and I’m not what exactly what you’d call a computer novice.
It’s imperative that we remember no one is born an expert, and that we often forget the pain of our individual learning curves. Flows in software are complex, and our familiarity comes from spending 40 hours a week cultivating it.
Strangely, many engineers have disdain for users because they lack that self-same knowledge that comes from the familiarity we each have with our respective products. This disdain can manifest even when users stumble upon truly unintuitive flows in our products.
There are only two industries that refer to their customers as ‘users’: illegal drugs and software. — Edward Tufte
Moreover, we call them users. We don’t even call our customers “customers”. Again, we call them users. To be absolutely frank: our terminology is othering and we treat people who are literally giving us money so we can live with contempt. We should call them people, clients, or customers — any word that forces a realignment of our thought processes, to remind us who really call the shots. Words mean things, after all.
Ironically, our disdain is completely misplaced. Have you used software today? It’s complex and filled with anti-patterns, all of which grow daily as software proliferates our lives.
During usability experiments, the researcher cannot interfere; the purpose is to gather an unbiased picture of how people interact with software. Watching someone else use your software, though? Oof. It’s don’t-go-into-that-house horror movie levels of bad.
Usability research (the practice of observing people using our software), is fairly common in software development, because often, we can’t ask our customers directly for what they’d like to see improved in our flows. Improvement in these flows will only come via empathy. Empathy is an edge, a competitive advantage — but only if we continually remind ourselves that that human people use the things we make.
Seamless is a food delivery service that’s incredibly popular on the East Coast. In 2013, they merged with GrubHub, and recently, the two companies combined their backends and released a refreshed user interface.
The reaction to these updates was really strong. It was a total “who moved my cheese” scenario, as customers had gotten used to the application’s flow, regardless of its inefficiencies. Customers had already expended the mental how to get from Point A (logging in, searching, placing order), to Point B (purchasing food), and it worked for them despite how counter-intuitive it may have seemed.
We need to remember that familiarity is a more powerful concept than intuition. While we should always strive to make easy-to-use software, we need to remember that this doesn’t serve the people who already know how to use the software as it exists today.
Additionally, the groups building software overwhelmingly don’t resemble the groups using the software. This is problematic, and one of the host of reasons software development is getting a (much) deserved bad rap.
In 2014, Apple released the Health app as a part of iOS 8. This app didn’t have the ability to track a menstrual cycle. Which is a huge blindspot in the application, as a menstrual cycle is a key indicator of a woman’s health. Like, it’s something that should happen routinely over the course of forty years of your life, but you can’t track it?!
Empathy combined with knowledge of the product could’ve avoided this blindspot. Apple got dragged by the press, and they announced that iOS9 would have this ability come fall 2015. They’re correcting the blindspot, but only after a full calendar year.
Interestingly enough, however, usability studies combined with familiarity can sometimes result in something “competitively important”. There’s a Harvard Business Review article about sparking innovation with empathetic design, which is the idea that employees of a company have the context and familiarity with the product they build. When we examine problems from this slant, it’s possible for us to find new opportunities to innovate; to make new things that people probably want.
Take, for instance, an example from the empathetic design HBR article: the invention of a women’s razor. Typically, women don’t shave their faces; men’s razors, therefore, aren’t designed for most women’s use. A woman working at Gillette redesigned the men’s razor to fit a woman’s hands and needs (e.g., shaving things like knees, underarms, and ankles). The women’s razor was a total success. It wasn’t as though Gillette intended to find a new market; it was there all along. They were, quite literally, already making razors. These kinds of opportunities, the kind that combine innovation and empathy, undoubtedly exist for us today. We merely need to be on the look out for them.
Empathy for our workmates
Traditionally, Engineering is a real hostile department. We’ve got a lot of power, and not a lot of oversight — especially in more Engineering-driven organizations. The inmates are running the asylum. How can we foster and create a more empathetic environment, especially among departments who infamously don’t get along?
For instance, Engineering and Marketing have never seen eye-to-eye. It’s a real feel-it-in-your-bones-pass-it-down-to-your-children blood feud.
Which, I never really understood, as they are literally trying to tell people about our hard work. The same goes for Sales: they are trying to sell our hard work for money, which, as participants in a capitalist system, we all need.
Why the distrust? It’s because suspicion and mistrust comes from comes from not understanding what these departments are doing, and not having any visibility into their workflow.
We need to start feeling empathy for these teams and treating their work as valid — as valid as engineering work. For instance, in the case of Sales, often they’ll have a quota they have to hit, else they literally lose their jobs. It’s an incredibly high-stakes profession. As engineers, we won’t be fired for building fewer features; in fact, we’ll probably be promoted if we manage to simplify the feature-set.
At the end of the day, Marketing, Sales, Product, Customer Support, Engineering, et al. are interlocking systems. We cannot succeed without one another. We cannot forget we build things with and for our workmates.
Empathy for ourselves
Within our ranks we have a host of problems:
- What are we even building? There are a lot of products we’re spending our time and energy on that don’t have a lot of utility.
- There are increasing social problems. For instance, women leave software at a rate of 50%, and there’s an distinct lack of diversity on our engineering teams.
As such, we need to work on solving these problems by making software a no flex zone.
What is a no-flex zone?
“No Flex Zone” comes from a great song by brothers/rap-duo Rae Sremmurd that cautions against an environment of posturing. Teens! So great. The words are literally, no flex zone! no flex zone! — they know better. They knooow better. It’s true. We do.
Let’s apply that to our work environment. Is it welcoming? How do you treat questions that people ask? Is it a “no flex zone”? For software development to truly thrive, it can’t be a flex zone.
I’ve worked in flex-zones, where someone is throwing around their weight around; it’s equal parts obvious and awkward, as the behavior is wholly based in insecurity. Flexing, categorically, is silly. In fact, we want flex-free workplaces.
An example of flexing is the the act of feigning surprise when a person doesn’t have the context or knowledge you do. It comes across as alienating and condescending. Moreover, in these flexing moments, in these clumsy attempts to distinguish ourselves as knowledgeable, we miss opportunities for empathy. In fact, you endear yourself to a workmate when you take the time to teach them, as well as enforcing your own knowledge set.
Ultimately, we want to be warm, be kind, be accessible. It’s the empathetic thing to do, and is the breeding ground for constructive collaboration.
Building software is becoming more collaborative process, especially as we look at the success of tools like GitHub and Slack (both of which were built, in hindsight, to fit a clear need). So, as we collaborate, we also need to think about the process of disseminating information, and how we do that; that’s for both the actual information sharing and the tone we take in sharing said information.
With all this in mind, how can we begin to build an empathetic codebase? First, let’s talk about what an empathetic code base is, and what it has:
- comments;
- code reviews;
- scripts;
- and any other tools that will provide context.
Comments
Comments are our first-line of defense in building an empathetic code base. Comments allow us to give context to new hires, but also ourselves. I don’t know about you, but I’m a functional amnesiac when it comes to programming. When I’m in the middle of a problem, I totally understand all parts and the specificity. Six weeks later? I couldn’t tell you even if I wanted.
Code comments lower our collective cognitive load by providing context where its needed. In addition, writing robust comments allows you to forget what you know safely.
Code Review
The process of releasing code is one of the most important action in our jobs, and it behooves us to get the best review we possibly can. So, provided we’ve thought about our problem and have opened a pull request, what should we do?
- First, do no harm: assume good intent. As a reviewer, assume that your workmate is doing their best to solve a problem.
- Provide context: As a reviewee, don’t assume your workmate has all the context you do. Giving your workmates context means they don’t have to track you down or find the link to the issue in the bug tracker, they can easily get to work reviewing your code. Efficiency!
Communicating is hard! It’s difficult to derive context from something typed in a text box. Text can be terse, and interpreted not at all like what you’d have said in person. Remember: GitHub supports emoji, which adds a sense of playfulness to comments, stripping it of its harshness. Use them!
When reviewing code, or generally explaining technical things, let’s strive to take ownership. It’s not “your code is bad”, but “our code is bad”. It means removing words like “just” from your vocabulary. “Just” is the kind of word that minimizes the kind of effort something will take. For instance, telling someone to “just re-architect the whole flow,” discards the time and effort someone has spent working on a feature and the time it will take to complete the new work requested.
Docs Or It Didn’t Happen
Everyone likes good documentation, and no one likes to write it. However, it’s essential for reference and on-boarding — software is a complex machine, composed of moving parts, and it needs a manual. Working on software without guidance, without documentation is anxiety-producing; not having documentation makes it hard to deploy code with confidence. Complex code (read: all code) simply is not production ready without documentation.
Automate All The Things
Think about the things that make your life and job easier. Can it be automated? If it makes your life easier, then it’s likely it can make life easier for your workmates too. This shows empathy in that you’re considering another person’s workflow, and trying to make it better.
TL; DR
Empathy is feeling with people.
We build software for all kinds of people, and empathy helps us to connect to these disparate audiences. We have to choose empathy, but I’d argue, it’s undeniably the “one weird trick” to future-proofing the software engineering.
Remember: empathy is a competitive advantage, and can help us stand out when building things that take people’s actual needs into consideration, while empowering us to build more interesting, innovative things. When we apply empathy to our non-technical teammates, we end cycles of mistrust, and can collaborate to move further than we could otherwise. When we apply empathy to our fellow engineers, we can focus less on time-consuming minutiae and focus on solving the real problems at hand.
Go out there, and make your workplaces a no flex zone. We’re building an empathetic code base. Get on board.
Thank you.
Many thanks to the following darlings who helped me craft this talk, and listened to me prattle on about empathy for the past few months. This truly was a community effort:
Ahmad A., Bruce Spang, Diógenes Brito, E.A. Nakashima, Eric Hodel, Haley Smith, Ibu Madha, Inés Sombra, Jade Applegate, Jurema Gobena, Kauser Manjra, Kelsey Gilmore-Innis, Kyle Kingsbury, Mark Christian, Nolan Caudill, Paul Hammond, Peter Youngmeister, Rachel Myers, Ryan Huber, and all the members of the Slack Engineering team.
