An Introduction to Open Source Projects for Beginners With Safia Abdalla (S6E19)

This episode was transcribed with the help of an AI transcription tool. Please forgive any typos.

Laurence Bradford 0:09
Hey, everyone, thank you so much for tuning in to the Learn to Code With Me podcast. In this episode, you're going to find out how and why you can start contributing to open source projects, and even how you might be able to work on an open source project full time. That's all coming up in a moment.

Laurence Bradford 0:29
Wouldn't it be great if you could get paid to learn how to code? Even if you're a total beginner just starting out on your own learn to code journey? Well, I'm here to tell you that you can do this my free eBook 28 Ways to Earn A Side Income While Learning How to Code walks you through 28 different side gigs you can do to turn your tech skills into dollars, even if you're just starting out. You can download it for free over at learntocodewith.me/sidegig today. Again, the URL is learntocodewith.me/sidegig.

Laurence Bradford 1:10
Hey listeners. In today's episode, I talk with Safia Abdalla. Safia is an open source developer, a software engineer at Microsoft, a writer and a co-host of the Book Bytes podcast. The reason why I reached out for Safia to come on the show is because she is both a contributor and a maintainer of open source projects. And for so many reasons that we're going to get into during this interview. Contributing to open source is a great idea. So today, we're going to cover what open source means. What makes for a beginner friendly open source project. How do you include your contributions to open source on your resume or related and so much more. The tip Safia shares are perfect for anyone curious about venturing into the world of open source. Enjoy.

Laurence Bradford 2:06
Hey, Safia, thank you so much for coming on the show.

Safia Abdalla 2:09
Thank you for having me.

Laurence Bradford 2:10
I'm really excited to chat with you today and to talk about open source. This isn't something we've covered a whole lot on the show, so I can't wait to get into it. But first, I would love if you can tell us a bit about your background and how you got into tech.

Safia Abdalla 2:25
Sure, um, how I got into tech Boy, that's a story that starts quite a while ago. I got into tech when I was a preteen around 10 or 11 years old. There was a website at the time called neopets.com, which Me and my friends used to hang out on. And one of the things that you do on Neopets was design a profile page or basically your social media profile on the platform. And they allowed you to use HTML and CSS to create your page. So as one of my hobbies And something that I did with my friends, we would kind of try to create the glittery, best, most fabulous profile pages that we could. And in doing that I ended up having to learn HTML and CSS. And those are really exciting moment for me because that's kind of when I discovered that computers are not just things that you could use to do stuff, but things that you could make do stuff for you like building a really cool profile page on Neopets or writing a program to do something. And since then, I've just kind of fallen in love with it. I was taught myself programming, I did it all through high school, to college, did computer science. And yeah, just was very enthusiastically into it from that first moment that I discovered that computers are these things that I can control.

Laurence Bradford 3:56
Wow. So you've been working. Are you Working I guess on high school, but programming for quite a long time then if you started when, while you're at 10 or 12 years old? Yeah. Wow, that's really awesome. And how did you get? I don't know if that's the right way to phrase the question. But I would love if you could talk a bit about how you got into open source and what that means. So bear in mind, a lot of folks listening to this show are brand new to technology. And some maybe have only been learning about it for a few weeks. So you could tell me about that'd be great.

Safia Abdalla 4:33
Yeah. So if you google open source, the dictionary definition is some legally use about how open source software is software where the creator of the software gives you the right to modify it or copy it in some way. something to that effect. That is one definition of open source. For me. The definition of open source is any code that exists publicly that individually tools can collaborate on. Oftentimes people will host this code on platforms like github.com, where the code is stored in repositories and multiple software developers can come in and Submit Changes to the code that's in these repositories on open up commentary about features or bug fixes that they would like. Things like that. So for me open source software's really, any software that people build together in a public fashion.

Laurence Bradford 5:32
And how long has this been? Like, around for like it again, if that's like the right word to phrase, I'm sure people have been collaborating on different kinds of software for ages. But what like, I don't know. Like, when did it become more popular or more common, I guess?

