Developers are From Mars, Developers are From Venus

Talks

Adam Keys

#emotional-intelligence

#developer-experience-dx

#conflict-resolution

#software-development-practices

Developers are From Mars, Developers are From Venus

by Adam Keys

The video titled "Developers are From Mars, Developers are From Venus" by Adam Keys discusses the importance of effective collaboration among developers, emphasizing that many project failures stem from social issues rather than technical ones. Keys reflects on his personal journey of recognizing the necessity of improving interpersonal skills to foster better teamwork, as he believes that communication can be as powerful as technical proficiency in software development.

Key Points Discussed:

Understanding Differences: Keys likens the differences among developers to the famous self-help model of gender differences, explaining that by understanding various personality traits and styles, developers can work more harmoniously together.
Identifying Developer Types: Keys categorizes developers into different character types, which helps in understanding their motivations and improving collaboration. The types include:
- Grinders: Rapid coders focused on iteration and fast feedback. They often need guidance towards more structured approaches like Test-Driven Development (TDD).
- Tour Guides: Experienced developers who understand the complexities of codebases deeply. They mentor others but can become overworked if not communicated with effectively.
- Geniuses: High-level thinkers committed to perfection who may overthink and hinder progress if not guided.
- T-Shaped People: Specialists in one area but having a broad understanding of multiple areas, requiring patience and encouragement during collaboration.
- Fun Leaders: Developers with both technical skills and people skills who help mediate and keep team dynamics healthy but should not be relied upon exclusively.
Personal Reflection: Keys shares his own learning experiences, stressing the importance of knowing oneself and practicing empathy. He provides tools like Hanlon's Razor (assume ignorance over malice) and Occam's Razor (simplest explanation is often the correct one) for better interpersonal communication.
Promoting Kindness in Communication: Emphasizing the need for emotional intelligence and understanding the context in tech communication, particularly in an online environment where nuance may be lost.

Conclusion and Takeaways:

Effective teamwork is about recognizing and valuing differences among team members, enhancing collaboration through understanding, communication, and empathy.
Developers should take responsibility for their interactions, fostering a kinder and more inclusive working environment.
The key to improvement lies in recognizing one's tendencies and adapting to the needs of others, thereby creating healthier team dynamics.

00:00:20.400 All right, so first of all, I have to thank you all for choosing to either wait the traffic out or not be in traffic here. That is an incredibly amazing thing.

00:00:27.279 This slide is really just for Chris Morris. You want to mute it? Yes, I'm doing so well.

00:00:39.200 This talk is called 'Developers Are From Mars, Developers Are From Venus', and that's kind of a play on a self-help book that was available in the 90s when I worked at Barnes & Noble. The idea of the book was that 'Men Are From Mars and Women Are From Venus'. The idea was that men and women are very different; they think differently, etc.

00:00:53.280 So you can better understand your spouse, girlfriend, husband, or partner by understanding how they're different. That might be a whole bunch of schlock, but the underlying notion that we're all different and that there are ways we can think about each other to better get along and work together is a really rad idea.

00:01:14.439 So, this talk is kind of my journal of diagnosing myself as a jerk and trying to troubleshoot that code out of my manner. I realized several years ago that a lot of the problems I was facing as a developer were social problems rather than technical problems.

00:01:32.079 Working with some people and some developers just wasn't easy or possible for me because of personality conflicts or disagreements. I was lucky for the first several years of my career to work with people who had the sympathy or empathy to know how to work with me as a young upstart.

00:01:49.560 But eventually, that's not going to carry me through my whole career. I realized I had to level up my people skills.

00:02:00.560 The tricky part is that there's no read-me for people, and there's certainly no manual page. So I felt like I had to reverse engineer it myself. Luckily, there are a lot of books and non-schlocky self-help materials out there. I've tried to collect the things I figured out as I go; I blog about it a bit, I tweet about it, and here I am presenting about it.

