Tales of the Autistic Developer: The Expert

by Brandon Weaver

In his talk titled "Tales of the Autistic Developer: The Expert" at RubyConf 2020, Brandon Weaver explores the nuanced concept of expertise, especially through the lens of his personal experiences as an autistic individual in the tech industry. He reflects on how autism can impact the pursuit of expertise, presenting both its natural evolution and potential dangers.

Key points discussed include:

- Definition of Expertise: Weaver describes expertise as a state where one exceeds in a field, becoming an authority and source of inspiration. However, he warns that this pursuit can lead to toxic workplace dynamics if mishandled.

- Personal Journey: He shares his experiences with ADHD and autism, which he discovered at age 19, and how these have shaped his self-perception and professional growth. He emphasizes the importance of self-acceptance in your professional life.

- Archetypes of Expertise: Weaver presents four archetypes he has encountered or embodied:

- The Hero: Described as someone who aims to save the day but can isolate others and create a toxic environment.

- The Discerner: Recognizes critical flaws in projects but can tend to nitpick minor details, leading to negative dynamics during code reviews.

- The Creator: Builds solutions rapidly but may lack empathy towards colleagues who require more time for development.

- The Authority: Holds significant knowledge but risks becoming arrogant, disregarding the contributions of others.

- Substantial Growth Experiences: He reflects on evolving from a ‘hero’ mentality that stifled collaboration to recognizing the value of teamwork and mentorship.

- Conclusion and Takeaways: Weaver warns that while expertise can drive organizational innovation, it can also endanger teams if pursued without humility. He stresses that programming is a communal effort and expresses gratitude towards those who have supported his journey.

Brandon invites listeners to consider their paths toward expertise, concluding that expertise should be a shared journey that enriches the entire community.

00:00:07.440 Well, here we are, okay friends. We are already a couple of hours into RubyConf 2020. I mean, this is wild! I know that for many of you who are on the other side of the planet watching this at like 2 a.m., you're probably getting a little tired. So, if you haven't had the chance, take a look at the activity video that I just posted to get some blood flowing and stay engaged. As a reminder, all of these are being recorded, so you're welcome to watch those after the fact. But let's get started.

00:00:30.880 So, who do we've got coming up right now? It's somebody that I've seen talk a few different times and has participated in an event I helped run last year. He is very engaging, and I hope that you're going to find his gloriously well-prepared presentation captivating and resonant. Without further ado, let me introduce Brandon Weaver. Oh, thanks for the intro! Well, I asked what I should wear today, and they said, "Do whatever suits you," so I did!

00:01:14.479 Anyway, jokes aside, let's go ahead and get into it. Hello there, everyone from RubyConf! We're about ready to get started. My talk is part of a series called "The Tales of the Autistic Developer." This particular story is called "The Expert." Now, what exactly is expertise?

00:01:32.720 It's really hard to quantify; it can be measured, but not easily. We do have some ideas about what its path might look like and what those who are further along that path might start to become. Expertise is a state in which you exceed in a field and become an authority, a source of knowledge, and an inspiration to those around you. For someone with autism, in particular, who is obsessed with their interests, expertise feels like a natural evolution, a further journey down that path to infinite knowledge and wisdom.

00:02:04.240 However, that’s where the problem lies. The pursuit of expertise can be the most dangerous part of an autistic person’s career, if not anyone’s career. It can create a situation where a person becomes substantially more toxic to the workplace and could potentially ruin everything around them. In fact, it would be no exaggeration to say that someone pursuing expertise with ill intent can cause significant harm to an entire company.

00:02:39.519 So, where does that leave us with this talk? What exactly do I intend to cover today? I’m here to tell you my story—my journey surrounding expertise. I will discuss how I've failed in its pursuit, how I’ve pursued it with pure intentions in the past, how I might have achieved it in some areas, and how I've learned to apply those lessons to my work.

00:03:14.560 Perhaps your stories might look a little bit different. After all, everyone has their own experiences, but I hope that these stories will help guide you along your own path.