Safia Abdalla 5:52
Yeah. So open source software has been around since forever. You have pieces of open source software from the 60s and 70s. I would say more More recently, it's gotten popular with the advent of tools like GitHub comm, which is often described as a social coding platform. I think this was a really monumental technology because it gave people a place to share their code and to collaborate on it in one centralized location. So I think the advent of those kinds of technologies was really helpful. And I think in general, just the emergence of the web and the internet as more accessible technologies for some people kind of brought about the advent of open source because now you had a way to communicate and interact with people who, you know, didn't just work at the same company, as you are studying the same computer science department at university, maybe you were a programmer at one university collaborating with a software engineer at a different company. And the internet kind of opened up these opportunities where people didn't have to be in the same space in order to have capital. Hold conversations and to build software together. So I think it was the really the internet is, is what did it. And of course the internet made a lot of important things happen in technology. So that's I think that's fair to say.

Laurence Bradford 7:14
Yeah, yeah. And I would love to hear like, how did you discover open source and what made you want to start participating in it?

Safia Abdalla 7:22
Yeah, so for me, it started off as a personal challenge. When I was a freshman in college, I had gone to a workshop series called write speak code. Right speak code is, I believe, a national organization here in the United States where different workshops will prop up in different cities. It's geared at primarily women in tech. And the idea is to help you build your brand as a software engineer by writing you know, blog posts, books, so on speaking at conferences or meetups and coding in open source So one of my kind of personal goals, my freshman year of college, I wanted to get involved in all of those things. So I had started writing blog posts, I had started speaking at meetups and some small local conferences. And then my last big goal was I had to contribute to open source. And so I still remember it, the day I did it. And I always like to tell this story, because I think it really puts it into perspective for a lot of people who are beginners and just looking to get started in open source.

Safia Abdalla 8:27
The first time I made a change to an open source project, first time I submitted a pull request. It was a one letter change. That was it. It was so trivial in so many ways, now that I look back at it. But believe it or not, I sat on that one letter change for I think, a week and a half. You know, trying to figure out how I use Git and how I use GitHub, and how I use all of these different technologies how I make the change how I test verify it. And I was just so nervous the whole time and spending so much time on it. And then I submitted the pull request the maintainer of the project, that's the person who's in charge of reviewing pull requests and issuing releases and things like that. reviewed it said thank you, and they merged it, and it was done. And that was an extremely again, when I talk about like empowering moments in my career. You know, the first one was the first time I made a theme for my Neopets profile page. I think another one was, when I had my pull request, merged into the open source project for the first time knows, like, wow, I can do this. It's not that hard.

Safia Abdalla 9:41
You know, I just have to put in time and I can do it. And I've been doing open source ever since it's been about oh boy, like five years now. Sometimes people will joke that I've spent a fourth of my life or more in open source. But yeah, that wasn't Kind of the catalysts for me is I had this personal goal of contributing to open source that was tied into my kind of other goal of starting to build my brand as a software engineer. And then I just got hooked on it. So it's such a very, it was a satisfying experience. It's always great to collaborate and work with people and form a network of other software engineers that I work really well with to understand how I work that, you know, if I have a really interesting idea, I can go to them and they'll hear me out and help me out with it. It's it's great to have that network.

Laurence Bradford 10:37
Yeah, that is such a cool story. And I love how you told us how you like it's just a one letter change, and you were sitting on it as it for a week. That's really, that's really great. And you mentioned you went to this conference or event right speak code your freshman year of college. And so then when was this like, how much after how much time had passed after that event?

Safia Abdalla 10:58
Yeah. So I would say I think I went to the event. Gosh, I had to dig through my brain. I think I went to the event it must have been the winter of my freshman year of college. And then the I spent like the winter in the spring, you know, blogging and I had found like a conference to speak at and some meetups to speak out. And then the summer is the summer after my freshman year of college, I was doing an internship in the Bay Area. And that's when I did the open source bit. So it must have been maybe, I think it's safe to say like, five to six months after that conference is when I got around to submitting my first pull request in open source.

