…But only for work, life, and effective communication. I mean, other than that, you probably don’t need it.

Last week, I ventured off to the magical land of Copenhagen, Denmark. Aside from eating delicious food, sightseeing, and enjoying the overcast weather all week, I also happened to be speaking at DockerCon EU.

At my first DockerCon seven months ago, I watched non-stop technical talks about getting started with Docker. I was newer to the community at the time, and the conference served as a great kickstarter into the world of containers. I also tried to meet as many Docker Captains as I could to pick their brains. And I interviewed a pigeon…

This time, since I was giving the Docker 101 talk, I decided to hop on over to the Transform Track of the conference to see what exactly “transform” meant. Was Docker about to announce Optimus Prime support?

Sadly, no. It was Kubernetes. But turns out the Transform Track was pretty fantastic. Here’s the official description:

The Transform Track focuses on the impact of change — both for organizations and ourselves as individuals and communities. Filled with inspiration, insights, and new perspectives, these stories will leave you energized and equipped to drive innovation.

When going to a technology conference, I feel like folks are often hesitant to attend tracks that are less tech or more thought, and I understand why. You’re there to learn, and you (or your company) have paid a lot of money to fly/house/feed you while you’re there. Often, you need to write up a report on the value of the conference, your takeaways, etc. (see: this blog post ✍️). But I’m here to admit…

I Went to DockerCon Copenhagen, and All I Got Was All the Feels

Close your eyes for a moment and imagine those words on a t-shirt.

Are your eyes open again? Great, let’s continue.

Honestly, this was a very pleasant surprise at what I already knew would be a great technical conference. Brace yourself for Chloe’s highlight reel from the Transform Track…

If you ever get the chance to see Lauri Apple speak, do it. Lauri and I met earlier this year at ShipIt Con in Dublin and have since bonded over all things technical, conference-related, and quirky. Her talk “We Need to Talk: How Communication Helps Code” was a very candid look at communication, empathy, and open values when building software. The upshot: it’s important, and it’s actually pretty easy.

Something I have struggled with understanding as a human newer to the world of engineering is the constant conversation happening around empathy. As far as I’m concerned, empathy is not a nice-to-have. It’s a must-to-have… Uhhh, must-have.

I’m often baffled by comments about individuals who lack empathy. I’ve heard justifications of non-empathetic behavior like “Yeah — he’s not the nicest person, but he’s brilliant” or “Please excuse her lack of tact — she’s knows what she’s doing when it comes to [insert technology here]”. Lauri’s talk helped solidify my views that empathy is essential to successful development.

Perhaps it’s time to rethink our continued acceptance of non-empathy. We don’t need to sing kumbaya and talk about our feelings, but we do need to be thoughtful communicators. Lauri mentioned in her talk that empathy “can be developed over time” and that “few are born great communicators — it’s a learned skill.” Not everyone will be tactful and kind from day one, but not learning to be empathetic towards co-workers and users is a sure sign that the scale of outcomes will diminish in the future.

Empathy Is Not an Emotion, It’s a Skill

Empathy can make the difference between a motivated and an unmotivated team. Would you want to work on a project where questions, pull requests, and general interaction were greeted with snark, one-upsmanship, or dead silence? Me neither. Being friendly and welcoming to your co-workers and contributors is essential to successful communication, which is ultimately much of the point of modern engineering practices. Collaboration removes the friction from delivery and replaces it with continuity, speed, agility. No, you don’t need to send swag or use all the emojis (can’t hurt, though: 🌈🙌🎊💯). But acknowledging intent and a genuinely polite response goes a long way. No one likes to be ghosted or ridiculed, and effort should be acknowledged.

Nirmal Mehta’s talk “A Strong Belief, Loosely Held: Bringing Empathy to IT” explored similar topics. Nirmal introduced game theory and how to apply it to the world of DevOps. In order to avoid a probabalisticly efficient (i.e., zero-sum) but non-beneficial endpoint scenario between development and operations, he encouraged “changing the game” so that the starting point is zero, from which any deviation improves the average outcome. That deviation, by definition, is communication, and a sustainable probabilistic optimization arrives from collaboration between the two sides. If dev and ops listen to each other, they both assure at least no additional cost. If they both talk and listen empathetically, they can actually achieve a beneficial inefficiency where either or both gain from helping the other, still without any direct cost 🤔

He shared a story where a junior developer asked him a question that, in the moment, he quickly dismissed. However, after revisiting that conversation later, he realized that his response should have been more empathetic because, ultimately, Nirmal’s lack of listening didn’t benefit either of them. Perhaps that engineer was nervous. Would his own response accomplish anything other than making that engineer even more nervous about asking questions in the future? Could Nirmal count on the engineer for anything, especially since there’s no mutual understanding of objectives?

As Nirmal said in his talk: “Become empathetic about the other point of view.” This could mean your users, your co-workers, even your barista. Be mindful of the things you say because, even when there isn’t an opportunity to negotiate, there’s often still a chance to change the game so that any next move adds benefit with no added cost. People are going to be more willing to engage and contribute if you’re prepared to avoid conflict and think, speak, and act with a goal of collaboration.

Below is my favorite slide from Nirmal’s presentation. I could honestly write an entire blog post on every line of this slide, but I recommend you watch his talk instead (if only for the Golden Balls videos alone).

I’ll leave you with a helpful mnemonic device I tweeted earlier this week while I was reminiscing about my DockerCon EU experience attending Transform Track talks and writing this blog post. The upshot is that empathy is key to optimizing the benefits of human interaction, even if you’re a mega-badass engineer. Modern software development requires more collaboration, not less, so start learning how to be good:

Here's an easy acronym I made to remember how to be a good engineer 💁🏼‍♀️:

Sentry provides open source error tracking that shows you every crash in your stack as it happens, with the details needed to prioritize, identify, reproduce, and fix each issue. It also gives you information your support team can use to reach out to and help those affected and tools that let users send you feedback for peace of mind.

Each month we process billions of exceptions from the most popular products on the internet.