00:03:39.200 To start with, who exactly am I? What makes me the person to talk to you about a subject like this? Well, dear audience, I'm autistic and have ADHD. It's something I discovered at the age of 19, and I've spent the last decade learning to accept it. Quite frankly, I’m still working on that. It has caused me innumerable struggles in my adult life but has also granted me many valuable lessons and experiences along the way—experiences I share in hopes that they help someone out there someday to find a way to love themselves for who and what they are.

00:04:22.639 Currently, my path has led me to work at Square. With close to a decade of experience, I've worked at several companies, large and small, each offering their own lessons. Some of these experiences even taught me what not to do in the future. At Square, I work as an organizational leader across platform and infrastructure engineering, focusing on topics such as Ruby community language standards, education, architecture, and a gamut of other topics.

00:05:02.080 Now, how did I go from being a positively disorganized person who could barely function, to a senior engineer? Well, that’s a story for another day. No, this talk is about expertise. So let's get started!

00:05:56.800 To be absolutely clear, I don’t like to call myself an expert—not in the slightest. I recognize the irony in giving a talk about the nature of expertise, but I want you to see from my perspective why I dislike calling myself that. In the Ruby community, there are so many experts—people with true talent far beyond where I see myself. Individuals like Matt, Penelope, Betsy, Aaron, Satoru, Eileen, Noah, and so many more. I could spend this entire talk listing their names, but you get my point—there are many people who know much more about Ruby than I do.

00:06:42.240 And you know what? That’s exciting! It means that no matter how much I learn, there will always be someone who knows more, which offers me the chance to further my own path. So let's begin with a story. When I started in platform and infrastructure engineering, one of the directors cheerfully exclaimed that I was "the Ruby expert." You remember that bit about me being somewhat touchy about that title? Well, in that moment, every reason why that title was wrong flooded through my mind, and I felt I had no business accepting it.

00:07:38.560 But I chose to let it go; it's called taking a compliment. Quite frankly, I’m horrible at accepting compliments. I reached out to others afterwards and talked it through with them.

00:07:49.840 I expressed my concerns, shared my feelings, and one dear friend started laughing. He said, "If you're not a Ruby expert, then God help the rest of us." That really touched me; it meant a lot in many ways. I realized I was refusing to accept how others saw me, both at work and in the industry, which undermined their faith in my abilities and my own self-belief.

00:08:00.000 Imposter syndrome likely played a role in this, but it was getting in the way of my effectiveness and my ability to leverage my skills to truly help others. In my head, I still believe I will never truly live up to that title, and that’s okay. Perhaps ten years ago, I would have gladly accepted it, but a decade of programming has highlighted just how little I truly know. While I might be an expert in Ruby, I’m hopelessly clueless in other areas.

00:08:46.319 This talk isn't meant to lament whether or not I'm an expert; it’s a reflection on a few archetypes of expertise I've embodied and witnessed on my journey, the mistakes I've made in their pursuit, the damage caused along the way, and how I've begun to mature and use these insights more effectively. There’s still a lot of growing I need to do, and it’s likely future me will see current me as abundantly foolish. But in the meantime, I'll do the best I can with what I have.

00:09:12.160 I will be critical of myself, of course, but I believe that’s necessary for growth—to hold myself accountable for all my actions, especially as I’m trusted with more power and responsibility. The solutions I offer might sound simple or be presented as such, but they are the results of years of wisdom from others and my own journey. Oftentimes, the simplest answers are the hardest to learn; it took me a decade to learn half of them, and it may take the next two or three decades to truly embody them.

00:10:14.880 Now, let’s take a look at some of the archetypes of expertise I’ve encountered on my path and the stories that came from them.

00:10:34.800 We’ll start with the first archetype: the Hero. A hero is someone who saves the day, fights against impossible odds, and comes out victorious no matter the circumstances. Even in dire situations, if you look to the sky, the hero will be there with a smile on their face, and somehow you just know everything will be alright. Early in my journey, I fancied myself one of these heroes, believing I could solve any problem. Unfortunately, that perspective got me into a lot of trouble.

