For those who don't know me, I'm autistic. Asperger's Syndrome to be precise. I've been a developer for the better part of a decade.

I didn't find out I was ASD until 19, and didn't reconcile with that until years later. These posts will be a combination of advice I've given to those who are like me, as well as a letter of sorts to my past self who could have used a lot of it.

I write these posts in the hopes that someone like me will find value in knowing a very simple and very important truth about ASD:

You are not alone, and you are loved.

RubyConf 2020

This post was given in talk form at RubyConf 2020 and you can find the recording here:

https://www.youtube.com/watch?v=rEeCeJv_H28

The Expert

Expertise is really hard to quantify, what exactly is it? Can it even be measured? Not really, but at the same time we have some ideas on what its' path might look like and what those who are well along that path might start to look like. It's a state in which you exceed in a field, stand as an authority, a source of knowledge and an inspiration to those around you.

For someone with autism and a particular obsessive streak expertise feels like a natural evolution. After all, it's just going further down that infinite path of knowledge and wisdom, isn't it?

Well that's the problem. Expertise, and its pursuit, are perhaps the most dangerous parts of an autistic person's career, if not any person's career. Dangers which can make a person substantially more toxic to a workplace, and likely to rot out everything around them. It would be no exaggeration to say that one who pursues it with ill-intent can ruin an entire company.

So where does that leave us with this post? What exactly do I intend to cover today?



I'm going to tell you a story. My story. These are my stories around expertise, how I've failed in its pursuit, how I've pursued it for impure reasons, how I've in some parts achieved it, and how I've learned to apply these lessons to my work. Perhaps your story might look a bit different, everyone has a story all their own, but I hope these stories will help you find your own path.

Who Am I?

Currently my path has lead me to work at Square. At close to a decade of experience I've worked at several companies large and small, each with their own lessons, some of which lessons on what not to do in the future.

My current job at Square has me working as an organizational leader across Platform and Infrastructure Engineering, working to lead our Ruby community on topics such as language standards, education, architecture, and a gamut of other topics.

As to how I went from being positively disorganized and unable to function executively to roles beyond a senior engineer, well that's a story for another post like this one.

This story is about expertise, so let's get started.

The Title Which Must Not Be Taken

Now to be absolutely clear I do not like to call myself an expert, not in the slightest. I appreciate the irony in this as I write a post on the nature of expertise, but I want you to see from my perspective why I dislike calling myself as such.

You see, in the Ruby community there's an abundance of experts, people of true talent far beyond where I see myself. People like Matz,Penelope Phippen, Betsy Haibel, Aaron Patterson, Soutaro Matsumoto, Eileen Uchitelle, Noah Gibbs, and so many more. I could likely spend my entire talk going through a list of such people, but you get the point.

There are a lot of people who know a heck of a lot more Ruby than I do, and you know what?

That's exciting!

It means that no matter what I learn there's always going to be someone who knows more, and because of that so much further I can go in my own path.

So let's start with a story. When I started in the Platform and Infrastructure Engineering organization at Square I was greeted by one of the Directors who exclaimed "So you're the Ruby expert!"

You remember that bit about me being particularly touchy about that title? In that moment I went through every reason why that was wrong and why I had no business taking that title, but I chose to let it be.

It's this thing called taking a compliment, and I am absolutely horrid at it.

I reached out to others afterwards and talked it through with them, one of which started laughing and exclaimed "If you're not a Ruby expert then God help the rest of us!"

In many ways I was refusing to accept how others saw me both at work and in the industry, and in some ways undermined their faith in my abilities. Imposter syndrome likely played no small part in this, but that said it was getting in the way of me working effectively and leveraging my skills to help others.

Now in my head I still believe I won't ever truly live up to or deserve that title, and I may never. Sure, when I was about five or ten years younger I would have gladly accepted, but a decade of programming has if anything highlighted just how little I truly know.

Where I may be an expert in some fields of Ruby I'm absolutely clueless in others.

Now this talk isn't meant to be a lamentation on whether I'm an expert. It's a reflection on a few of the archetypes of expertise I'd embodied on my journey, the mistakes I'd made in their pursuit, the damage I'd caused along the way, and how I've finally in some small part matured to use them more effectively.

There's still a lot of growing I need to do, and very likely future me will see the current me as abundantly foolish as well. In the meantime, however, I will do the best I can with the time I have. Naturally I'm very harsh on myself, but I believe this is absolutely necessary for growth, especially as I'm trusted with more power and responsibility.

While the solutions I may offer sound simple or be presented as such they are the result of years, and often times the simplest of answers are the hardest to learn. It certainly is in my case.

With that, let's take a look into some of the archetypes of expertise along my path, and the stories that came from them.

Heroism - The Savior to Everything

