Promoted partner content
How can channeling empathy lead you to become a better engineer and build better products?
We're joined by Realizing empathy author Seung Chan Lim to talk about his new book at the next Bookmarked discussion on October 29. Find out more and register here.
As a developer, I’m always aiming for the best user experience and observing how successful or unsuccessful other people are when using the products that we build. Taking that one step further, I’m even more focused on developer experience, or how enjoyable it is to use the tools that enable me to build digital products. I’m constantly asking, ‘how does my experience of building a website, app, or other service impact what is ultimately launched and put out into the world?’
In Realizing Empathy: An Inquiry Into the Meaning of Making, Seung Chan Lim offers a new perspective of the creative process in which the end result is not separate from, but is entirely dependent on, the creator’s approach and relationship to the process of making. Originally a software designer and coder, Lim seeks to resolve what he calls ‘our abusive relationship with technology’, in which people are left feeling powerless when confronted with technology that is confusing, error-prone, and inaccessible.
For answers and inspiration, Lim does a deep dive into the creative processes of both craft disciplines like woodworking, and the visual and creative arts by enrolling in graduate school at the Rhode Island School of Design (RISD). Interspersed with excerpts from his journal, Realizing Empathy outlines Lim’s exploration into the arts and details his conclusion that empathy is critical for creativity, and that empathic conversations, both with others and with ourselves, are central to the process of making. To be clear, this is not a book explicitly about the making of software, or anything close to that. However, there are several lessons that can be drawn as relevant to the work developers do – both in terms of writing code and in terms of the way we collaborate with other developers.
Lim begins his time at art school with a lesson from his woodworking professor. What’s the first step in making a chair? Learning about wood! The history, type, age, and other properties that comprise materiality are going to strongly influence how a chair can be created. As his professor says, ‘the wood is going to do what it wants to. All you can do is negotiate.’ Throughout the book, Lim notes times in which he, by listening to and being in conversation with his materials, is able to achieve a better result.
While a computer doesn’t have materiality in the same way that wood does, I would argue that developers have an acute sense of materiality, otherwise “brittle code” would not be such a common criticism. When programming, we construct a mental model of the application being built and try to step through instructions like a computer would do. Reframing this process as a “negotiation” serves as a reminder that as a web developer, the better I understand the fundamentals of how a browser renders a page, the better the experience of using my website will be. For example, even with frameworks like React and Vue, it’s easy to code a website that has janky animations. By understanding the pixel pipeline, we can learn how to structure our code to avoid expensive functions and achieve smoother animations.
Once again in the workshop, Lim finds himself unable to solder a ring despite using the same solder, torch, and steps from his professor’s lesson. About to give up, Lim’s friend walks in and immediately notices the problem, which is that he is using the wrong surface, and so the solder can’t heat properly. If you’ve ever had a bug that you couldn’t solve until you called over a colleague and immediately realized your mistake while ranting about how it should be working, this is an incredibly relatable story. For Lim, the lesson is that there’s value in recognizing that our knowledge is incomplete.
Working with computers, sometimes it feels like the universe is very specifically trying to remind me how little I know. Most recently, I had this experience attending UsableNet’s excellent webinar, How a Blind Person Uses a Website, in which I was exposed to many ways of keyboard-navigating a website beyond my approach of just using the tab key. Especially when working on accessibility, it’s important to remind ourselves that there is a whole universe of ways to use technology, most of which look nothing like our own personal way. Having the humility to recognize and question our assumptions about accessibility will not only improve our technical knowledge, but also our knowledge about how other people experience the world. As coined by the Mozilla team, this will hopefully move our products from being accessible to being ‘delightfully accessible’.
In drama class, Lim observes a professor help a student with a particularly painful moment for her character by encouraging her to reflect on her own painful experiences and translate them into her performance. Lim mentions that drama professors would frequently share their own personal experiences and actively participate in student exercises, and so they had built enough trust with their students to ask them to be vulnerable. Additionally, Lim is surprised that the professor is pleased with the actress’s performance, even though it does not reflect the most famous depiction of that character.
For senior developers and managers, it’s incredibly important to model the behavior that we want other developers to adopt. Whether that is done through a pull request (PR) review, pair programming, or even admitting and discussing our own failures, how leaders approach programming will impact how the team approaches programming. It’s important to note that the professor did not try to micromanage the exact output of their student, but rather guided her to meet the larger goal of bringing the character to life, but in her own style. Similarly, leaders that can guide junior developers to meet feature requirements, while still leaving space for them to figure out their own implementation, will ultimately see faster growth and advancement from their team members. This guidance often plays out during the PR review. It’s helpful to consider if the feedback that you are giving is educational, critical to approval of the PR, or based on personal preference – and to make that explicit for the author. Consistency and sincerity when reviewing and authoring PRs builds trust and ultimately helps improve project velocity.
In comparison with his initial, uncomfortable experiences of RISD’s woodshop, Lim describes a difficult assignment for architecture class in which he approaches the drafting table and feels a sense of confidence instead of dread. Lim doesn’t know exactly what he will do for the assignment, but having received a thorough tutorial on the protractor, rulers, and other architectural tools, he knows how to use these tools to find a solution.
For me, this recalls the experience of onboarding a new developer onto a project. A clear readme is helpful for getting a local development environment up and running, but doesn’t typically help a developer understand the structure of the application or the full context of the project. Without this information, a new repo can feel much like Lim’s woodshop – confusing, threatening, and not conducive to good programming. Strategies like pair programming on initial pull requests, keeping a decision record to capture context around choices, and most importantly, one-on-one time for questions and answers during the onboarding process, can help a new developer understand their tools enough to do courageous work.
Realizing Empathy (hey, that’s the name of the book!)
Returning to drama class, Lim’s classmate, who drew from her own painful experiences to realize those of her character, ends the semester with an original performance about her experiences. Lim notes that it was her attempt to empathize with her character that inspired her to empathize with herself and to tell her own story.
When we bring humility, sincerity, and courage into both our work and our collaborations with teammates, that is what Lim refers to as ‘realizing empathy’. By having empathic conversations in which each participant tries to both understand and be understood in an honest and sincere way, we’re able to collaborate better and do better work. This ultimately starts with, and leads to, empathic conversations with ourselves. A part of these conversations needs to be recognizing the limits of our knowledge and our biases, both specific to programming and in general. There are many different ways of working in technology and our team members will have different strengths, working styles, and lived experiences. As lead developers, it’s our job to create space for these differences and to foster a healthy team environment in which everyone feels safe, secure, and inspired to do their best work and make the best product possible.
Realizing Empathy doesn’t contain specific advice about how to run a software project day-to-day, but it does discuss a philosophy of empathy that can influence and inform our approach to, and implementation of, collaboration and process.
I’ll end as Lim does, by acknowledging that the work is to be done, and is never finished. Even after a product launches, we carry the experiences of making it to our next project, and bring the experiences of working with our teammates to our next team. For the sake of our products, our teammates, and ourselves, let’s do so as honestly and empathetically as we can.