00:11:25.760 By positioning myself as a hero, I isolated more junior engineers from taking tasks that would have aided their growth simply because I was interested in their development. Their growth was hampered because of my pride, greed, and my inability to work alongside others. Instead, I gave them the work I detested or considered less valuable, which could have helped them advance in their careers. I felt I had to be seen as the brightest star in the night sky and to prove myself at every turn.

00:12:10.240 However, that pride led to my downfall on several teams, as I was often faced with problems beyond my capacity to solve—too proud to ask for help. I was the hero; I could take on the world! This also meant that when I left, all the knowledge I accumulated from years of solitary work went with me, leaving a trail of destruction as others had to clean up the unmaintainable mess.

00:13:21.200 So, how did I recover? What saved me from that toxic mind frame? The realization that programming is not a solo journey; it never was and never will be. There is a wall that, no matter how talented you are, you will find yourself staring down—an insurmountable mountain for those walking the solo path. You cannot overcome it alone, despite what self-help books or thought leaders may suggest.

00:14:22.080 The secret to programming lies in collaboration. I learned to see the value in others and their unique insights. I learned to invest in my colleagues' growth and recognize that sometimes, all it takes to help someone reach their potential is a gentle push in the right direction. The people around you know so much more than you might think if you take the time to understand their strengths. We grow together, not alone.

00:15:08.240 Perhaps ironically, the more skilled a solo programmer, the later they realize they have reached this wall. The collision with reality when they do can be damaging. Those who learn to collaborate early on will undoubtedly outpace even the fastest solo developer over time. But does this mean that heroics are inherently bad?

00:15:55.520 Not really. Some of the greatest heroes in the Ruby community inspire us to surpass what we currently know, showing us what's possible and offering new insights into what we thought we already learned. A true hero is a source of inspiration—a beacon that lifts the morale of those around them. They are the steady leader in uncertain times, a captain in uncharted waters, and a guide through the labyrinth of engineering.

00:16:36.640 Just knowing they are there supporting you makes you feel like you can achieve so much more, breaking your own limits and growing as an engineer. A true hero in programming is a leader who elevates those around them to a new level, ultimately leveling themselves up as well. Such a programmer can excel as a tech lead and be a valuable asset to any team.

00:17:53.600 Now, let’s move on to our next archetype—the Discerner. A discerning expert grasps problems at a glance, unearthing critical flaws that others might miss. They deliver insights that dramatically improve the environment around them and act as guardians against potential pitfalls.

00:18:15.440 In my career, I developed the ability to see a variety of issues with code, instantly recognizing improvements or optimizations. Unfortunately for my colleagues, this often manifested as nitpicking code style. I spent hours, days, and weeks on code reviews, scrutinizing the minutiae that ultimately did not matter. I focused entirely on microscopic details and ignored larger, more critical issues. This not only blocked many code reviews but also instilled a sense of fear and distrust in having me as a reviewer.

00:19:02.399 Rather than providing constructive insights, I bullied others with my opinions and failed to recognize significant problems that compromised code integrity. I could identify countless stylistic or formatting issues but missed major architectural and security flaws like critical architectural issues, SQL injection vulnerabilities, and more. My personality often belittled others’ knowledge because they didn’t know as much as I did, finding some smug satisfaction in proving my superiority through petty critiques, which has certainly not blessed me with friends.

00:20:02.560 So, how does one improve on this? This may be controversial, but I want everyone to hear this: code style doesn’t matter. Pick a linter or formatter with an autocorrect feature and let it handle the stylistic issues. Code style should be relegated to tools; they are at best a measure of uniformity and, at worst, a distraction.

00:20:51.920 Engineers should focus on larger issues, not the microscopic nitpicks. Code reviews should be utilized to teach and guide, allowing room for others to make mistakes. After all, we all learn from failure. A wise friend introduced me to the concept of blast radius, suggesting that failures should be allowed at certain levels depending on the impact they would have, which creates learning opportunities.