Laurence Bradford 11:42
Wow, okay. And you were studying computer science at your college. Okay, that's that. For some reason. I thought you said your senior year so I think I misheard you earlier. I thought it was four years later, but Okay, that makes that makes sense. But still, even if was four years later, that would be a great story nonetheless. So do you remember what Project was for?

Safia Abdalla 12:01
Yeah, it was for a project in the Python ecosystem. It was called Pandas. It's essentially a data analytics tool. I was familiar with that project because I had used it during my part time job during my freshman year of college. So I was already familiar with it as a user. And the other thing that was really appealing about that project is they did a really good job of labeling all of their issues in their GitHub, their issues, essentially a list of bugs and features that they need to implement. And they had a really great labeling scheme where they kind of labeled things by how easy or hard it was, how much time they expected it to take. And then what category it was in, so it was really easy for me to essentially find an easy bug that would not take me a long time to do and to fix it. And those are really great because they tend to be the kinds of things that are just small enough that The maintainer of the project might not have enough time to do something so small, but small enough that you know, a new contributor or someone who's never been working in open source can tackle them. So, that's how I got, I chose the pandas project as the first project that I submitted a PR to.

Laurence Bradford 13:18
Nice, nice. So, so, okay, so I know and I, I feel this way, and I know, we can just feel this way that contributing to an open source project. Well, first of all, you have to like understand the entire right like if you're using GitHub and know what all these different terms mean. And once you're like up to speed with that, understand how it works. I feel like there's a lot of, I don't know, maybe imposter syndrome like like, like being nervous too. Because what if you're wrong, right? Like what if you suggest something What if you're wrong, what steps to take all that? How would you recommend to someone who's like somewhat new, like go about educating themselves and learning like how to contribute and like the proper steps to take.

Safia Abdalla 14:01
Yeah, so I would say, if you're interested in contributing to open source, one of the first things I would do, and it's a little bit counterintuitive, is find a project that has a good culture. And what I mean by that is find a project where the maintainers are going to be supportive, and provide good mentorship, where the community is going to be tolerant if you make a mistake, or mess something up and kind of aim to work in that kind of a project. And I say this because the reality is, we all don't know everything. Even now that I've been doing this for almost five years. I don't know everything about open source or GitHub or things, the technologies that I work with. So finding a place where it's okay for you to make mistakes, and it's okay for you to learn is the first most important step. I would say that there are some projects that are not as tolerant of learners as others.

Safia Abdalla 14:56
So find the ones that are I would like to Shout out the project that I'm involved in, which is called interact as a good project to participate in. If you're someone who is, you know, a learner and wants to get involved in open source and be a part of the community that's going to be welcoming and supportive. So a find you the right people to collaborate and work with, and then be taken step by step. Don't take it all at once, I think is the best piece of advice, I would say, start by building a foundation, which is just knowing a particular programming language that that project uses. And then start by learning just get and then start by learning GitHub, and kind of assemble the pieces that you need to know bit by bit.

Safia Abdalla 15:46
I think this kind of creation of the roadmap for your learning is subjective and unique to each individual, which is why I really emphasize finding a good community and good project to learn with it's the first step because those people People are going to help guide your learning and show you the right way to do things the right way to learn things based on their experiences and also their knowledge about your background and your experiences. So you actually think, you know, it's really hard to generalize and say what the best way to learn is. But I think a good piece of advice that I would give is, find a project with people who can help teach you and are tolerant of the fact that you're a learner, like we all are.

Laurence Bradford 16:27
And could you repeat the open source project that you is it is the right word you mean to maintain?

Safia Abdalla 16:34
Yes, and the right word design maintain it with several other people. So it's not just a solo effort. The project is called Nteract the spelling for that is n-t-e-r-a-c-t. You can find this online The website is going to be n-t-e-r-a-ct.io. So if you go there, you can read a little bit about the project you can find links to GitHub organization, as well as a Slack channel, where all of the contributors and maintainers of the project hang out.

