
From Solo to Social: Making Coding a Collaborative Adventure (Allissa Dillman, BioData Sage)
From Solo to Social: Making Coding a Collaborative Adventure Speaker(s): Allissa Dillman Abstract: What if coding were not an exclusive skill but an accessible adventure? Through community-driven, project-based learning, I transform data science education into an inclusive journey. My approach builds trust by meeting participants where they are, using familiar tools and relevant datasets. Through targeted workshops, and collaborative hackathons, I break down complex coding concepts into digestible applications for global audiences. By reimagining how we teach technical skills, I'm not just delivering education—I'm fostering a movement that makes data science accessible to all. Join me to discover how we can democratize coding and create pathways for everyone to become active members of the data science community. posit::conf(2025) Subscribe to posit::conf updates: https://posit.co/about/subscription-management/
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Now, when I was growing up, there was definitely a stereotype on who and what a coder was. And I decided to start this talk by using AI to ask a bunch of different tools, show me a coder. And they all showed me this guy. This guy right here, with this haircut, these glasses, that amount of coffee and pizza, he's a coder. So at least according to AI, there's definitely still a stereotype. Hopefully that's not offensive to anybody who has this haircut.
I was a first-generation college grad by day, hair model by night, and I certainly did not identify or really have anything to do with coding. And then I started towards my PhD, and sort of the amount, the size, and the complexity of biological data I was going to need to analyze exploded. And I realized, oh, crap, I'm going to have to learn some coding. And I'm going to have to do that on my own, because that was not originally my plan. And while I was in a super supportive environment, and there was a lot of great people that really supported me, it felt really lonely and kind of isolating, because I was a biologist. What am I doing with computers?
But then I participated in a hackathon, and it hit me. What if coding wasn't an exclusive skill, but an accessible social adventure? And I really got excited about that idea. And I've spent the better part of ten years working primarily in nontraditional training methods with a wide variety of communities. So everything from indigenous networks to high school students to medical librarians and bench biologists.
What if coding wasn't an exclusive skill, but an accessible social adventure?
And there's one thing that sort of kept coming out over and over again with a lot of the people I work with. And they also didn't see themselves or even want to be coders. You know, they really just wanted to analyze their research data, understand their community health risks, or explore their hobbies. Pokemon data, fantasy football. And coding was sort of this necessary evil that they needed to do the thing that they were excited about.
And inevitably, these folks would end up getting stuck on something, and they would go to the internet, where inevitably they would end up on Stack Overflow. And on Stack Overflow, somebody will tell you, go read the fricking manual. And obviously that's super disheartening. And if you're starting to learn and somebody tells you that, you may just stop right there. But what's even more fascinating to me is this idea that even troubleshooting should be solo. Right? You go off. You go learn it. You go read it. You go fix it. And to me, like, that really struck me as, like, an interesting thing.
The other thing is, for a lot of folks, they don't want to have beautiful code. They're not interested in the technical nitty gritty. They just want to do the cool thing. And a lot of the ways we offer help isn't that. So, you know, some of us, we do love to code. But for most of the people that I work with, they code to do what they love.
Three pillars: trust, accessibility, emotional resonance
So how can we create spaces, environments, and places where things are more social? That things are about the doing, the building of the thing versus the doing of the thing? And I've kind of come up with these three basic concepts that kind of happen over and over again in these kinds of spaces. And the first is trust. Right? To create a safe, collaborative environment where people feel comfortable asking questions, expressing interest, and also just saying frustrations. You also want things to be accessible, right? You want to lower those barriers of entry, make it not so scary, have people have a starting point so they don't feel like they're drowning. And also, and more importantly, and actually this kind of came out in our previous speaker, right? This idea of, like, you want things to kind of speak to people, right? This emotional resonance. I want to feel a connection, I want to be connected to my passion, and I want to be engaged.
So with these three concepts in mind, there are a couple of different ways that you can start to create community spaces using these concepts. And there's sort of three event types to me that really lend themselves well to this idea of trust, accessibility, and emotional resonance. The first is think-pair-share. So the idea of think-pair-share is this cooperative learning strategy, and it starts with individual reflection first, and then you're paired together, and you kind of discuss the problem, and then you come out to a larger group, and then you're kind of discussing, like, the things that you've learned. Then you have data storytelling, and here we have, like, these very bite-sized projects, and they're really focused on the idea of, like, data to meaning, so they're really focused on visualization, not necessarily so much on the coding themselves. And then finally, you have the sort of more traditional tried-and-true hackathons, right? Fast-paced team-building, problem-solving, and that sort of thing.
Think-pair-share with high school students
And I'm going to break down each one of these, and I'm going to kind of have a flow throughout of how you can interweave trust, accessibility, and emotional resonance for each one of these event types with a story, an example. So the first I'm going to talk about is think-pair-share, and this story is going to be about a group of high school students that I worked with. It was a completely virtual and mostly asynchronous for most of the summer, and then we kind of got together at the end of the summer in person, and the first thing I noticed when we were together in person was, while they really did understand, like, the functions and kind of what they did, they got really stuck on, like, how do I actually apply this in the real world to, like, real things? So that was the first thing. The other thing was they also really didn't want to ask questions, right? They'd been asynchronous and online the entire time, so nobody wanted to say anything. Nobody wanted any questions. They were very quiet.
And I thought, like, a think-pair-share might be a great way to sort of hit both of these issues, and so the first thing I did is before we even did the think-pair-share, I actually asked folks, like, hey, what are your goals? What are your interests? What are your hobbies? Like, what do you want to get out of this? I asked, like, a whole set of questions, and then I actually built coding challenges around these problems of interest. Then I provided a bunch of different coding examples in a bunch of different formats, and so that way each pair got to pick the challenge that really kind of fit them, and they got to roll with that.
The other thing that was really important to me is to really hit home this idea of mistakes are learning opportunities, not failures, and I even demoed a bunch of my old code from grad school that is full of terrible, terrible mistakes, and kind of walked through, like, and here's what I've learned about that, and here's, you know, how I've built new things, and it was great that I did these mistakes, because now I get to do more cool things. But also all questions are valuable. Honestly, a lot of the times when people ask me questions, I'm like, oh, I never even thought about it. Let's try it together. Like, it's a great space to learn together, but also, like, more often than not, if you have a question, somebody else has pretty much the same question. So why not learn it together?
The other thing that I really like personally about think-pair-share is the think part, and you know, this is meant to be, like, the space where we really get to slow down and process things internally, but I like it a lot, because I'm dyslexic, so I'm not a fast reader, and often what would happen, like, when I was trying to learn things, like, you would get shown some code, and everyone would already have the solution, and I'm like, I'm still reading what's happening. I don't know where we are. So like the think part really does have it baked into there. You have this pause time, this down time. Let's sit with our thoughts, slow down for a second, see what this means.
The other thing is that I built prompts for discussion, so not coding prompts, but actual discussion prompts, because I really wanted them to focus on this idea of, like, problem-solving and different ways to problem-solve and how to work through the challenge together, rather than, like, oh, let's get really nitty-gritty on the code. And then I kind of further brought that home for the group discussion, so we celebrated process over product, so what I mean by that is, like, we really celebrated, like, that's a really cool way to think about that, or I didn't even think about, like, using it that way. This is really great. And it was, again, less about, like, the code itself. I mean, but they were writing code, learning code, building code.
One thing I really loved about this is, so after we did the think-pair-share, I had always had virtual office hours throughout the whole summer. Almost none of the students ever came and just sat there and did nothing for an hour. But after this event, they were coming to virtual office hours, and I was like, this is great. And then when we would do live demos, they were asking questions. But the other cool thing is this was the third year I'd run this program, but the first year I'd done this, and they actually started their final projects early, like, before they needed to start them. So I have a hunch that maybe they felt a lot more confident in getting things done, even sort of, like, without guidance.
Data storytelling with medical librarians
The next example I'm going to talk about is using data storytelling. So I had a medical librarian program that I worked with for the past two years that was really focused on building more technical skills. And by this point, we'd actually had a couple of coding workshops already, but one thing that I really noticed with the medical librarians, so a lot of them, they'd been in their job for a really long time. They were super confident in what they did. And then we were teaching them coding, and they would kind of freeze. They would be like, I don't even want to do this because I'm going to do it wrong. What if I break something? There was just this real, like, concern about doing it wrong. And it kind of kept coming up over and over again. And the other thing that also I noticed is, like, for some of them, they were like, I don't know how this actually does apply to my job. Like, I'm not really getting a connection of, like, this work to what I do. So I thought a data storytelling activity might be a great way to kind of bridge both of those gaps.
So I started with a data set that was actually a health data set, some that they'd actually already come across a couple of times, and that's where we kind of built the heart of our data storytelling activity. The other thing that I did was I actually put them on teams, and they did have differing levels of sort of skills and skill sets that they were bringing. And I really tried to iterate that this was a strength, right? Because in order to sort of analyze data to tell a story with data, you need lots of different skills, right? You need to have the subject matter skills to understand the data, you need to be able to interpret patterns, you need to understand, like, the ethics of the data. There's so many components, and you need all of those things, and you can build them together.
But the thing that I love about data storytelling is it kind of gets at this idea of, like, wrong. In data storytelling, there are so many ways that you can tell a story with data, right? And this was, like, huge survey data. So there's tons of things that you can say about this data, there's tons of ways to explore, there's tons of plots to explore. So there is no wrong way, per se. There's many fun, right ways.
The other thing was I built some notebooks with lots of prompts, so lots of bits of pre-made code, like, hey, you could try this, or you could do this, here's a plot or two. But also prompts about the data, like, what if, you know, we do this, have you thought about the data like that? Like data exploration prompts as well. So they weren't kind of starting completely from nowhere. The other thing was I really highlighted interactive tools. So one of my favorite packages is Esky, and it's really cool, because it actually takes ggplot and turns it into a point and click, drop and drag, and it spits out code for you, basically. So it is reproducible, but it makes it interactive, and you're now not so focused on code, you're focused on, like, how can I tell a story with this data? So I kind of, like, removed that part of the stickiness.
The other thing is I really, really encouraged personal connection and creativity in this activity. And what I meant by that was, like, you know, is there a particular bit of data that speaks to work you already do? Is there a particular bit that speaks to something personally for you? But even more so, like, for their final presentations, I basically let them present however they liked. Some of them made infographics, some of them just did the plots, some of them talked about the ethics behind the data with the plots. They sort of got to come up with their creative strategies for this. The thing that's really fun about this is I just told you this entire program was virtual, and yet here's a picture of me with two of my librarians. And what happened was after this event, a couple of librarians got so excited and so engaged in this that they ended up actively seeking out other activities, and this happened to be a data for good workshop. And they showed up, and they were, like, we're excited to be part of the data community, and it was just really great to see how much more confidence they had after this.
Women-led hackathon
My final example is going to be hackathons, partially because this is my favorite thing. I ran probably over 70 of them by now. And this particular example is a bit of an oldie but a goodie. So when I was first participating in hackathons, I noticed that I was usually the only female team lead. There were other women participating, but not leading teams. So when I started running hackathons, I really wanted to change that. So I started talking to a bunch of different women's coding groups, women's science groups, and we came up with the idea with a women-led hackathon, and this was really sort of something we built together from day one.
And we were really excited to mentor and be mentored by other women. We also focused a lot more on collaboration versus competition, although, to be fair, all of my hackathons, for the most part, are pretty much collaborative, because I want to build community. But that doesn't mean that we didn't celebrate success, right? We had lots of fun awards around all sorts of different things to sort of say, like, hey, you've done amazing stuff. But also I built the team specifically to make sure that there was, you know, coders as well as scientists and different levels of expertise, and they could really build community together that way. Finally, we made sure that the projects had varying level of difficulty, but also subject matter, so that way there really was hopefully a project for everyone.
I also built multiple sort of, like, team roles. So we had everything from, like, data munger to, you know, analyst to subject matter expert. Like, people made logos for their teams so they could practice art, all sorts of things. And I also made sure that there was a bunch of different, like, shiny tools and cloud computing tools to help them collaborate together. And the final thing was, like, for our final presentations, I really wanted them to have, like, outside the box, like, crazy ideas. And they loved having this, you know, no-risk place to explore and take risks.
But what I loved the most about this hackathon is most of the participants were men who'd never been in a hackathon before, and they explicitly said they were participating because this is a women-led hackathon. And most of us actually still continue to talk today, work together, collaborate together. But my favorite part is a couple of the women in this picture formed another team and participated in MIT Hacking Medicine, and they won. So I was like, yes! This is fantastic!
Why this works
So why does this work? So if you have trust, you build safe social learning spaces, right? And this builds persistence. So even if I get stuck, like, I know I have an Accountability buddy who's cheering me on, and when they get stuck, I'm cheering them on, right? So when you get frustrated, like, somebody's like, yes, you got this, and when you're frustrated, you swap. But also, like, you now have a safe community. When you do get stuck, you're like, I know I can ask somebody, and they're not gonna be like... Also, right, so we want clear points of entry, supportive tools, lower barriers of entry, and that really helps more people feel welcome. And finally, emotions just make things stickier, right? You're more likely to learn things when you feel connected to them.
And finally, emotions just make things stickier, right? You're more likely to learn things when you feel connected to them.
So three ways you can start today. Curiosity questions, instead of where are you from, what's your name, ask them what they're interested in. What-if questions, open-ended questions, to make it like you are interested, you want to explore. Also, multi-participation formats, right? You can share by a giant whiteboard with sticky notes instead, so you can be social without talking to people. And finally, connect activities to real problems, even if it's something small, like a dataset, a question, something. And you don't need to do all three of these, even just one is great.
So I hope today that I have really helped you come into my idea of, like, coding is about what you can imagine and create together. If you want to work with me, check it out there. I actually have an initiative right now. We'd love to have mentors, datasets, and student participants. Thank you so much.
I think we have time for one question. When building teams with different skills, how do you decide how to put people together? Or do you just let them get together by themselves?
Yeah, so most of the events I run are where I specifically build the teams, because I really do want them to work outside of their, sort of, field, but also have interdisciplinary teams, but also have different skills that they're building together, so I really try to make sure they're people who have never been in a hackathon before, people who have, people who have, sort of, not as confident with coding, those who are, and I'm really trying to make sure that these teams that are going to work together and build together.
