I’ve been speaking and writing for some time now on the importance of communication and collaboration in the scientific community. We have to stop reinventing wheels, and we can’t expect to learn the skills in coding and data management we need from attending one workshop alone; we need to establish customs and venues for the free exchange of ideas, and for practicing the new skills we are trying to become fluent in. Normally, these comments are founded on values of efficiency and sound learning strategies. But lately, I find myself reaching the same conclusions from a different starting point: the vital need for a reality check on how we treat the towering challenge of learning to code.

Everywhere I go, I meet students who tell me the same story: they are terrified of asking for help, or admitting they don’t know something to the other members of their research group – and the more computationally intensive the field, the more intense this aversion becomes around coding. Fears include: “What if my supervisor is disappointed that I asked such a ‘trivial’ question?“; “What if the other students lose respect for me if I admit I don’t know something?,” and, perhaps most disheartening of all, “What if this means I am not cut out for my field?”

If this is what our students are thinking – what have we done, and where has this come from?

There can be, at times, a toxic machismo that creeps into any technical field: a vicious cycle begins when, fearing that admitting ‘ignorance’ will lead to disrepute (perhaps even as lost grants and lost promotions), we dismiss the challenges faced by others, and instill the same fear in our colleagues of admitting they don’t know everything. The arrogant colleague that treats as trivial every problem they don’t have to solve themselves has risen to the level of departmental trope, and it is beginning to cost us in new blood. I remember working on a piece of code once for weeks, for which I received neither feedback nor advice, but only the admonition ‘you should have been able to write that in five minutes‘. Should I have? By what divine inspiration, genetic memory, or deal with the devil would I, savant like, channel a complex and novel algorithm in three hundred seconds, as a new graduate student with absolutely no training in programming?

That rebuke was absurd – and for those less pathologically insensitive than myself, devastating as they accrue, year after year.

Even in the absence of such bullying, we have made things for the new coder double-bleak. The computing demands in almost every field of research are skyrocketing, and the extent to which we train our students in computing continues to stagnate. Think of the signal this sends: computing skills are, apparently, beneath contempt, not even worth speaking of and so trivial to be not worth the training. And yet, they are so central to a growing number of fields as to be indispensable. Is it any wonder then, that so many students and early career researchers feel alienated and isolated in their fields, and doubt themselves for being hobbled in their work when they ‘fail’ to miraculously intuit the skills their establishment has signaled should be obvious?

A couple of years ago, Angelina Fabbro, my friend and mentor as well as noted web developer, wrote a brilliant article on Imposter Phenomenon (aka Imposter Syndrome), which they define as ‘the experience of feeling like a fraud (or impostor) while participating in communities of highly skilled participants even when you are of a level of competence to match those around you.‘ I strongly recommend reading this article, because even though it was written with the tech world in mind, it is one hundred percent applicable to the experience of legions of academics making careers in the current age of adolescence in research coding. The behavior and effects I describe above have contributed to an epidemic of imposter phenomenon in the sciences, particularly surrounding coding and digital acumen and particularly in students. That fear is keeping us in our little silos, making us terrified to come out, share our work, and move forward together; I consider that fear to be one of the biggest obstacles to open science. Also from Fabbro’s article:

‘In the end I wasn’t shocked that the successful people I admired had experienced impostor phenomenon and talked to me about it — I was shocked that I somehow thought the people I see as heroes were somehow exempt from having it… We’re all just doing the best we know how to when it comes to programming, it’s just that some people have more practice coming across as confident than others do. Never mistake confidence for competence, though.’ – Angelina Fabbro

So What Are We Going To Do About It?

The cultural and curricular change around coding for research that ultimately needs to happen to cut to the root of these problems will be, like all institutional change, slow. But what we can do, right now, is to start making spaces at our local universities and labs where students and researchers can get together, struggle with problems, ask each other questions and work together on code in casual, no-bullying, no-stakes safe spaces, welcoming of beginners and where no question is too basic. These are the Study Groups, User’s Groups and Hacky Hours I’ve been talking about, and addressing the problems I described is the other dimension, beyond simple technical skill building, of why they are so important. In my travels, I’ve stumbled across a few; here’s a map:

Study Groups & Hacky Hours

Please, if you’re running a meetup group or something similar for researchers writing code, let me know (bill@mozillafoundation.org) – I’d love to add you to the map and invite you to tell your story here on this blog (see Kathi Unglert’s guest post for a great example). Also, if you’re curious about the idea of small, locally driven study groups, my colleague Noam Ross has assembled a panel Ask Me Anything event on the Mozilla Science Forum, kicking off at 6 PM EDT, Tuesday, March 24. Panelists from several different meetup groups will be available to answer your questions on this thread, from 6-8 PM EDT; more details are on the blog. Don’t forget to also check out our growing collection of lessons and links to curriculum ideas for a study group meetup, if you’d like some material to try working through.

There are tons of ways to do a good meetup – but to start, see if you can get a couple of people you know and trust to hang out once or twice a month, work on some code, and acknowledge that you’re all still learning together. If you can create a space like that, a whole lot of the anxiety and isolation around learning to code for research will fall away, and more people will soon want to join; I’d love to hear your stories, and I hope you’ll join us for the AMA on the 24th.