Laurence Bradford 17:08
So you are good. You just kind of answered the next question I was going to ask, but I would love to talk about a bit more, because as you're speaking, I was thinking, Okay, so like, do all these people just communicate on GitHub? Like, is that like the main form of communication? But sounds like you guys are also staying in touch over slack, correct?

Safia Abdalla 17:27
Yeah. So I would say there's a couple of different ways that people in open source communicate, and it also depends on the project, I can speak to how we do it on the interactive project. Communication does happen in GitHub on GitHub tends to be a great place for this because GitHub issues and pull requests will be indexed by Google. So if someone ends up googling something that's kind of related to your project or an issue on your project, they will land on your GitHub page. So that kind of information is really easy. Tap surface publicly through a search engine like Google not been to look back at later because it's all kind of archived and stored on GitHub. So generally GitHub for kind of communications where you want to purse for communications where we want to preserve the information. We also communicate via-- We also communicate via Slack. And this is kind of for more back and forth conversation where you're maybe getting some mentorship directly from someone or want to talk about an idea or a problem that you're running into. Sometimes we will jump on Hangouts, so video hangouts with two to three people where we will kind of pair program or work on a problem. Another way we communicate is through discourse forums. So this is where it's essentially kind of like a modern forum where people can make posts and other individuals can respond to it.

Safia Abdalla 18:57
There's also weekly recorded video hangouts where we provide updates on what we're doing and what we're working on and interact, we will post those to our YouTube channel so that folks who are interested in what's going on in the project can go to the YouTube channel, watch those weekly uploads and kind of get a sense of what's going on. So there's a ton of different ways to communicate. We try and keep all of it digital, oh, I will add. We also do have some in person, we call them sprints where maintainers and contributors who can will fly out to a single location for a week and we will all be working on the project at that location physically together for a week. So yeah, there's a ton of variety in the way that people communicate and open source from text base to video to audio to in person. It's kind of whatever is the most appropriate for what we're trying to do.

Laurence Bradford 19:59
Sit tight podcast listeners, we're taking a quick break to hear a word from our sponsors.

Laurence Bradford 20:04
Technical sidegigs have had a massive impact on my life. Shortly after I began learning to code back in 2013, I landed a gig as an assistant to a more experienced web developer. That gig was my first step towards working as a freelancer later on. even learn to code with me, which is now my full time job began as a side project. I am so obsessed with side gigs because they are the perfect way to build up your experience and confidence as you transition into tech. Even more, they enable you to try out different aspects of tech before committing to a new career path in any particular direction. I really recommend them because I love sidegigs so much, I put together a free ebook to help you start your technical side gig journey so you can earn extra money every single month while advancing your skills. Inside this free guide, you'll learn which skills you need for these 28 different side gigs, how much money you can make from each plus tips on how to get started on whichever ideas speaking to you. You can get your copy completely free over at learntocodewith.me/sidegig. Again, the URL is learntocodewith.me/side gig.

Laurence Bradford 21:24
Got it? And as you're just talking, it sounds like there is so much that you do it almost sounds like a whole job unto itself, but you also work full time, right? So like, how much time every week are you? I don't know. Like, like, do you work on it every day after work? Or like how does it kind of look in the day to day?

Safia Abdalla 21:44
Um, that's a great question. And I think this is a pretty popular topic, especially for maintainers because there's a lot of conversation about um, maintainers burnout because they not only spend a lot of time on their open source projects, but have their day jobs and are essentially doing two jobs and kind of grow fatigued and stressed from that process. So I have had both negative and positive experiences with this, I've had moments where I was focusing too much on trying to be the best at everything all the time and commit a ton of time to open source and my day job. And, you know, that caused me to burn out. I have had moments where I was just focusing on my day job and didn't do any open source.

Safia Abdalla 22:29
And I think for me, it's just been a personal experience of trying to figure out where the best balances for me generally, I will try and work on it every day after work, but I will break it up. Generally I'll try to limit it to at most two hours, maybe an hour and a half. And usually what I'll do is I have my daily to do list and I'll identify a particular thing that I want to do related to open source for that day. So maybe I want to work on it. implementation for a feature. Or maybe I want to go through and check my GitHub notifications and clear out the, like 800 notifications that I have or something like that. So yeah, most people I know who work in open source actively and do it in addition to their day job. And I think we all have to kind of work on balancing our commitments to the job, as well as open source as well as other life obligations, like family and friends and all that.