Our first archetype is the hero.

A hero is someone who saves the day, who fights against impossible odds and manages to come out the victor no matter what may happen. Even in the most dire of 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. For me, early in my journey to expertise, I fancied myself one of these heroes who could solve any problem.

It got me into a significant amount of trouble.

The Weakness

By positioning myself as the hero I had isolated more junior engineers from taking on tasks that would have helped them grow as engineers, simply because I was interested in them.

Their growth was hampered because of my pride and greed, and my inability to work through others. Instead I would give them the work I detested or found less valuable and showy. As a result I could have cost them the potential to be promoted much earlier in their careers.

I had to be seen, to be known, to be the most visible bright star in the night sky. I had to do it alone, and prove myself at every turn.

This pride was what led to my downfall on several teams, as there would always be a problem beyond me that I was too proud to ask for help on. After all, I was the hero, and I could take on the world. Right?

It also meant that when I left all the knowledge I had accumulated from years of solo work went with me, and a wake of destruction would soon follow as others had to clean up my unknowable mess.

The Solution

So how did I recover from that? What was the secret that saved me from that toxic mainframe?

It's this: Programming is not a solo journey. It never was, and never will be.

There is a wall that, no matter how talented or special you are, you will find yourself staring down. It's a wall which can never be overcome by yourself. An insurmountable mountain for those walking the solo path, and one that will never be conquered for all the self-help books, thought leaders, blog posts, or anything else in the world.

So how does one overcome such an obstacle?

The secret to programming is quite simple in the end: others.

Stepping back I'd learned to see the value in others, in their experiences, in the unique insights which make them who they are. I learned to value those I worked with more and wanted to invest in them, to see them grow and reach that potential. I'd also recognized that often times recognizing that potential was as simple as a push in the right direction. The people around you know so much more than you would ever think unless you take the time to talk.

We grow together, not alone.

Perhaps ironically the more skilled a solo programmer the later they find this wall, and the more damaging colliding with it will be. Those who learn to work together early will inevitably outpace even the fastest solo developer in time.

The Strength

Does that mean that heroics are always bad? Not necessarily.

Some of the greatest heroes in the Ruby community are those who inspire us to go beyond what we currently know, that show us what's possible, and give new insight into what we thought we've already learned.

A true hero is an inspiration, a beacon that lights the morale of those around them. They're the firm leader in uncertain times, the captain in uncharted waters, and the guide through the labyrinth of engineering. Just knowing they're with you and supporting you, you feel like so much more is possible, and in doing so break your own limits and grow as an engineer.

A true hero in programming is a leader that brings those around them to a new level of understanding, and through them also levels up themselves. Such a programmer is an excellent tech lead, and a valuable member of any team.

The Discerner

Our second archetype is the discerner.

A discerning expert is able to grasp problems at a glance, find critical flaws in otherwise benign code, and deliver insights that dramatically improve the code around them. They can see what others may miss, and in doing so are a guardian against a myriad of pitfalls down the road.

They can also heavily abuse this to destroy the morale of their teams.

Weakness

In my own career I'd started to develop an ability to see all types of issues with code, to be able to know with a glance all forms of potential improvements to code. Unfortunately for my coworkers this took the form of something I consider now to be extremely damaging: code style.

Hours were spent on code reviews nitpicking the smallest of details of code on things that quite frankly did not matter. If code did not follow an exacting standard of what I believed to be correct I would raise all hell about it. I'd focused the entirety of my attention on things that were irrelevant.

This blocked so many code reviews and instilled a sense of fear and distrust in having me as a reviewer. I wasn't delivering insight, I was bullying others with my opinions, and missed the much wider picture of very real issues which compromised the integrity of the code I was reviewing.

I could find fifty stylistic and code formatting issues, naming conventions, or other such things, but would miss N+1 queries, injection potentials, O(n^2) loops, or far worse: architectural problems.

Because of my personality this was also used to belittle others knowledge. After all, they didn't know the language, and I would take a smug satisfaction out of this. It was my goal to prove I knew more through these petty comments and critiques, and in doing so I certainly made no friends.

Solution

So how does one improve from this?

This will be controversial, but I want you all to hear this:

Code style does not matter

Pick a linter / formatter, and only one with an autocorrect feature, and let it do the work. Stylistic nitpicks have no place in code reviews and should be relegated to tools. They are at best a measure of uniformity and at worst a severe distraction from what truly matters. Engineers should train to see larger issues, not nitpicks.

Code reviews, and the ability to see issues, should be utilized to teach and guide rather than to tell. People are allowed to make mistakes, and are required to do so to grow. I certainly make several. The point of calling out a mistake is to only do so when the mistake would cause them or others harm.

