I am not a fan of the term “imposter syndrome.” It’s a lazy way of ignoring the complex and interconnected, often structural reasons that contribute to many people’s feelings, which manifests itself in a variety of deeply idiosyncratic ways. But I guess the tl;dr is that this is what this post is about.
I am not someone who has “hobbies” as such; I have interests that I adopt with great enthusiasm, pursue obsessively for a short period of time, often declaring that I have found a lifelong fascination, and then drop once the initial feeling of “endless possibility” has worn off and something else shiny and new finds it way across my path. I suppose my hobby is “pursuing novelty.” The 2022-2023 edition of this came in the form of tabletop role-playing games, and earlier this year, I found myself sitting with some good friends, beers and snacks, working out how my character, “Ach!”, a small goat with a fondness for fainting at inappropriate moments could make their way into a human party undetected.
The solution for Ach! and friends was to don a disguise and stand on each others’ shoulders, and this image of 3 goats in a raincoat trying to sneak into a human party perfectly reflects how I feel about myself sometimes as an open source maintainer.
(Here, I need to get round to commissioning an image of 3 goats in a raincoat standing on each other’s shoulders. The top one has black and red braids and is wearing a hat and fake beard/moustache)
I am the current maintainer of the arrow R package, which in reality just means I am the person who is listed as such in the package DESCRIPTION file, and have the responsibility of clicking the link in the confirmation email from CRAN when someone submits the latest version of of the package to CRAN. Of course, I do more than just this; I triage bugs, submit patches, review PRs, and occasionally implement new features, but so do other people. While for career-serving purposes, I can technically claim to be “the” maintainer of the package, honestly, I am “a” maintainer and part of a team. This isn’t always reflected in other people’s language, and results in weird moments where people say things to me like, “ah, you wrote arrow!” and I have to respond with, “I absolutely did not, though I did write a lot of the bindings for dplyr::across!”, a topic which subsequently interests me more than it does them.
The tyranny of “should”
I’ve spent much of this year suffering from the tyranny of “should” regarding my own knowledge and abilities, in a way that has been verging on ridiculous. A lot of it is the perfect storm of adjusting to new responsibility, the deeply unhelpful way in which my self-image when I was younger was built up around being “smart” and “knowing things”, and a knack for punching above my weight by being good at figuring out just enough about a topic to get shit done. I don’t know every single detail of object orientation in R, but I know enough to be able to create new bindings between C++ objects and R6 classes in the arrow R package and expose their methods via fields and active bindings. Despite having looked it up repeatedly over the past few years, I still cannot recall the difference between how things work with static and shared libraries, but I did manage to fix a bug requiring me to bump the version of the C++ date library that Arrow vendors, via inspecting old pull requests and helpful feedback I received on the PR I submitted.
It came to a head at this year’s posit::conf, where I had the privilege of co-teaching a workshop about Arrow with the wonderful Stephanie Hazlitt. We spent months preparing materials and practicing teaching to our laptop screens, but when the event itself rolled around, teaching it to a room just shy of 60 people was a different experience entirely. It was intimidating being in front of a room of eager learners, and any jokey asides I was usually capable of making went out of the window, and I just taught the materials fairly plainly, stumbling over my words a bit, and finding the moments of silence in the room as I was teaching pretty awful. Subsequent feedback from folks I trust enough to deliver at least some honesty alongside their validation has led me to conclude that the only person who really noticed or cared about this was me. I was doing my old trick of snatching defeat from the jaws of victory, and realised later that my self-expectations were totally unreasonable. While I used to be able to absolutely smash through delivering a well-practiced 2-day “introduction to R” course, and delighted in engaging the folks in the room and showing them what they (and R!) were capable of, it’s 5 years since I last did that on the regular. This was the first time these materials had seen the light of day, and at no less than posit::conf, daunting enough on its own. And honestly, this is all ego. We ran a good workshop, people were engaged, and we wrote some quality reusable materials. Yes, there’s room for improvement, but overall it was solid. Delivery of content is something I can (and will) work on. I’ve applied for The Carpentries instructor training, and have plans to get back into the swing of teaching by running workshops (on Arrow and other topics) at user events.
The power of “I don’t know but I can find out”
The second day of posit::conf was spent being a teaching assistant for the fantastic Andy Teucher, who was teaching “Fundamentals of Package Development”. I managed to escape a lot of this “should” nonsense here, so when one of the course attendees asked me about where to store CSV files to use in unit tests, I happily admitted I wasn’t sure but could find out, and together we had a look in “Writing R Packages”, where I couldn’t find the information, and then suggested the approach I usually take when working on arrow - look at what folks who often define best practices do in the packages that they maintain. We took a look at readr, found the files in the testthat directory, and concluded that unless there’s reason to want to do anything more complicated (like make those datasets available to end users), then that approach is fine. Not knowing the answer instantly wasn’t a hindrance to working out the necessary solution. Learning how to say “I don’t know, but let’s find out together” is one of the most important things I learned when I was first teaching people how to use R. A teacher doesn’t have to know everything, but should be able to help a learner find the information they need.
The power of community
The rest of the conference week was pretty awesome. I was in the middle of a CRAN resubmission (well, actually a re-re-resubmission, but let’s not go there) which had got a bit hairy, and I needed some help tracking down the source of the bug. I spent some time briefly engaging in a bit of pair programming with Jonathan Keane and Neal Richardson, who’ve both been involved with Arrow for a lot longer than me, and I’m always taken aback by just how quickly they both get to the source of a problem any time I ask for help. Part of my “knowledge anxiety” manifests as me sometimes taking longer than I would like to process things when communicating verbally about technical topics, which leads to me getting really frustrated when I’m just not “getting” things in the moment that I know later will seem pretty obvious and uncomplicated. This happened when we were looking at the arrow bug, but I had this sudden moment of clarity upon realising…nobody cared except me. Jon and Neal are great collaborators and are always happy to explain things again if there’s time, and aren’t going to judge me for it.
I also realised that there is no universal measure of what I should know or where I should be at. While I always want to know more about how things work, I don’t have to know everything and it’s a pretty unrealistic expectation for me to have of myself; sure I can (and often do!) go read a whole load of the codebase and related concepts, but that’ll never be the same as also leaning on other people’s years of experience and knowledge. The whole point of being part of a community is to be able to share both overlapping and divergent knowledge.
Progress is power
I don’t think there is a universal solution to this problem of feeling like you “should” know more, but all I know is what has worked for me. Public work is important - social media, blog posts, talks, workshops, whatever. It can be scaled to wherever you’re at. There’s always something you’ll be surprised that you know but others don’t. And it creates a lovely feedback loop whereby a little bit of external validation can go a long way.
Learning is also important - I did the first half of the Udacity C++ Nanodegree this year, and while a lot of what it taught me was that I never want to be a full-blown C++ developer (I’d rather make weird buildings and spaceships out of existing Lego pieces than become a polymer scientist just to create custom bricks), realising that I could learn C++ at that level if I really wanted to, was invaluable. Part of the course involved getting acquainted with cmake, and whilst I can’t claim expertise there, dabbling in a bit of the whats and whys helped make many related Arrow project issues seem less mystical.
Reassurance and validation are good and well, but in my experience, having tangible proof of the things that I do know is more effective.
“Fake it til you make it” is deeply problematic
The commonly received advice is “fake it ’til you make it”. Pretend you feel like you belong and are confident, until that becomes the case. I’ve spent a long time attempting this, and the problem is that it doesn’t actually work, because it doesn’t address the underlying issue. It’s only since I started to own the fact that I don’t feel comfortable in every environment or domain and working out what I need to do to feel more comfortable that I’ve felt my confidence growing.
In the past month, I’ve been a lot more open about how I’ve been feeling around this. It’s been tricky as I’ve been scared that my vulnerability just looks weakness that I shouldn’t show around other people, or just come off as moaning, but it’s had massive benefits. During the first couple of days of posit::conf this year, I suffered the worst ongoing anxiety I’ve had all year - I had a constant knot in my chest - but despite that managed to have a good time as everyone was very accepting. I can say without a doubt that pretending to be fine would have made things infinitely worse.
There was another point during the conference when I casually mentioning that I was feeling quite hopeful about a potential opportunity but not entirely sure if it was in the bag, as I suspected I might be up against someone whose background I find impressive. It was kindly pointed out to me that each of us bring different things to the table, a comment which has since set off a chain reaction of me starting to appreciate what I can do rather than what I can’t.
The cure for imposter syndrome
The most important thing I learned this year is that the cure for imposter syndrome isn’t persuading yourself that you aren’t just 3 goats in a raincoat pretending to be a person, but instead surrounding yourself with folks who wouldn’t really care if you were anyway because goats are cool and that’s a pretty awesome feat of acrobatics and balancing.