Laurence Bradford 23:30
Got it and so, okay, so that was all really great advice. But like, Are there people that are doing this full time like essentially doing what you do not with a full time job and just doing open source maintain projects? Maybe multiple, maybe one? I don't know, is that like their full time thing?

Safia Abdalla 23:48
Yeah. So I do not have a couple of people on who do work on open source full time. For some of them. What they will do is they will work on it full time and they will have some sort of patronage page. I don't know if If you're familiar with Patreon, it's essentially a web service where you can donate monthly to an individual. And what these open source maintainers will do is they will work on open source, ship all these really useful open source tools that tons of developers are using. And then those developers will donate to them on a monthly basis. And that's their income source. As they kind of live off those monthly donations from individuals who use their technology.

Safia Abdalla 24:28
There are other people who work at open source foundations. So for example, the entire company is producing open source software. This is the case for the Firefox browser, which is open source and is run by Mozilla. So in that case, there is an organization that's funding the work full time for individuals who are producing open source software. And then there are other cases where an individual might work for a private company like Google or Facebook or something. And that private company is interested in the open source type. knology and so they will allow their engineers to spend time working on it. It might be, you know, one day a week, or it might be their full time job, but they do do it as part of their full time role. Um, so those are, I would say, are like the three degrees of working in open source that are more full time than just doing it nights and weekends.

Laurence Bradford 25:21
Gotcha. Gotcha. So so that was that was like all super informative. I didn't like of course heard of like Mozilla and I think anyone who's used Mozilla, like you've seen probably that the donation so I'm assuming the donations are going towards everyone maintaining all that right?

Safia Abdalla 25:36
Yeah. And the Mozilla is a 501 c three so I guess it also goes to their operations and other things like that. I'm not aware of all of their internal finances, but essentially go after the yeah, to the organization.

Laurence Bradford 25:50
Got it. Okay. And the private company one Yeah, I was, you know, aware of that too, but Okay, so that and then there's the people with the Patreon pages. Were there Yeah, getting money through donations that way. Okay, that's really cool. So how long have you been a maintainer? Like, how long did it take you to go from being a contributor to open source to? Yeah, becoming a maintainer of a project?

Safia Abdalla 26:15
I'm not long at all, believe it or not, I think that's probably a year. And I think that's the case for most projects. If you are an active contributor, and you're really enthusiastic maintainers existing maintainers are usually really eager to bring you into the fold as a maintainer. So you can help out and do a lot of the reviewing of code changes that are being submitted by people triaging of issues that are coming in providing support all of that. I think there's definitely this presumption that some open source projects are a little elitist, and that there is a barrier that exists between being a contributor to being a maintainer. This might be the case in some projects I know on the interact project, we really actively work against that, in fact, so actively that one of the policies that we have is that as soon as one of your pull requests is merged into an interact repo, you are a member of the interact organization.

Safia Abdalla 27:15
So you can go in and review code, post comments and things like that. So we've like completely reduced the barrier to being a maintainer. And personally, I think, in a lot of ways, I don't feel like it's for project it's for projects that do have a culture where there are lots of really arbitrary barriers that are placed into what it means to be a contributor to becoming a maintainer. It's not super healthy. My view on it is if someone's enthusiastic about something and they really care about the software, and they really want to help maintain it and keep it going. Then they there shouldn't be anything that gets in the way of that. So for my person, like experience I was that way I was enthusiastic, I really wanted to do it. And that opportunity was given to me. So I like to give that opportunity back to people. Um, if you really want it home, you should have it.