00:21:31.280 There is great strength in having clear insight and the ability to spot problems at a glance. This skill is cultivated from years of experience and provides a level of clarity critical to the success of larger projects. It empowers a senior engineer to steer product roadmaps, adjust velocity, and highlight gaps. My abilities in this area were instrumental in two promotions at my current job. It was my ability to spot gaps others had missed and subsequently plan ways to address them that led me to more senior roles.

00:22:51.040 Conversely, this insight allows you to see the potential in others and help them grow. The Discerner is a cornerstone for a mature application; they're the individual you want double-checking the blueprints before embarking on major refactoring efforts.

00:23:12.480 Now, let's transition to our third archetype: the Creator. A Creator is an expert capable of constructing almost anything imaginable if they set their minds to it, often at a pace others might find absurd. They take a problem and provide an immediate solution, building a team and growing something from the ground up.

00:23:48.560 The issue is that there is more to building a site than a weekend hack and an abundance of arrogance. Early in my career, I would see trivial tasks as easy to accomplish in mere hours, failing to understand why others took longer to finish. This frustration stemmed from a lack of empathy in communication regarding the true struggles behind each feature. I believed I could create the same solution, and faster, resulting in a hostile environment. While it may have been possible to finish the work sooner, that mindset disregarded the need for newer engineers to grow at their own pace.

00:24:51.679 In some instances, I may have been correct about the speed but forced others to make rushed compromises, leading to inevitable failure and burnout. So, how do we overcome these issues? I realized that while things might be done faster, that doesn't always need to be the case. By stepping back and listening, I foundpace could be more easily regulated. Speed is not the only factor; focusing solely on how quickly something may be completed causes omission of various contributing factors and distracts from meaningful scope.

00:25:40.960 The secret here is trust—trusting those around you to express problems they encounter and create an environment where they feel comfortable doing so. This openness facilitates honest discussions about challenges and allows you to help guide engineers back on track with insights and questions. And often, you might learn something valuable from those conversations, illustrating the principle that programming is not a solo effort.

00:26:35.520 Even though I could accomplish a few tasks more quickly, there will always be that wall, inhibiting solo endeavors. If one becomes too fixated on how quick they can execute tasks, they risk forgetting the larger vision of creating an entire house around the chair.

00:27:09.760 It’s worth mentioning that trust isn't freely bestowed, and not everyone operates with good intentions. Some may take advantage of trust. Expertise, in some cases, is knowing the difference between the two.

00:27:52.640 So, what are the strengths of the Creator? Much like the Discerner, the ability to iterate over various possibilities is paramount. The Creator emphasizes initial construction, even if they cannot finalize tasks. This strength enables them to provide insights to those blocked by difficult tasks, assisting them to advance.

00:28:33.200 They can grasp work they're not directly involved in or onboard quickly, figuring out how they might approach a problem. The ability to comprehend how others might tackle similar problems, coupled with the skill to communicate thought processes effectively, can bring tremendous benefits. When I started applying these skills, my productivity soared as I learned to trust and support those around me. This approach could also help alert team members to potential pitfalls.

00:29:16.560 Finally, we come to our last archetype: the Authority. The Authority is a voice of seasoned expertise on a particular subject—a reliable source who can answer virtually any question you could conceive. Even if they don't have an immediate answer, they can usually find it in a matter of minutes.

00:29:54.160 They represent years of distilled knowledge; however, they can also be exceedingly arrogant, confusing opinion with truth. This overconfidence can lead to some of the most toxic team dynamics. The problem with believing you are an authority is that you end up with a mindset of having no wrong opinions. What you say is treated as law. Anyone who doesn't comply is deemed foolish. For me, this resulted in my leveraging that position to strong-arm others into submission regarding what I deemed correct without fully understanding their concerns.