00:02:40.640 As I grew into an elder-aged developer, I reached a point where I realized I was limited by who I could interact with and the kinds of situations I could successfully negotiate. I figured out basically that I could accomplish very little on my own, so I better get this teamwork and understanding people stuff together or else I was going to be stuck in the corner doing uninteresting things.

00:03:15.640 Once upon a time, I realized that everyone is different; not everyone is like me. For better or worse, I have to figure out when I meet someone, or when I'm interacting with someone, how to better communicate with and engage with their perspective.

00:03:34.720 So, I started debugging myself and reverse engineering those I work with because I can see what's going on in my head, but I don't know what's going on in theirs. It's a black box situation. And I tried to learn how to work with teams and communities that I'm a part of because every team and community is a little different, just like every person.

00:04:05.480 The headline things here are to know people in general, know yourself, know what your tendencies are, and practice empathy. The way I want to get started with this is by knowing people.

00:04:45.720 We all like to categorize things, putting them into buckets or pigeonholes. So, I have developed some character types of developers to help me get a rough idea of what is motivating or important to someone I might be working with in a team or community.

00:05:03.360 These are absolutely not science; these are just my observations. One or more of these caricatures may resonate with you, and one or more may be on your team or people you see at Ruby group meetings, conferences, or online.

00:05:39.360 The useful thing here is to recognize each character type and then learn how I can work most effectively with that character type. The first character type that I ever realized was different from me was the Grinders. Grinders are people who just hack out a bunch of code really quickly. They get features done snappily, push to production, and iterate rapidly.

00:06:19.519 These individuals are obsessed with getting new stuff out, experimenting with it, and seeing if it works. Their methods for getting software into production can often come across as cutthroat.

00:06:42.840 One grinder I worked with a few jobs ago would push updates nearly every 30 seconds, sometimes without even ensuring they were syntactically valid Ruby. He would type something in, say he thought it worked, deploy it, and then see on the server that something broke. As people on Twitter would comment about the issue, he would immediately make a fix and deploy it. This worked fine because our deploy process only took around 30 seconds.

00:07:11.479 However, this terrified me. I often wondered how that was working for him without writing any unit tests. The answer lies in his obsession with getting feedback and moving quickly. He made mistakes, but he also moved quickly to fix them. Grinders can be tempestuous; while they aren't aggressive like lions, they are not as contemplative as I tend to be.

00:07:39.000 So, the core question for me, as a more perfectionist-oriented developer, when working with a grinder is how can I explain to them why what I want to do is better than their current approach? How can I sell this individual on Test-Driven Development (TDD) or conducting A/B tests to improve their workflow for better outputs?

00:08:19.440 To assist them, I can suggest that by moving from a trial-and-error approach to TDD, they can receive a quicker feedback loop since it runs on their own machine without needing to deploy right away. I can say that by writing methods instead of cramming code into an action, they will leave room for later reuse and adjustments, which will make them faster in the long run.

00:08:54.720 Sometimes, they might say, 'Adam, that doesn't make any sense! I don't understand how I could write more code to go faster.' This creates a feedback loop where I can reflect on their response, considering their perspective.

00:09:14.880 They might eventually see it as beneficial when we discuss past mistakes they made, adjusting for improvement. I try to listen to them and respond if they mention that my software design isn't aiding their process. This highlights the collaborative nature of working with Grinders.

00:09:48.240 The next personality type I want to point out are the Tour Guides. These developers are invaluable for their deep understanding of code and the domain at hand. For instance, if you’re working on a legacy system, a Tour Guide can give you insightful explanations as to why the system works the way it does and how to navigate its complexities.

00:10:40.200 Tour Guides are often the veterans of a project, and they can explain the rationale behind certain coding choices. They know how to traverse through complexity, pinpointing necessary changes across systems. Their knowledge extends beyond a singular project; they often possess expertise in kernels, compilers, programming languages, distributed systems, and cryptography.

00:11:17.680 However, a challenge arises because Tour Guides are often overworked on critical projects. Ideally, their time should be split between tackling critical tasks and mentoring others on the system. A 50/50 split allows them to impart essential knowledge and skills to the rest of the team, an invaluable process.