A wise friend once introduced me to a concept of "blast radius", in which they would allow failure at certain levels dependent on the impact it would cause to create learning opportunities. Sometimes the learning opportunity is you were wrong and the lesson is humility.

Strength

What does that mean for the strengths of the discerner?

There is a great strength with having clear insight and the ability to spot severe issues at a glance. It's a skill cultivated from years of raw experience and familiarity with systems, and it provides a level of clarity that is critical to the success of larger projects.

When used at the scope of a very senior engineer this ability can be used to charter product roadmaps, adjust velocity, spot critical elements missing from the equation, influence senior leadership to the future of teams, and so much more.

It is a skill that inspires confidence.

Those skills were pivotal in two of my promotions at my current job. It was spotting gaps that others had missed, and being able to bring together a plan to deal with them. It was the ability to predict future peril before it escalated to a point of severity, the ability to wrap those insights into actionable content and finally deliver on them that led me to more senior roles.

That insight also allows you to see the potential in others and help them grow.

The discerner is an architect for mature applications through and through, and the person you want triple checking blue prints before you start refactoring large parts of the application or breaking apart a monolith.

The Creator

Our third archetype is the creator.

The creator is an expert that can build almost anything they set their minds to at a pace that others might find impossible. They can take a problem and give you an immediate solution and a way to get there, build a team, and grow something from the ground up.

The problem is there's more to building a site than a weekend hack and an abundance of arrogance.

Weakness

Earlier in my career I would see things as trivial, easy tasks, that could be done in a matter of hours rather than days. Why, then, did it take people so long to finish those types of tasks?

It was a constant source of frustration, and was a projection of my idea of what was necessary to deliver a feature.

The problem was that my interpretations of the requirements were wholly uninformed, and missed several critical insights that would have collapsed my design. It was a lack of empathy and communication with those around me that led me to severely underestimate the difficulties and true struggles behind each feature.

By believing that I could not only build the same thing by myself, but substantially faster, I was creating an exceptionally hostile environment. In some cases I may have been right, but that also discounted the need of newer engineers to grow at their own pace without my assumptions on pace. In other cases I was absolutely wrong, and in doing so had forced others to cut corners to deliver on impossible timeframes, setting up the team for failure and inevitable burnout.

Solution

How does one, then, overcome these issues?

Sure, some things could be done faster, but was it truly necessary? By stepping back and listening, pace could be more easily regulated. Speed is not the only factor that's important in the construction of software.

By focusing on how fast something could be done I'd failed to account for the multitude of contingent factors, and had focused on a scope that was not wise for me to pursue.

The secret here is trust. Trusting in those around you to tell you the problems they encounter, and creating an environment in which they feel comfortable to confide such things in you.

By creating such an environment you can have honest discussions about issues that are encountered, and when necessary, help to guide engineers back onto track with insights and questions. Often times you may well learn something from the discussion as well.

This harkens back to the points on programming not being a solo effort. While I could do a few things faster there's always a wall, and if one obsesses over how fast they could build a chair they'll fail to remember they need to build an entire house around it.

Now it should be noted that trust is not free, and not all act with good intentions. Some may well take advantage of this, and expertise in this area is knowing the difference between the two.

Strength

What are the strengths of the creator?

Much like the Discerner this ability allows one to iterate through many possibilities. The difference is that the creator is concerned with construction, even if they never finalize and perform on it. That means that you can provide insights to those who are blocked on certain tasks and help find solutions to get them moving again.

It's the ability to grasp work you're not directly involved in quickly due to the ability to figure out how you yourself might approach the problem, and further strengthened by the ability to understand how another may approach the same problem. The ability to not only have these insights but communicate your thinking process to your team can be a significant benefit.

When I started to learn this I became substantially more productive as I learned to trust those around me, and when required I was able to leverage this knowledge to take care of difficult problems together with them.

Your coworkers are smart, programming is hard, and they got here all the same. That's really something incredible.

It also gave me the ability to warn them of potential pitfalls and things to be watch in certain tasks and expedite their learning curves.

The creator is a dream for greenfield projects who need a seasoned hand to guide their growth into maturity. If you have a new product to ship you want one of these people on your team.

The Authority

Our final archetype is the authority.

The authority is the voice of seasoned expertise on a subject, a reliable source that can answer about any question you could think of, and even if they can't they're able to find that answer in a matter of minutes. They're the accumulation of years of refined and distilled knowledge.

They can also be incredibly arrogant and confuse opinion with truth and fact, and become some of the worst bullies on a team.

Weakness

The problem with believing yourself to be an authority is that you have no wrong opinions. What you say is law, and those who fail to listen are foolish.

For me this became a tool to bludgeon others into submission on what I believed to be correct without fully understanding their concerns or feelings on matters. It became an issue where I would see myself as the sole arbiter of truth in my field of expertise, everyone else was wrong.

