[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today, we’re talking about getting into open source, which Janessa Tran, Junior Software Engineer at Ten Forward Consulting.
[00:00:20] JT: It exposed me to a lot of different things that I feel like are hard to get when you’re working on projects by yourself.
[00:00:27] SY: Janessa talks about being one of a triplet of coders, how contributing to open source early on helped her to level up her dev skills and what you should look for as a beginner when choosing what open source projects work on after this.
[00:00:47] SY: TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Take up the tool of software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.
[00:01:04] Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?
[00:01:21] Cloudinary is an end to end image and video management solution with a powerful API that lets developers upload, store, create, optimize, and deliver your media with ease. They have a generous free plan as well as advanced plans with enterprise configurations. So check out Cloudinary today at cloudinary.com.
[00:01:42] MongoDB is an intuitive, flexible document database that lets you get to building and MongoDB Atlas is the best way to use MongoDB. It’s a cloud global database service that gives you all of the developer productivity of MongoDB, plus the added simplicity of a fully managed database service. You can get started free with MongoDB Atlas at mongodb.com/atlas.
[00:02:11] SY: Thank you so much for being here.
[00:02:13] JT: Yeah. Thank you so much for having me.
[00:02:15] SY: So you are actually a part of a triplet of sisters who are all developers, which is really cool. What kind of work do each of you do?
[00:02:23] JT: Yeah. So it’s really funny that we’re all developers actually, because none of us really knew what computer science was before college. So I have one sister, they’re both actually in California and I’m located in Madison, Wisconsin. One of my sisters, Jennifer, she is a junior software engineer at Acorns, which is a fintech company. And my sister Jessica, she was a software developer at Amazon.
[00:02:51] SY: So what was it like to pursue something that both of your sisters were also pursuing? Was that kind of strange to do?
[00:02:58] JT: I think it provided me the support network that I needed when I felt like things were just really confusing. It was just really nice to have them to like ask questions and bounce ideas off of, and I actually, when I decided to start self-teaching web development, sent them this program I found online called “The Odin Project” and asked them what they thought and they gave it the okay. So yeah.
[00:03:26] SY: Yeah. Tell us about The Odin Project.
[00:03:28] JT: So it’s this open source free resource that has this curriculum of different stacks. You can do Ruby on Rails, which is the stack I chose and I think most recently they also added a Node.js curriculum. And it’s essentially just a bunch of different modules that you go through and they have different articles and videos that they link to and then a project. So it’s set up in a way that it’s very hands on because it gives you the resources that you need to use to understand enough to work on the project and then you can share and post your project for everyone else to see.
[00:04:10] SY: So how did you end up getting into coding? What was the first step for you?
[00:04:15] JT: So I was first introduced when I was taking a calculus course in college and my professor asked me if I would work with him. And I was really hesitant, but he sent me a book, I think it was Learn Python the Hard Way.
[00:04:34] SY: Yeah. That’s a great book.
[00:04:35] JT: Yeah. I accepted his offer to work with him and he needed me to create data visualizations using Python. And so that was my introduction to programming and it was really cool to be able to write a script and see a thing and make a thing.
[00:04:52] SY: What kinds of visualizations did you make?
[00:04:54] JT: So his research was around higher dimensional Lorenz models, which are basically the butterfly model is what some people now does. It basically looks like a butterfly and its movement. And so I used Python to visualize the trajectory of a 5D and 7D Lorenz model.
[00:05:16] SY: Wow! That sounds really hard and very sophisticated. Very fancy.
[00:05:21] JT: It sounds really sophisticated, but anyone can do it. If I could do that at that time, anyone could put it together and I wasn’t doing the heavy lifting. He invented the mathematical model and I was basically just putting it in Python and making it look cool.
[00:05:39] SY: What did you like about that experience?
[00:05:41] JT: I liked how immediately gratifying it was to code something and then see something on the screen, really, really satisfying.
[00:05:52] SY: What was the next step for you? Did you decide at that moment that you wanted to be a developer?
[00:05:56] JT: No. I didn’t. It actually took me a while. I had a lot of people kind of encouraging me down that path, but I never could see myself doing it I think for probably multiple reasons. I didn’t really understand what that path looked like in terms of a career. And when I looked at the other students who were studying computer science, I definitely didn’t feel like I could relate to them.
[00:06:23] SY: How come?
[00:06:23] JT: I guess I mostly saw people who just didn’t really look like me. I’m a first generation college student, so I didn’t really ever get exposure to any higher academic stuff and I was just incredibly discouraged by the fact that I didn’t really even know what computer science was. So I couldn’t even imagine what that would mean if I were pursue it as a career and the other students were just very into stuff I wasn’t into and that might seem trivial, but like some of the interests, some of the hobbies, like I didn’t read sci-fi or fantasy or play a bunch of video games.
[00:07:06] SY: Yeah. So then what got you kind of back on the coding road after seeing those people and feeling like you didn’t fit in?
[00:07:14] JT: Well, so I studied economics and I did other jobs throughout college internships involving data analytics and I found myself trying to put programming as much as I could into my workflow. So one of my internships that I did during school was at an advertising agency and I was helping them do data analytics and almost all of it was in tons of Excel workbook. And I thought that I’d try writing a Python script that could automate a lot of my work and I was able to do that. And that was just really, really satisfying and cool to me. And so I found myself trying to involve programming into my work a lot more and eventually decided, “Well, since I like this part of data analytics so much, like the actual writing of the program to do it, maybe I should look into writing code.”
[00:08:14] SY: So at what point did you decide, “Okay, I’m not only interested in looking into code, but I want to be a developer”?
[00:08:21] JT: That was probably last year after I moved to Madison and I started a new job. I just felt like there was a little bit of a FOMO, fear of missing out, because my sisters were both developers and I also just kind of felt like at that time in my life, I wasn’t sure where things were going and I was kind of bored, like I wanted to learn something new and try to make things. So I thought maybe I could try web development.
[00:08:55] SY: And what did you learn? What languages? What framework?
[00:09:24] SY: So tell me a little bit more about your experience with The Odom Project? Because my understanding of The Odin Project is it’s a self-pace curriculum. You got to go at it at your own pace. You’re essentially teaching yourself, but you’re using this curriculum to guide you along. What was that like? Did you keep a schedule for yourself? Did you have weekly goals? How did you manage that?
[00:09:45] JT: So I actually went through a challenge that I found at the same time called The 100 Days of Code Challenge and that’s kind of how I set myself up is I just initially decided that I would start with just an hour a day of coding. So I started there. And after a hundred days, that’s a really long time of building a habit, I kind of just kept going. And as you probably know, and a lot of people probably experience, you say you’re going to code for an hour. That turns into maybe three hours because you don’t want to stop what you’re working on because it doesn’t look quite right yet or you just get really into the zone. And so it started off with just every day after work. I would spend a little bit of time on a project. And it turned into a really valuable thing because I would post about it on Twitter and other people would like or comment on my tweets and I started finding a community of other people who were learning how to code by themselves as well.
[00:10:53] SY: So we’re here to talk about open source and getting started in open source. How did you first hear about open source?
[00:10:59] JT: There was this organization that I had heard about called “Data for Democracy”. And this was kind of in my exploration of feeling like I wanted to do some more developer work, but I came from a data background and it’s a community of people who work together to volunteer on social impact projects. And I joined a Slack group that they have where they essentially just post about different projects that they want to work on and organize groups of people to work on these projects. At that time, I was just kind of observing because I didn’t really feel like I had a lot of skills at least enough to contribute to these projects. So that was kind of my first introduction into open source, being a place where I could try to apply my skills to things that I cared about, like social impact projects. And then I started getting interested in contributing when I came across a tweet by Ruby Together and they were putting on a program called RubyMe and it essentially pairs junior developers with senior developers. And for 12 weeks, they get to work on an open source project together. And that seemed like a valuable thing. And I got accepted and was paired with someone to work on an open source project.
[00:12:26] SY: What projects did you work on?
[00:12:28] JT: We worked on a project called if-me.
[00:12:31] SY: What does it do?
[00:12:32] JT: So if-me is a mental health open source application that enables its users to share their experiences and stories with people that they are close to and trust.
[00:12:42] SY: Neat! And what does that do? What’s the end goal of if-me?
[00:12:46] JT: I think the end goal is just to make mental health resources more accessible to people who might struggle to be open about what they’re going through and don’t feel like they have the space to discuss it.
[00:12:59] SY: So what did you get to work on?
[00:13:00] JT: So I worked on a feature that enabled users to change their avatar to their Google avatar, if they logged in using Google OAuth. And then I also worked on just some specs, some tests in the application.
[00:13:18] SY: And that helped you in your outside of open source world that had helped you maybe get a job or anything like that?
[00:13:25] JT: Yeah. Absolutely. I would say it was probably the most valuable experience I had in getting my first professional software engineering role because it exposed me to a lot of different things that I feel like are hard to get when you’re working on projects by yourself.
[00:14:00] SY: Explore the Mysteries of the Pythonic Temple, the OSS ElePHPant, and The Flame of Open Source all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.
[00:14:18] No one wants to manage databases if they can avoid it. That’s why MongoDB made a MongoDB Atlas, a global cloud database service that runs on AWS, GCP, and Azure. You can deploy a fully managed MongoDB database in minutes with just a few clicks or API calls. MongoDB Atlas automates deployment, updates, scaling, and more so that you can focus on your application instead of taking care of your database. You can get started free at mongodb.com/atlas. If you’re already managing a MongoDB deployment, Atlas has a live migration service, so you can migrate it easily and with minimal downtime then get back to what matters. Stop managing your database and start using MongoDB Atlas.
[00:15:08] SY: So you recently wrote a post on Dev called “A Beginner’s Guide to Contributing to Open Source”. What prompted you to write that piece?
[00:15:17] JT: So in October, I participated in Hacktoberfest and I posted about that and I had a few people asking me how I got started and I wanted to be able to have a more thorough answer for how I got started, what helped me and pass that information along to other people who are new and interested in getting started, but didn’t know how.
[00:15:40] SY: Yeah. And what is some of that information? What did you want to pass on?
[00:15:44] JT: I wanted to pass on basically that, one, even if you’re a beginner you still know enough to contribute. Two, there are some kind of what I call “the green flags” that you can look for in terms of projects that might be good to start on as a beginner in both programming and in open source. Three, I really wanted to emphasize that you don’t need to know how to code if you want to contribute to open source. And four, the attempt to contribute is a success in and of itself.
[00:16:19] SY: So I want to talk about I think it was the third thing that you said that you don’t have to code in order to contribute. If you are not coding, then what are you doing?
[00:16:28] JT: I feel like a lot of things that people overlook, one, you can update documentation. For example, if you try to use the current documentation to get the project set up locally and you run into issues, you can update the documentation to help someone with a similar environment to whatever device you’re using get started as well or there’s also managing the issues on a project, cleaning them up, responding to people who maybe haven’t posted in a while on their issue, things like that.
[00:17:01] SY: So I think that you’re right for the most part that most people are probably ready to contribute before they feel like they’re ready to contribute, but I assume there is some type of baseline to when you should start doing open source work. What is that baseline? What’s like the bare minimum you should know or be able to do in order to start?
[00:17:22] JT: I think you should definitely be familiar with version controlling systems because everything is kind of set up in a way that it requires you to be at least familiar with it, if you want to contribute, because if you want to submit a change, for example, you have to understand how to make a pull request. I think another thing that you should be familiar with is just how to communicate things properly to people when you’re working on a team and also being understanding of what it means when you’re working on an open source project. And by that, I really mean sometimes people don’t respond as quickly as you might like because they don’t have the time because they’re doing this in their free time.
[00:18:09] SY: Yeah. Well, yeah, those are all really good points. So that last point that you made, going back to the takeaways, the things you wanted to pass on to people just getting started, you said that the fact that you are contributing to open source, that in and of itself is a win. Why is it a win? Why is it so important to contribute to open source?
[00:18:27] JT: It’s definitely good to acknowledge it as a win because often when people are new to coding and they’re contributing to open source, it might be one of their first experiences of putting their code out there into a code base that they don’t own, which is kind of a scary place that’s outside of most people’s comfort zones. And so I think anytime you do something that’s outside of your comfort zone because you want to help and you want to contribute and you want to grow, you should definitely give yourself a pat on the back for that.
[00:18:59] SY: So when you think about reasons why people don’t contribute to open source, we kind of touched on this idea that people might not feel like they’re ready, they’re maybe a little bit intimidated. What are some other reasons why people don’t contribute as early as they could?
[00:19:12] JT: Maybe they don’t come across the right projects or projects aren’t set up in a way that is necessarily inviting for people who are new to contribute because I think that an open source project is basically defined by a type of license. So not all of them are the same. Some are a lot more descriptive than others in just the read-me that you read. I think the more information there is, the more inviting it is for newcomers to be able to get themselves antiquated with just what the project is about and what kind of help they’re looking for. So I think beyond not feeling ready and not thinking they can do it, it just might be that they haven’t come across a project that seems like it’s beginner friendly.
[00:20:03] SY: Yeah. I think it’s really tough just finding interesting projects, projects that are relevant to you that might catch your eye and then also finding ones that are just a good fit for what you’re able to contribute. Do you have any advice on some of those? I think you call them green flags, some of those things that might tell us, “Hey, this is a good fit. You should try contributing to this.”
[00:20:24] JT: So I think some of the green flags that people can look for when they’re trying to find beginner-friendly open source projects is a code of conduct, which is essentially a collection of rules and values that everyone agrees to if they want to work on a project together. And I think that’s an important thing to look for because it signals to people that there are a set of rules and proper practices so that you aren’t going into something where someone might say harmful things too and that be okay. That is important because if you’re making a pull request for the first time and you’re maybe anxious about the kind of feedback that you’ll get on your code, this is a good way for you to maybe feel a little more safe, that there’s a code of conduct. There’s a way that everyone’s agreed to conduct themselves in rules and practices that they’re going to implement when communicating with you, even if it’s something about your code, that needs to be changed.
[00:21:32] SY: So we talked about green flags. I’m wondering what are the red flags that we should watch out for?
[00:21:39] JT: A project that is just generally less organized is probably not a great place for beginners to start. And by that, I mean like consistency in the way that issues are created or if there aren’t a lot of labels or just if it doesn’t look like it’s been taken care of, I think that indicates that it might be more difficult for A new person to get into and contribute right away.
[00:22:07] SY: So I want to talk about how open source contributing has affected you personally, because I think we have this agreement that open source is good, that we should contribute to it, that it’s going to help us, but I’m wondering specifically for you, what if the benefits of open source been for you and your development as a coder?
[00:22:25] JT: So beyond the RubyMe experience giving me what I felt like really valuable experience in terms of getting my first job, open source has been valuable to me personally because it gave me an avenue of being able to apply my skills to things that I personally cared about, which felt very empowering.
[00:22:46] SY: Tell me more about that.
[00:22:48] JT: Yeah. So for example, the project that I worked in during the RubyMe apprenticeship was if-me, and it was a mental health application, and that’s something that I really care about. And another open source group that I got familiar with was Ruby for Good and they work on a lot of different projects. One of them that I helped contribute to is called DiaperBase. And it’s an inventory system, diaper bank basically. And a diaper bank is where people donate diapers and then the diapers are given to people in need of them.
[00:23:24] SY: How do you find these projects? These are good ones.
[00:23:27] JT: Yeah. So Twitter has been a really good place for me to find them. I actually got familiar with this when I attended RailsConf last year. And I found out about RailsConf through Twitter. So I would say Twitter is an excellent resource, but in the article that I wrote, I listed a few websites that people can use to find open source projects and there are really good websites out there that let you filter by different things like the language that you want to work in or a topic that you’re interested in.
[00:24:01] SY: Very nice. How has contributing to open source affected your technical skills?
[00:24:06] JT: The feedback that I got helped me remember that when I’m writing code, I need to keep others in mind because I won’t be the last person looking at it. And it also just helped me explore code bases, which I thought was a really good skill that I wouldn’t have gotten exposure to just working on my own projects because I felt that the ramp up of just getting a project set up locally and understanding how it worked enough to start was a pretty challenging task in itself. And in my own work now at Ten Forward, I find that’s incredibly helpful because when you go to work for a company, you’re often going to be working on projects that have already existed for many years and being able to familiarize yourself with an existing code base I think is a super valuable skill.
[00:24:58] SY: One of the things that I love about working on other people’s projects is that it gives me exposure to different features, problems, different ways of coding that I wouldn’t otherwise be exposed to. And I’m wondering, has that happened to you in your experience of contributing open source? Have you been exposed to things that you wouldn’t otherwise have been exposed to?
[00:25:19] JT: Yeah, definitely. Like different ways to write tests, which maybe sounds boring to people, but there are so many cool things you can do to set up tests like with mocking data and setting up just the way that you described them, even just whether or not they write tests at all or whether or not they write tests before they write the code. Like if they follow a test driven development, seeing that in different projects was really interesting.
[00:25:55] SY: Coming up next, Janessa walks us through the steps of making an open source contribution after this.
[00:26:11] SY: Images and videos are the heaviest resources users have to download when they use your site or app. Achieving great experience with media was a complex and tedious task. But with Cloudinary, there’s a powerful API that employs sophisticated algorithms, machine learning, and automation to deliver great media experience on any device for any framework in web or a mobile app. At Dev.to, we’ve been impressed with Cloudinary serverless API platform and recommend it to developers as the one and only solution they can use to solve all their media problems.
[00:26:45] Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Not only that, it allows you to use the most popular open source languages to build web apps. And while you’re checking out their services, make sure to check out their podcast, Code[ish], that explores code, technology, tools, tips, and the life of the developer. Find it at heroku.com/podcast.
[00:27:24] SY: So when we talk about contributing to open source, I think there’s a general assumption that people are familiar with the steps, kind of the process of that and submitting a PR. Can you just kind of start from square one and just walk us through the steps of making an open source contribution?
[00:27:42] JT: Once you’ve decided on a project to work on, you want to want to look for if there’s any sort of wiki or documentation on how you should contribute. For example, do they want you to first claim an issue or ask about updating documentation in an email or Slack or whatever forms of communication that they use. So looking for that first and understanding what the best practices are and the guidelines that they’ve defined, if they’re defined at all. And so once you do that and say you’ve chosen an issue and in this context, I mean specifically an issue on the GitHub project itself, if it’s not claimed, make a comment on the issue itself, asking if you can be added as the owner. Or if you come across an issue that is claimed, you can check to see whether or not the previous owner has worked on it in a while. And if not, you can maybe reach out to them and say, “Hey, I noticed you claim this issue, but it hasn’t been updated for a while. Do you mind if I take it over or do you want to pair?” Something like that.
[00:28:58] SY: Oh, cool! What are some examples of issues? What kinds of things might I be picking up?
[00:29:03] JT: So it could be maybe someone wrote that the website isn’t responsive on mobile, or if they find a bug and someone opens an issue kind of thing.
[00:29:16] SY: Cool. So really distinct either features or fixes that we can add to the website or the app?
[00:29:22] JT: Yes.
[00:29:23] SY: So I’ve picked my issue. I am now owner of that issue. Now what I do?
[00:29:28] JT: Once you’ve decided on an issue, the next step is to clone the repo and get everything set up on your local environment. So that means either getting all the dependency set up and setting up a database, if that’s necessary. Once you do that and you have it running locally, you can create your new branch to start working on your feature that you chose.
[00:29:52] SY: Very cool. And then what do we do?
[00:29:54] JT: My recommended next step is to run the test suite, just to see where things are, because sometimes there’s flaky tests and some tests might be broken, but you just want to be aware of changes that you make that might impact the master branch or the main branch. And so diving into the code, understanding how things are set up, observing the ways that people kind of write the code itself, like how people name the methods, for example. You kind of want to follow the convention of what is currently in the project. Once you write your feature or whatever code you need to fix the issue and write tests, if that’s necessary, you can go ahead and make a commit and eventually a pull request and describe what you’re looking for in your feedback and describe what issue you’re working on and take it from there and see what feedback you get.
[00:30:55] SY: So before I submit that PR, that pull request, is there anything that I should consider or kind of go through a checklist in my head before I submit?
[00:31:06] JT: Yeah. So beyond just trying to be consistent with the way the code is currently written, for example, the method names that I mentioned or variables or just general code practices, running the test suite again, just so that you can see that your code isn’t breaking other tests is the next good step. Once you run the test suite again, you want to make sure that your branch is up to date with master. So essentially what that means is when you’re working on an open source project, there’s a lot of people working at the same time and what your local copy is on your computer might be different from what the project currently is. So you want to do a get fetch and merge of master and rebase against that.
[00:31:56] SY: And so how did it feel, I’m wondering, to make your first pull request?
[00:32:01] JT: It was very exciting and scary at the same time.
[00:32:05] SY: What were you scared of?
[00:32:06] JT: I guess it was just the first time I was having the world see my code, which was a bit scary, but it was also very exciting.
[00:32:17] SY: So for folks who are thinking about hopefully excited about contributing to open source, making their first pull request, what is the most important thing that they should keep in mind?
[00:32:27] JT: I think the most important thing to keep in mind is that even as a beginner, what you bring to the table in terms of your skills is incredibly valuable. Being just someone new to a project and giving fresh eyes and a fresh perspective on things is a lot more valuable than people remember.
[00:32:51] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Janessa, are you ready to fill in the blanks?
[00:33:00] JT: Yeah.
[00:33:00] SY: Number one, worst advice I’ve ever received is?
[00:33:03] JT: Lean into things that you’re interested in and that you care about and that you love to do. I think obviously it’s usually positive to pursue things that you really care about because that’s just an inherent benefit in being able to get through challenges when you face them in terms of trying to work towards that thing that you care about. But for me, I have a really difficult time pinpointing things that I love that are practical to pursue, if that makes sense.
[00:33:42] SY: Yeah. Number two, best advice I’ve ever received is?
[00:33:46] JT: I think the best advice, and I think I was about six when I got this, was to always express your gratitude for people and don’t hold back if you have something nice to say.
[00:33:57] SY: That’s beautiful. I love that one.
[00:33:59] JT: Yeah.
[00:34:00] SY: Number three, my first coding project was about?
[00:34:03] JT: The Python data visualizations of creating the butterfly models.
[00:34:09] SY: That’s such a great hardcore first coding project. That’s awesome.
[00:34:14] JT: And really anyone can do it. I promise.
[00:34:18] SY: Number four, one thing I wish I knew when I first started to code is?
[00:34:22] JT: I wish that I knew it wasn’t a skill that you had to be just magically talented in order to be good at. It’s a skill like any other. If you put time into it, you will get better at it.
[00:34:35] SY: Very true. Thank you again so much for joining us, Janessa.
[00:34:38] JT: Yeah, thanks for having me.
[00:34:46] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, firstname.lastname@example.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.Copyright © Dev Community Inc.