00:11:54.880 If you have to consult a Tour Guide, always take notes to capture valuable information that can be shared further. This leads into the next character profile I’ve encountered, which I refer to as Geniuses.

00:12:38.040 Geniuses are the thinkers, sometimes prone to overthinking. Some Grinders may refer to them as 'architecture astronauts.' I personally have faced challenges with the urge to reinvent systems entirely instead of working within existing frameworks. Geniuses are committed to crafting high-quality systems that they can take pride in, always exploring various languages and libraries.

00:13:43.640 They tend to want to iterate on their vision of perfection. So collaborating with Geniuses requires humility: as someone more inclined towards quick iterations, I recognize I cannot simply halt progress. It becomes about guiding these developers to break down bigger visions into actionable steps.

00:14:36.960 The next type I come across are T-Shaped People. They are generally specialized in a specific area of skill development while having a broad understanding of other areas. This specialization creates an interesting dynamic when working with them; they might excel in one area while being only mediocre in others. Engaging with them requires some patience in areas where they don't shine and direct encouragement in areas where they do.

00:15:36.560 Now, let’s move on to Fun Leaders. These are individuals with amazing technical chops and people skills. They can listen to differing viewpoints, finding common ground to keep the team moving forward. They help bridge the gap between dogmatic figures and can catalyze the movement toward productive resolutions.

00:16:43.240 There is, however, the temptation to lean on them too heavily. While they can be key to diffusing conflicts, they also need time to focus on technical matters. If a team is overly reliant on them, then deeper issues within team dynamics might need to be addressed.

00:17:34.680 It's crucial for me to recognize my tendencies as I engage with others. There are moments when certain phrases can put me off, leading to defensiveness or frustration.

00:18:01.920 Learning to step back and handle these situations tactically is key. Understanding where I feel natural and where I struggle helps me navigate the social landscape. For example, sales negotiations are particularly daunting for me.

00:18:49.360 Additionally, I’ve learned to be patient with the tendencies of others. Recognizing that some people might engage in behaviors I find annoying is crucial. Sometimes, it's best to tolerate small irritations and then recalibrate to continue productive conversations.

00:19:43.919 The insights I’ve gained about various personality types, including those from Myers-Briggs assessments, help frame my understanding of how to communicate effectively across differences. Each personality trait has a place, and knowing where I stand prevents misunderstandings, particularly between introverts and extroverts.

00:21:07.240 More than anything, it's about building empathy—understanding others' pressures, goals, and needs, especially when interactions occur online where context is stripped away.

00:21:56.720 Two concepts I find useful are Hanlon's Razor and Occam's Razor. Hanlon's Razor suggests we assume ignorance rather than malice in others' actions, while Occam's Razor proposes we pick the simplest explanation over a complicated one. These frameworks help us avoid jumping to negative conclusions or complicating situations unnecessarily.

00:23:41.200 Moreover, in our tech communication style today, understanding emotional context is vital. It’s crucial to pause before expressing thoughts, considering how our words may be interpreted by others and what underlying messages they carry. Separating feelings from rational thoughts can lead to clearer dialogues.

00:25:41.760 Rejecting the conflation of social issues with technical problems is essential. While strengthening moderation or enforcing policies may help, we must also bear in mind that communities flourish with a balance of experienced individuals and newer members.

00:26:43.920 Ultimately, promoting empathetic interactions necessitates knowing ourselves and others while practicing kindness to create better communication experiences.

00:27:37.600 By actively engaging with colleagues, we can foster a supportive environment at work, whether by chatting with a barista or filtering out toxic dynamics in our social networks. Having a friendly, understanding community starts with personal responsibility, and we should appreciate our progress along the journey.

00:29:59.040 In conclusion, everyone is unique, and by recognizing different character types, we can enhance collaboration and foster empathy in our interactions. My goal is to promote kindness and understanding within our community, reducing conflicts and improving overall experiences when working with others.

Big Ruby 2014