I cannot begin to tell you how toxic this mentality is.

Because of this so many potentially brilliant ideas and considerations were crushed and ignored, and the people that had them were shut out. This lack of humility led to several bugs, issues, and other major structural issues in my code that could have been prevented.

The desire to be right and never show weakness or wrongness is one of the most dangerous things a programmer can do, because you will most certainly be wrong, and you will most certainly fail no matter how smart you are.

Those who place themselves atop the highest ivory towers will fall the hardest when the tower collapses under the weight of their arrogance and pride.

Solution

So what's the solution to this arrogance?

The solution is to stop talking and listen.

This required a lot of growing on my part. For as much as I'd thought I knew there were swaths of programming that I had absolutely no knowledge of.

There's always something to learn, no matter who you're talking to. Granted perhaps that lesson is what not to do.

By stopping and listening I've learned far more than I ever would have by talking through an entire meeting. I'd learned to ask questions, to seek, to learn, and to appreciate the strengths of my coworkers in ways I never had when I was busy running my mouth.

Asking questions became a way to reframe rants and tirades into concentrated points and clarifications that delivered substantially more value and insight to problems. Sometimes those questions were genuine curiosity, sometimes they were meant to identify potential gaps, and sometimes it was best just to sit back and listen.

Strength

Being an authority on a subject means you have a lot to share, and that you can be a guiding force for those learning. It also means that you can condense these insights into simple answers and questions that will potentially lead to enlightenment and growth of your coworkers, or perhaps even yourself.

Through education and teaching the authority can prevent bugs and issues before they even catch the attention of a discerner. They establish a foundation of knowledge by which the productivity of an entire company can be multiplied several times over.

They can also speak to the most difficult issues your company may face and find answers where before there were none. Much like the hero they can help to overcome issues that were otherwise thought to be impossible.

The authority is a teacher and a mentor, and one capable of growing and leveling up all of those around them. Companies with several new engineers onboarding will find great value in an authority and their ability to explain the complex in simple terms.

Wrapping Up

Now this brings us to the end, and there are a few thoughts I would like to leave you with.

The Dangers

The first is the dangers of seeking expertise.

Expertise can be exceptionally dangerous, and can lead to some of the most toxic coworkers if pursued with ill-intent. A single rogue developer seeking expertise can destroy teams, organizations, and even companies if left to their own devices.

One needs to recognize the potential dangers and areas of growth that are necessary to become an expert to do so in a healthy manner, and also to recognize those who have failed to do so.

The Range of Expertise

The second is on the wide range of expertise

It should be noted that there are several types of experts, and even among experts people rely on each other! I most certainly don't have the faintest idea how to write C-extensions, contribute directly to Ruby, or whole other swaths of fields and likely won't for years to come. That said I know several people I respect who are exceptionally good at all of those, and they've been amazing friends and coworkers.

Interestingly enough, being able to discern these traits in others is in and of itself a field of expertise and one of immense value.

The Potential Value

The third is the value an expert can provide.

While there are indeed dangers, experts are some of the most valuable people in our companies and our communities. They're a constant source of inspiration, learning, and innovation. They drive the edges of the industry to new territory, and show us a glimpse of what may be possible. They can condense years of knowledge into clear answers.

When used wisely, an expert is a force multiplier several times over, but that expertise must be used responsibly.

It's Never a Solo Effort

The last is that programming is Never a Solo Effort

Programming has never been, and will never be, a solo effort. We work with others, no matter the level, no matter the knowledge, to build things beyond ourselves. That's one of the most fascinating things about it.

I am the cumulative result of the thousands if not tens of thousands that have invested in me, from school to my current job, to make me what I am today.

I'm not self-made man, and quite frankly there is no such thing. No, I'm community-made man, and for that I will be eternally grateful to everyone around me.

But gratefulness is not merely accepting the investment of others, but reinvesting your knowledge, time, finances, and everything you are into building the next generation.

That's what it means to live in a community, to be a true expert, and Ruby is one of the best communities out there.

The End

This has been a difficult post to write, like many I have written in the past, as I've had to confront the man I was in the past to become the man I wish to be in the future.

I'm not now and nor will I ever be done growing. In the past that was a terrifying thought, but now I see it as a beautiful thing. A new path that will ever be in front of me, and an infinite amount of knowledge to learn, new friends to laugh with, cry with, celebrate with, and live with.

To the future beyond these dark days we find ourselves in I see hope, I see growth, and I see each and every single one of you working to find your own path to expertise and knowledge. I sincerely hope you find what you're looking for on your own path.

So am I an expert?

Well that's up for you to decide. I'm merely a fool with a lifetime of work ahead of me, and so much more to learn.

Now go out and be amazing, because you know what?

I believe in you.