00:30:46.000 This toxic mentality crushes potentially brilliant ideas and shuts out those who may be equally or more knowledgeable. My lack of humility led to numerous bugs and serious structural issues in my code—issues that could have been avoided had I merely listened to others. The desire to feel right and never exhibit any weaknesses is a perilous mindset in programming, where failure is an inevitable part of the journey.

00:31:33.360 As we wrap up, here are a few thoughts I'd like to leave you with today. First, the dangers of pursuing expertise can be quite grave, leading to toxic dynamics in the workplace. A rogue developer seeking expertise can obliterate teams, organizations, and even whole companies if allowed to operate unchecked. It's essential to recognize the risks involved and ensure a healthy approach to growth in expertise.

00:31:55.760 Secondly, there exists a wide range of expertise. It's crucial to understand that even among experts, people rely on each other. I certainly don't know how to write a C extension, contribute directly to Ruby, or grasp a myriad of other fields.

00:32:28.480 Interestingly, the ability to discern others’ expertise is a field of immense value in its own right. Third, while experts can be dangerous, they also represent some of the most valuable assets within our companies and communities. They drive innovation and push the boundaries of industry knowledge, providing often crucial insights.

00:32:51.920 Thus, when utilized responsibly, the expert is a force multiplier. However, if mismanaged, that multiplier may yield negative results.

00:33:16.160 Lastly, programming is never a solo effort. We collaborate with others, regardless of our own knowledge level, to accomplish extraordinary things. I am the culmination of thousands—if not tens of thousands—of people who invested in me throughout my schooling and career.

00:34:09.080 I'm not a self-made individual; there's truly no such thing. I am a community-made man. For that, I will be eternally grateful to everyone around me, and that gratitude is not just about receiving support—it's about reinvesting my knowledge, time, and resources into building the next generation.

00:34:44.560 This essence of community is what makes one a true expert—especially within the Ruby community, known for being one of the best out there. This talk has been challenging for me to write, as I have faced the man I once was to become the individual I aspire to be. But honestly, it has been worth it. I am neither done growing now nor will I ever completely finish this journey.

00:35:34.000 While that realization filled me with dread in the past, today I view it as a beautiful truth—a new path that will always lie ahead, filled with an infinite amount of knowledge to learn, new friends to share laughter and tears with, and a community to celebrate our journeys together.

00:36:15.760 So, to everyone, I see hope; I see growth, and I see each one of you striving to find your own path to expertise and knowledge.

00:36:40.000 I sincerely hope you discover what you’re looking for on your journey to that expertise. So, back to the initial question: Am I an expert? Well, honestly, that's up for you to decide. In the meantime, I’m merely a fool with a lifetime of work ahead of me and so much more to learn.

00:37:00.119 Now go out and be amazing, because you know what? I believe in you! I don’t have time for questions during this live session, but I would love to continue this discussion on the RubyConf slack channel titled "Tales of the Autistic Developer: The Expert." If you want to connect outside the conference or see what else I’m up to, feel free to reach out on any of these social networks.

00:37:30.160 One day soon, I imagine all the lemurs will be back for more illustrated talks, and I believe we will have some exciting topics to cover then. With that, I think it’s time to wrap up. Thank you so much for having me, and have an amazing conference!

00:38:00.560 Well Brandon, I really appreciate that talk; great job! That was wonderful and the sentiment here is reflective of what you've expressed. Thank you so much!

00:38:14.880 To everyone in the chat who is watching now, please head over to Slack and let’s move the conversation over there. We have a channel specifically for this discussion titled "Tales of the Autistic Developer: The Expert." So, if you're browsing channels, head over there.

00:38:28.160 If you have questions for Brandon, let’s move them there as well because we are effectively at time now. With that being said, friends, let’s keep moving on to the next talks scheduled for the day.

00:39:04.240 Please check the schedule for the upcoming presentations or workshops that you’d like to participate in. This community is only as vibrant as the conversations that happen here.

00:39:42.080 So, engage with one another as much as you can. Thank you again, Brandon, for that inspiring talk!