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.