Laurence Bradford 28:11
Yeah, I really like that mentality. And I'm changing subjects a little bit. But I really wanted to ask this, because a lot of folks listening to the show want to get full time jobs in tech, so they want to work as software engineers or data scientists or something else. And I was wondering, like, has your open source contributions or maybe not just maybe not yours? Maybe someone you know, who also works in the, you know, on open source projects? Has the can that help you get a full time job? And if so, like, could you talk a bit about that, like how to showcase it? I don't know on your resume or LinkedIn or your portfolio website or something?

Safia Abdalla 28:54
Yeah. So I would say it depends on in this case, depends on two things. Depends on the company that you are interviewing with. And it depends on the projects that you are working on. Some companies don't care about open source at all, like their interview criteria is, you know, can you do these whiteboard coding questions? Do you have these certain things on your resume? Do you have these particular competencies? That's one class of companies. And there's another class of companies that will look at your open source work as kind of a measure of your engineering skills. Because you know, this open source code, it's public, it's out there. If I am someone looking to hire you, and I wanted to see how good of an engineer you are, you know, what better way than to go see the code that you've written.

Safia Abdalla 29:41
So some companies will use it as that kind of measurement and then other companies. If your open source project is something that is really well used or really popular, will hire you on the basis of being a contributor or maintainer within that project, because you have expertise that they want. So it depends, I would say the best kind of projects to do are probably not in the realm of, you know, like web apps, or I don't know what the best way to describe it. But I know some beginners will start off with, like building a web app and putting that on their GitHub. I think that's certainly good with respect to like showcasing your skill set, I think what's a little bit better to do is to build open source projects that are more like packages for a programming language that you are interested in, or API's or things like that things that other developers can consume. That tends to be a really great way to showcase your technical skills and your ability to kind of ship something and maintain it in the long run, which is really important for having a full time job as an engineer. Um, so yeah, I would say the best kinds of projects are Those kinds of projects where you're kind of showing that you can ship software consistently.

Safia Abdalla 31:04
And it's a package or a tool that's going to be used by other developers not just on a side project that isn't really actively used. And then with respect to showcasing it, I think the best thing is just, I personally just link to my GitHub on my resume. There were points in time where I did list out the project that I contributed to in my resume, that's a good option as well. Those are the only two that I have experience with. I know some people will kind of create collages online on their profile pages of what projects they contribute to. Generally, from my experience, on the other side, as someone who's been on the hiring end, at a full time company, I'll just go straight to their GitHub if it's linked on their resume, and I'll start poking around and looking at it.

Safia Abdalla 31:50
I don't really bother to go into any kind of portfolio page or something they might have about their GitHub projects. I'll just go straight to the source, but that's might just be me. So yeah, I don't know if that was particularly helpful for my experience, focus on projects that you ship consistently. And then you work on long term, and that are more likely to be used by other people, especially if in some other developers, which tends to be the easiest thing to do. And then the respect to how to showcase that I think as long as your GitHub is on easy to link to whoever's hiring us probably going to find your GitHub and start looking through it. And reading what you have.

Laurence Bradford 32:30
Yeah. Oh, that's it. Those are really good tips. I would love actually, if you can elaborate on something you mentioned. Just now. So you were saying making a package or an API or something that other developers can consume? Could you give like, an example of what that could look like? It doesn't have to be super detailed, but maybe something you've done or yeah, a friend of yours, or something?

Safia Abdalla 32:52
Sure. So I can talk about it. One of the like, side projects that I built as a command line tool called Legit and what Legit would do is it would essentially, um, if you had an open source project, it would populate it with a license file. Generally, when you have open source project, you have to pick some sort of license, which is essentially legalese that outlines the rights that other people have to use the source code within your project. And so I made a quick little tool that made it really easy to create a license file for your project. And I shipped that out a couple of years ago, and I ship versions of it out every now and then. So there's kind of helpful tools like that when it comes to packages, it could be something like an NPM package. One of the other packages that I've done was a middleware package that would integrate with a another technology, or sorry, it was a middleware package that would integrate with another node module. I feel like

Safia Abdalla 33:54
I'm using a lot of technical jargon here, but it was basically a package that allowed you to Log certain things into a particular service called century. And that was another package that I published and that people are using in production, in their software at major companies are just sometimes frightening to think about, that my code is being used by people, which is a good thing, but it's sometimes scary to think about. So yeah, those are the examples that come to mind for me, but just, you know, things that I think the most important thing is not necessarily consumed by another developer, but just something that is used by other people, and that you are maintaining in the long run. I think one of the key distinctions between being a learner and just getting into software engineering, versus being someone who's been a software engineer for several years is that when you've been doing it for a while, you start to develop a history where you have shipped products to customers, and you've maintained those products, by shipping out improvements, bug fixes, things like that, and I think showing that you have the ability to not just write software, but to write software and improve it is really important.

Laurence Bradford 35:06
Oh, yeah, that that's great. And I like how you clarify like something that people are using or businesses are using, it's like bringing value into the world in some way, even if it's, you know, really small, like a small thing, but it's bringing value in some way. And I really liked the licensing example that you shared, um, that sounds like something that would be really useful for people and like, like beneficial, and I just, I'm curious, I feel like we let me check the clock here. Can we have a little bit more time? How did you even get that idea? Like, was it something that you were like, Oh, this is a problem I have. And I'm going to create this because I would use it or?

Safia Abdalla 35:42
Yeah, that was exactly it. As I was moving the situations. I had run on those kind of situations where I was seeing a ton of my own GitHub projects without license files. And I was just noticing and a lot of other people's projects. I was like, hey, it looks like they're A space for something to be built to solve this problem. And so I went out and did it. So I think that's another really good thing is as you're learning, you might have those moments where you're like, Am I just dumb? Or is this actually a problem? You're not dumb, write it down and see if you can build something to solve that problem you're having or that hiccup you're running to, because it's likely that if you're running into it, other people are too. And that's an opportunity for you to write software that delivers value that you can put on your GitHub, not only to showcase to companies that you want to hire you, but also to like start collaborating with people and to help others out. So I think that's a really good skill to develop this just as you're learning to code as you're coding every day as a software engineer, be mindful of the problems that you run into and how you might build solutions to solve them that you can then share it with other people via open source.

Laurence Bradford 36:58
I love that that is such a good way I think and this interview that's such good advice. I could like, talk more about just that topic. But I'm going to hold myself back. I would love to ask you one more thing, because I can I can I can ramble on for a while. But last thing is there any parting advice you have for people who are just starting out and just getting their feet wet in technology?

Safia Abdalla 37:19
I would say the most important skill set in being an engineer is not intelligence. It's not shared genius. It's not what editor you have, or what company you work at, I think the most important thing that has kept me interested and engaged in growing as a software engineer for so long as persistence, some people will run into a bug that is really hard to debug, and it gets the best of them and they will quit. Some people will not quit when they run into that difficult problem, or they're really hard to fix bug. And those are the people who become great engineers, who don't let those things get in the way of their progress. Yeah, so persistence is key.

Laurence Bradford 38:02
Awesome. I love that. Thank you so much again for coming on the show. And where can people find you online?

Safia Abdalla 38:08
Yeah, so I have a personal website. My personal website is safiya.rocks. It's a really awesome domain name that I scored. So if you go to safia. r-o-c-k-s you will find my personal website there, you will find links to my blog, my Twitter, my LinkedIn, all of that good stuff, some of the conference talks, I've given books I've published. And then the open source projects that I work on are links there as well. And then I'm probably most active on social media at Twitter. My Twitter handle is CaptainSafia. So you can follow me there as well.

Laurence Bradford 38:49
Great. Thank you again for coming on.

Safia Abdalla 38:50
No problem. Thank you for having me.

Laurence Bradford 38:57
Thanks so much for listening today. If you will Want a reminder of anything that was covered in the episode just head on over to learntocodewith.me/podcast. You can see all previously published episodes there. And if you enjoy Learn to Code With Me podcast, please consider becoming a patron of the show. By pledging just a few dollars per month you'll get access to a bunch of patron only bonuses and privileges, like the ability to vote on the topics of future episodes. To find out more, go to learntocodewith.me/pledge. Thanks and I'll see you next time.