[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 starting out an open source with Brian Douglas, Founder and CEO of Open Sauced.

[00:00:19] BD: I learned a ton working at startups and seeing how the world works and really understanding how like the world of software and business works. The thing that I’ve taken away is like I like working at companies that I could use. And it’s kind of been like the difference of my career is that I’d always been working at developer tools that even the bootcamp I worked at, I used that bootcamp software to learn iOS programming while I was working at the job. So just be excited about what you’re working on. And if you’re not excited, for me, I just go move on to the next thing.

[00:00:45] SY: Brian talks about starting his own company, takeaways from working at startups, and describes what open source is all about after this.

[MUSIC BREAK]

[00:01:02] SY: Thank you so much for being here.

[00:01:03] BD: Thank you for having me. Again.

[00:01:06] SY: So Brian, we had you on the podcast many, many, many years ago. You were one of our very, very first guests and we had you when you had just graduated from your bootcamp. Fill us in on your coding journey. What happened since those early days moving up to now?

[00:01:20] BD: It was crazy times because I think I’d spent like about 17 weeks from deciding to code to then getting my first job. And I think it was probably the second week I had that job. You had reached out and we had that interview. So everything was brand new, didn’t really know what was going to happen. So yeah, fast forward, spent 10 months at that job with an idea as a Ruby on Rails engineer. Then made the leap to move to San Francisco right after that for another job. And I worked for Bloc, which got acquired by Thinkful. And the bootcamp, the bootcamp actually I learned from. And then I spent a quick tour of duty at an early startup called Netlify as Employee #3.

[00:01:54] SY: Wow!

[00:01:55] BD: It was like very serendipitous. I sort of, while being in San Francisco, ran into the CEO and co-founder and started using the product. A year later, they reached out because of my podcast and blog, and then spent four and a half years at GitHub. Then most recently, in the last six months, went full-time on my own startup.

[00:02:09] SY: Yeah. So I know that the reason you had initially gone to bootcamp is because one day you hoped to start your own company. Why did you want to start a company and why did you think learning to code would be the way to get you there?

[00:02:23] BD: Yeah. So my story of learning how to code was my son was born early, about 11 weeks early.

[00:02:27] SY: Wow!

[00:02:28] BD: And we were in the hospital and at the same time I was getting my MBA.

[00:02:30] SY: Oh my goodness! So much going on.

[00:02:32] BD: Yeah. So I was getting my MBA to basically be an entrepreneur. I was doing sales at the time and I learned from my first dissertation, first semester, I wrote basically a dissertation on Google and how that company was founded and how they basically had no brick-and-mortar business behind it, which is they just knew how to write code and then some other stuff. They got CS backgrounds and stuff like that. But that kind of sparked in my mind, it’s like, “I can get this MBA and then I can also learn how to code and build my own stuff.” And that was the goal until I found out you can get paid more as a junior engineer. And I basically went down that route for a while.

[00:03:05] SY: Very cool. So once you graduated from bootcamp as opposed to starting your own company right away, as you said, you threw yourself in the tech industry, you learned through other companies. Was the goal to eventually come back to that dream of starting a company or were you just focused on making that sweet developer money back in those days?

[00:03:24] BD: Yeah. One of the best ways to kind of learn how to build a company is go work for a company.

[00:03:27] SY: Right.

[00:03:28] BD: And that’s like the sort of mantra I had the entire time. I wanted to be a good engineer, wanted to learn all the skillset I didn’t have. So I did the sales background because I did that for four years outside of college. I had the business background with the MBA and also the college degree. I had a finance degree as well. So learning how to code is like another skillset I can have to be ready to be an entrepreneur. At the time, I gave myself like four to five years of go work somewhere and then go start my own thing. And within that four-year mark, the most interesting thing happened was I got a job at GitHub and then six months later we were acquired by Microsoft. So the golden handcuffs became extremely amazing, like to be quiet honest…-[00:04:05] SY: Yeah, very golden. Yeah.

[00:04:06] BD: Yeah. Yeah. And like from being in the San Francisco in the Bay Area, like I was living in like a one-bedroom apartment, sort of like doing the startup grind, like living the dream. Getting the Microsoft stock basically, because that’s what happens when GitHub was acquired by Microsoft, it became very comfortable. So that kind of postponed my thought of doing my own thing, but I kept building side projects and doing open source a lot. And then when I was ready to do it again, the pandemic hit. So it got postponed mainly because I’m very conservative around my budget and realistic about like taking chances. So it got to the point where I was four and a half years at GitHub, fully vested. The handcuffs were slightly loosened. It was like now or never. So here I am.

[00:04:43] SY: Very cool. So I know that you said that you got a job at Netlify, which I feel like is like the hot thing, and you were Employee #3, which is super early. Tell us a little bit about Netlify and what was that experience like being an early employee there.

[00:04:56] BD: Yeah. I mean, it’s wild that on the other end of it, because the mantra is most startups fail.

[00:05:00] SY: Right.

[00:05:01] BD: So after being a Netlify user, I was like user number 8,000 or something. It had been around for at least 18 months or a year at that point. And they reached out to me because at Netlify they could see what’s being deployed on their servers and like see all the Netlify URLs. It had kind of like a Twitter esque of like every time a new site deployed, you’d see like a screenshot of the landing page and be like, “Oh, that’s a cool site. Let’s go check it out.” So my site, because I was doing blog posts like two to three times a week, that was the other half of my story is like I was writing blogs every week about what I learned previously. The founder, Matt Billmann, was reading it and he was like, “Yeah, this guy is writing content about stuff he’s learning yesterday. Mostly people wait until they’re experts before they start writing blog posts.” So he reached out. We had coffee near their office and I’ve asked a question of like, “Hey, you reached out to me. What’s the deal? You’re asking all your customers to chat with you?” They’re like, “No, we actually just raised funding. We actually want to hire you.” That kind of took me aback. So we ended up having an impromptu interview, like in a coffee shop.

[00:05:58] SY: Wow!

[00:05:59] BD: Which was pretty surreal. My entire experience at Netlify was pretty surreal. So between my first and second interview, the CTO was hired. So then the CTO giving my technical interview like probably three weeks later after that first interview.

[00:06:11] SY: Yeah.

[00:06:11] BD: And I was like interviewing other places. So I didn’t think anything of it. I wasn’t like short of pressuring them or anything like that. They ended up offering me a role at Netlify and I worked there for two years from seed funding to almost Series B. So I saw the company grow to almost 50 people before I got the email from GitHub saying that I should work for them.

[00:06:30] SY: Interesting. So what was that like being an early employee? Were you hired on as a developer or what was the role that you were in?

[00:06:37] BD: Yeah, I was a full stack engineer. So ironically, like my blog post that I was writing, I was writing Go. So I was writing blogs about like the basics of Go, me learning it because I didn’t have any background in computer science and I was rebuilding computer science constructs, like linked lists and stuff like that and Go. So that’s how I was kind of learning it. So I interviewed building an API and Go to power their domain dashboard, which is a feature on Netlify. And then I was also learning React at this time. And this is like 2015, 2014. So React was pretty new. And they said, “Hey, we know you interviewed using Go, wanted you to be a full stack dev. But no one’s writing JavaScript here. Could you convert this Angular app into React?” AngularJS was converting over to Angular 2.0. So my job was to create the entire dashboard in React, and I did that. It took about three or four weeks, and then I just started shipping new features in the dashboard pretty much every week at that point. And then I was an engineer, but then they liked my blog post. So they’re like, “Hey, just write blog posts about what you build.” And I was like, “Yeah, that’s exactly what I want to do.” Like do company blog posts about how we’re building engineering concepts and stuff like that and how we use React. My goal was to eventually speak on stage at a conference, and that’s exactly what happened. I had started speaking on stage and there was a correlation between every time I wrote a blog post or spoke on stage and user signups. So they were just like, “Hey, could you just like continue to doing this?” And I told them, “No.” So I was like, “I just want to be a full-time engineer. I already know I have the skillset of doing like the sales and the business, but I didn’t want to get pulled away from engineering. So six months later, we hired our second front-end engineer. And they asked me again, I was like, “Okay, you asked me again. Obviously, there’s a correlation and eventually I’m going to get burnt out and not be able to do everything at this company. So I’ll just do DevRel,” which I didn’t know was a thing. They pitched me on being a developer advocate. So Netlify is actually crazy because like they’re one of the premier developer experience companies where they have like DevRel and engineering mixed together as a role and that’s what I was, the entire time I was there. I was doing DevRel and I was shipping features and did that for about a year until I spoke at GitHub Universe. And one of the engineering managers reached out and was like, “Hey, saw your talk. Would you like to work at GitHub?”-[00:08:45] SY: Nice. Okay, so let’s move on to GitHub because it’s not that many people that get to work at a successful company that’s very loved, very popular in the dev community that also gets acquired. That’s a pretty big deal. Tell me what that experience was like being an employee and then going through that acquisition.

[00:09:03] BD: I mean it was pretty surreal. Like you read about all the tech crunch articles about acquisitions and IPOs and the chance of your company that you’re working on getting acquired or even IPO, like there’s not a huge gate of a bunch of companies going public and stuff like that. So like when that happened at GitHub, I joined, it’s funny because I got into engineering because my son was being born. My daughter was on the way. So my wife was like three or four months pregnant and at the time I was like, “Ah, I don’t know if I can do startup life and have a second kid and live in a one-bedroom apartment in Oakland at the time.”-[00:09:34] SY: That’s intense. Yeah.

[00:09:35] BD: GitHub was offering five months off for paternal leave.

[00:09:37] SY: Wow!

[00:09:38] BD: That honestly was the biggest catalyst on why I left Netlify to go to GitHub because I knew I can get time off at Netlify and I was doing a lot of good work, but having benefits and finally having a job that working at a startup I guess nowadays is kind of weird because you do get like the six-figure startup salaries. Back in 2018, that wasn’t realistic to get out of startup. So I was able to get a huge pay bump, but also five months off when my daughter was born. So in July of 2018, she was born and I took five months off. But the crazy part is June of 2018, there was a rumor and then eventually announcement that Microsoft was going to acquire GitHub.

[00:10:11] SY: Wow.

[00:10:12] BD: And I was like blown away. And I’m like, “Oh man, do I still take time off? What’s going to happen?” And when I came back, I was working for Microsoft.

[00:10:18] SY: Wow! Oh my goodness. So you didn’t get to deal with, I guess, the transition itself. You kind of got to skip the rocky ride and get to the finish line. That’s really nice.

[00:10:25] BD: Well, I mean, the way it works with these acquisitions, like all the due diligence for the SEC and the FTC and stuff like that, it takes some time and there’s really no updates. So Microsoft announced that they’re acquiring, but then it was just crickets. For that entire time, I was out. No one knew what was happening. So by the time I came back, a couple things happened. The deal closed and everyone found out how much their stock was actually worth, which is the other half of working for a startup is.

[00:10:49] SY: Right.

[00:10:50] BD: You get this magical stock money, but it’s not really worth anything.

[00:10:52] SY: What does it mean? Yep. Yep.

[00:10:54] BD: It turned into a very large amount of money for me that I felt very privileged to have that opportunity. But the other thing that happened was GitHub was working on this product when I first started. It came out of a couple different projects to spot out, like Project Everett was the internal name for the bigger project. But there was like a feature in this project, which ended up being GitHub Actions.

[00:11:13] SY: Oh, cool.

[00:11:14] BD: And during that time, GitHub Actions, it went to production and went live right before the acquisition closed. And I had been watching this product the entire time. So right out of me coming back from paternal leave, I became like the DevRel advocate for GitHub Actions.

[00:11:29] SY: Nice! Nice.

[00:11:30] BD: And yeah, it was like a huge career boost and like I got to be again, like I was an expert at Netlify at the time in building the product. I got to now this be focused on onboarding experience for GitHub Actions and it became, yeah, an amazing experience. And like we’ve seen so many other things come out of just that one feature and what’s possible.

[00:11:48] SY: Very cool. So now that you have your own tech company and you’ve had such an incredible career working at these great companies at different sizes, and I’m sure you’ve learned lots of lessons along the way, what have you taken from your experiences and what are you applying to your own company now?

[00:12:04] BD: Yeah. I mean I learned a ton working at startups and seeing how the world works because I mentor a lot of devs and I have conversations every now and then just in the general Twitter and Open Sauced community that I’ve been sort of maintaining for a while and really understanding how like the world of software and business works. The thing that I’ve taken away is I like working at companies that I can use. And it’s kind of been like the difference of my career is that I didn’t go to a finance company to a tool that I never would sign into. I’d always been working at developer tools that, even the bootcamp I worked at, I used that bootcamp software to learn iOS programming while I was working up the job. So the thing I’ve taken away is like just be excited about what you’re working on. And if you’re not excited, for me, I just go move on to the next thing and take that opportunity. So GitHub being the thing that everyone learns how to program and how to leverage and collaborate with your team was a thing that I used a lot. So being able to see how literally that sausage is made, made it so insightful because now I’m running product and I’d have someone who I brought on to run engineering now, but like I’m doing all these like automations and using actions and like we’re using free compute, like our infrastructure’s pretty cheap because we’re just using a lot of the tools I learned how to be an expert at for the past four and a half years.

[00:13:17] SY: Very cool. Tell us a little bit about it. What are you working on?

[00:13:20] BD: Yeah. So I built Open Sauced in 2016. It was a CRM tool to maintain my open source contributions. In 2020, someone reached out to me and was like, “Hey, could you add signup to this? So I could also maintain my open source contributions.” I’ve always had the goal of getting more people to do open source, but I found as a big gaping hole of projects, especially ones that come out of companies and doing open source properly. So we built a tool and we partnered with DigitalOcean during Hacktoberfest to get insights in open source contributions. So every project that was opted in the Hacktoberfest in October, you could see how many PRs were, like who were the top contributors across the entire hackathon. That’s something we’ve actually been building as custom dashboards for any company or any maintainer to use. So you could sign up to Open Sauced and pick your repos and get insights on that. And that’s pretty much the focus today. And then where we’re moving towards is we want to bring more people in the default for open source. So pretty soon we’ll have individual user profiles to be able to track your contributions and then celebrate that through either generating a resume or to get recommendations for places to contribute to.

[00:14:24] SY: So we talked a little bit earlier about how you are conservative and you like to play it safe was just completely understandable for anyone, let alone someone with the family to take care of all that good stuff. What gave you the leap of faith to finally start your own thing?

[00:14:40] BD: That’s a good question too, as well, because like I definitely spent time, I guess climbing the corporate ladder. I left as a director of developer advocacy at GitHub and what really gave me this sort of momentum is really, I had a very decent amount of savings. So if I had to bootstrap this thing and not take a salary for a couple years, like I could do that. So that was like sort of confidence that give me to even consider this. But then also, I kept saying a need of people talking about open source and like how hard it is to get involved and no one really knows like what success looks like at open source. And I started defining this in some conference talks I was doing and some blog posts I was writing. And I’ve had this Open Sauced product for a while. So it just made more and more sense for me to say, “Okay, if I’m going to do it, it’s going to be now. So might as well just start this thing.” And then a couple things happened last year, the CEO of GitHub stepped down and now works on his own stuff and he does a lot of angel investment. The majority of the leadership team left and moved on post-acquisition in GitHub last year. And they all went to VCs. So what I did is I reached out to a lot of them and was like, “Hey, I’ve got this idea. I don’t know if this is VC ready or it’s going to be scalable, but here are a couple ideas and here’s what I built so far.” And they got an overwhelming signal that like I was onto something and that this would be useful at GitHub as a feature. I think a lot of what I’m working on would be useful at GitHub. But the focus at GitHub right now is really focused around some of these more forward-thinking, future of developer engagement tooling like code spaces and copilot and actions. But the sort of onboard ramp in the open source, that’s the thing that was missing on the roadmap. So when the roadmap was launched earlier this year, I saw a very gaping hole of like, “This is what I want to work on. This is what I want to engage community with,” but it’s not represented right now in the roadmap. So those couple things got me to basically do one thing, which is take a sabbatical at GitHub. So I took three months off in the summer and handed over my team to my manager and started working on this problem. And then I partnered with DigitalOcean to ship, at the end of my sabbatical, shipped this product. And the product had good feedback and at that point I made the decision to not go back to GitHub and pursue this full-time.

[00:16:44] SY: Wow! Good for you. I appreciate the steps you took to kind of test the waters and to really make sure that you had something that people responded to. You got some good feedback. You put it out there. You had a partnership. So I respect that. I think that’s really cool, instead of just kind of jumping in and hoping that it works. You took these little baby steps to kind of really test it out. That’s good. That’s good for you.

[MUSIC BREAK]

[00:17:26] SY: So I want to dig into open source a little bit. I think that open source for people who are not familiar with it cannot make a lot of sense, just this idea that there are all these people all over the world, millions of developers writing code for free without getting paid for an unknown amount of time for other people. And not just other people, but for other companies, for legitimate organizations to then use doesn’t feel like a very logical thing, but yet it is here. It is thriving. How do you describe and explain open source for people who may not be familiar with the concept?

[00:18:05] BD: Yeah. So I mean, the open source movement came out years ago. There’s like definitely who people cite like Richard Stallman and Tim Berners-Lee. I honestly don’t put too much like weight into those folks. I think they’ve done great stuff, but I think if we continue to focus on those folks, we can never progress forward. So open source of a sense is like literally just having your code source open. You could see the code and people could view it. Now there’s other variables on open source where there’s like community and collaboration and an open roadmap and foundations and licensing. Those are all extra variables that they definitely make sense to pay attention to. But if you take open source, open source is also like you do ship code for free and you’re a part of community and there’s no sort of guarantee that you’ll get payment for whatever work that you’re doing, potentially a company can take your open source code and build an entire startup or business and make billions of dollars without the need to even ask you permission. With that being said, I do a hundred percent think open source is a valuable thing for everyone’s career and that’s why I’m working on this product. But if you take that same lens about open source and like this take the game of basketball. So if you wanted to be a successful player on whatever team, whatever level, there’s pathways for you to be better at basketball, and usually it comes out with practice. So you could practice by yourself and shoot free throws and never talk to anybody. And a lot of people do that. In coding, it’s like LeetCode. Do a bunch of LeetCode. Crack a coding interview. You’ll be good. You’ve read all the books. You’re excellent. Perhaps someone’s going to give you your job. But when it comes to like basketball, you have to start playing with other people to eventually get better. You have to see what else is out there. If you saw LeBron James was doing pickup games across the street from your house, you would be there if you want to truly be the next great basketball player or at least just get paid to play basketball. And I think with open source, it’s the same thing. Will you see the best developers? In the entire ecosystem in engineering, whatever corner of the internet or whatever you work on, you’ll see the best developers do really cool things. We’re seeing what ChatGPT gets shipped from Sam Alton and OpenAI and Stable Diffusion. All the stuff is being built in the open. You could see the code base and get conversation going about how this is working. And that’s where I see open source. Open source is so much opportunity. And I think if we strip all the layers and the labels away from that, at the end of the day, it’s opportunity to grow your career or get exposure to something new.

[00:20:25] SY: Very cool. So tell me more about, I just love this framing of it being a team sport because I think that when we talk about open source, a lot of the conversation is focused on the code and the fact that the code is open and everyone can see it and anyone can use it within certain parameters, depending on your license, et cetera. But I really appreciate your point that it introduces you to a team and you have the opportunity to potentially play for the team with the best players and the best team and learn from them. And I think that’s a really cool framing that I don’t think I’ve heard before. So tell me about your focus on open source during your time at Netlify and GitHub. Where did open source come into play? Were you, yourself, making open source contributions? What was your experience in that world like during that time?

[00:21:15] BD: So the experience, it’s even sooner. Probably a year after my first job, I had an opportunity actually to the CodeNewbie community when it was a Slack channel.

[00:21:22] SY: Yeah. Yeah.

[00:21:22] BD: I connected with a few other folks and we wanted to build a new Slack channel for underrepresented folks in STEM. And I had this idea to use Slack to then auto invite people into Slack, because 10 years ago, like Slack, you had to manually put emails in, other people you wanted to invite, and it was very strenuous and took a lot of time. So I wanted to create a server to then submit into a form to then auto invite people in email.

[00:21:45] SY: Yes.

[00:21:45] BD: It’s trivial now because Slack does this by default. But I found Node to make this work. And the way I did this is I found something on GitHub that someone built that actually made it work. I just had to know how to use Node. So I’m getting to a point where I didn’t know how to get to the work. I emailed the developer and they’ve responded back to me with like answers and like mentored me on how to use node code. And from that point on, I started doing way more JavaScript because I had a better understanding and I got this free mentorship on one weekend and they just told me everything I needed to know at that time just in time. With that same experience, I would always go in the projects and ask questions, open issues like be friendly, but also answer questions if I needed the answer as well. So at block, I actually created this program, which is an open source apprenticeship where I would work with folks who would graduate the program, they’d spend an extra six weeks with me and we’d contribute to open source. And I saw so many folks do this program with me and get their first job pretty quickly.

[00:22:42] SY: Oh, that’s cool.

[00:22:42] BD: Because I had a person who contributed the Go GitHub, which is a go library to interact with GitHub’s SDK or API. and they were contributing upstream to that. And like I’d never written that much Go, and I’ve never contributed a project. But I gave them all the steps on how to interact with the maintainers and how to get notice and how to properly ask a question. So when I got to Netlify, it was the same thing. I was like the only person shipping front-end code, but I had to ship stuff to production. So if I got blocked, I’d go get free mentorship from another open source maintainer and like we’d end up striving up a conversation and I’d shipped their entire documentation then to Netlify. During that time, I talked to the React team, which is kind of mind blowing, like they were just so accessible, but I got them to actually ship their entire docs to Netlify at the time.

[00:23:25] SY: Wow!

[00:23:25] BD: I don’t know if it’s still a Netlify, but it was just like those engagements just kind of helped me to grow my career a little faster. and get mentorship where I got good mentorship from my bootcamp. But I just kept getting way more from industry professionals. So that’s what I did. Even at GitHub, I was able to have conversations with some of the biggest maintainers on GitHub and in the ecosystem and ask them questions on how to build things, actually it was called Open Source Friday. So every Friday we’d met on Twitch and we talk about a maintainers project.

[00:23:56] SY: So I can just hear the passion and I can hear the enthusiasm for open source. What is it about open source that gets you so excited?

[00:24:05] BD: I think so, when I learned how to code, I was 27 years old and I felt like I was like so far behind. Most people are going to the college with like a little bit of understanding. I’d ship MySpace pages and stuff like that. Did some CSS here and there. But I was like, “Ah, man, if I started 10 years ago, I’d already had my second startup going.” So what I found is like there’s a shortcut and like if there was a shortcut for me to accelerate my career, and that’s from engaging with open source maintainers and getting this mentorship, I want to also give that to other people. I just talked to somebody today who was laid off for the second time this year and they’re now on the job market again. And I was like, “Hey, have you considered like contributing open source?” Because like in the last year and a half that I’ve been doing Open Sauced to, even at GitHub, I’ve seen multiple people take their contributions on Open Sauced, put it in their cover letter and get a good first look from hiring managers. And the thing about open source is like when you come out of bootcamp, you have nothing but greenfield projects. You’ve got some sample projects here, maybe some team projects there, but they all look the same. They kind of look like everything else you do in a bootcamp. But when you do open source contributions, you get real life work experience on a product or a library that has real life users in an established legacy team with tech debt. You can’t manufacture that in a bootcamp, but you can literally walk into an open source project and get real-life work experience. And when I tell people that in the Open Sauced community, they’re like, “Oh, I never thought about it that way. Because most people in open source are like all my interview projects, I put an open source. Because that I figured is open source. People can see it. But what if there were some projects there that you had some pretty heavy hitting PRs or maybe some small PRs on a big project? And I was able to do contributions to things like Node.js and Webpack and React Native just by asking questions to the right people.

[00:25:50] SY: Yes, absolutely. I was looking at a job posting for an entry level developer job, and even at that level, entry level is never purely entry level, right?

[00:26:01] BD: Yeah.

[00:26:02] SY: It’s always like a fake entry level, but it was asking for experience and asking people if they had contributed to maintenance or deployment of code in production. And I’m thinking to myself, “If you’re an entry-level developer, if you’re new, if you’re a code newbie, you’re just getting started, how are you supposed to have access to maintaining and deploying production ready code?”-[00:26:28] BD: Yeah.

[00:26:28] SY: You know what I mean? Like it felt so outside the reach of someone being able to do it on their own. But the way to get that experience is you just put it. It’s through open source, because guess what? Open source, especially those bigger projects, they are deployed, they are in production, they are being used, they do need maintenance. So that’s an opportunity to get that experience without getting the job and being able to build those skills, build those muscles ahead of time.

[00:26:53] BD: Yeah, and what’s even crazier is like once you really zoom back, the people who are maintaining some of these projects work at the companies you want to work at.

[00:27:01] SY: True. Yep.

[00:27:01] BD: So if you wanted a referral to get in an interview at somewhere else and you did good work. And a lot of times, and that’s the other thing I kind of stress with a lot of folks, a couple things I stress, you kind of have to do a second good first issue or a second issue because everyone does one issue. Everyone will go to their project and be like, “Okay, I did it. See you later.”-[00:27:19] SY: Done.

[00:27:20] BD: “Don’t talk to me ever again.”

[00:27:21] SY: Nailed it. Yeah.

[00:27:21] BD: I was talking to one of the staff PMs at GitHub. He maintains Node.js. He’s on the core team. We were talking about this all the time. It was like people, they want to contribute. They want to feel like they’re established, but they just like ghost you all the time. So then now the team’s like burnt out because they tried to mentor somebody new and then they disappeared. But if you like just did a second, like there’s an individual who works at GitHub. They were interning at GitHub and they finished their internship project so early that they asked around like, “What else can I work on?” And they’re like, “Hey, we’ve got this project called Electron. Do you want to see if you can help out there?” And they ended up shipping like tons of features into Electron and maintenance stuff to the point where instead of going back to school, they went back to school and then had a part-time job at GitHub maintaining Electron. So they had two semesters worth of contributions. So when it came time to offer them job, it was like pretty obvious. They’re not going to be white-boarding because like their entire work history is like there in the commits. So why are we going to put them through a coding test? Why don’t we just test to see if they can work with a team and can collaborate in Slack as opposed to like put them through another LeetCode test or another HackerRank test?”-[00:28:29] SY: How do you feel about the common advice that I’ve seen pop up over the years of, you know, if you’re trying to figure out your first contribution, want to get started in code, fix a typo, fix some type of grammar mistake, use that as kind of your way into the project. How do you feel about that advice?

[00:28:45] BD: Yeah, I mean, this might be controversial, but I don’t think that’s the best advice. In Open Sauced, we call them typo hunters. I think it’s valid that if you’re using something and you got blocked or you were discovered a typo, like that’s helpful. Like I got a PR today, there’s a comment in our code that has a typo, like there’s an extra C in a cross. Thank you so much. But also we’re probably not going to merge this in because it’s not breaking any code base. There’s no build that’s failing. And at the end of the day, we’d love for you to be way more engaged in our community and showing that you like, “Hey, I tried to actually run this locally and it didn’t work.” “Oh, can I show you how to fix this?” “Would you mind fixing it?” In Open Sauced, like I have the mantra of every good first issue should have an answer in it. So all my good first issues, they all have literally the line of code and the code that you should write. And if it’s wrong, let me know. I stream twice a week on Twitch and I go through issues and I call it Issues with Brian and I just go through them and just put answers in it. It doesn’t take a lot of time for me to go and be, “Oh yeah, I know what’s broken here,” because I’ve been building this thing since like day zero. But that way anybody comes to the project, they’re like, “Oh, I did a good first issue. Can I do another one?” “Yes, please. Do another one. Do you want to try something harder?” And like we sort of step people up into progressively being part of the community. And then at the point that they end up like either leaving or getting their first job or going to their second semester at college or whatever it is, they have a good foundation of like, “I know how to interact on GitHub.” And that’s something that we are really doing a good job at. And when we preach, go ahead and do a typo or a fixed documentation, I think that’s it’s valid. Yes, go fix typos, do documentation, but also use the project. And there’s so many people who are just fixing typos that won’t clone the repo and run it.

[00:30:22] SY: Interesting.

[00:30:23] BD: Or they won’t install it into their project. And what we need is more people using stuff and also fixing stuff, and that’s really where the community comes from. It’s less about just doing a PR for the sake of doing a PR.

[00:30:33] SY: What you said that really resonated with me is this idea that it’s not fun or all that helpful from the core maintainers perspective because when I think about your first open source project and your first open source contribution, I’m thinking about it from the contributor’s perspective, right? And what I didn’t think about is as the maintainer, if all I’m getting are these one-word grammar fixes, one-word typo fixes, that’s got to be kind of annoying, especially if I’m opening up my issues, maybe I’m excited to see all this help that I’m getting and I see that all of it is, you know, “Oh, you have an extra “S” at the end of the word.” I can imagine that being just a frustrating experience. And so I like the exercise as a way to maybe practice using GitHub, practice figuring out like where all the buttons are and how do you do these things. But if your ultimate goal is to be an open source contributor and to put that on your resume, use that to learn, use that to level up actually be helpful to yourself and to the community, that’s definitely not where you should end.

[00:31:40] BD: Yeah. And this is like we’re building something that we want to be able to validate contributions in a way that actually shows meaningful contributions. So there is the big push for people to create these like Hacktoberfest repos to do the practice and I think it’s valid. If you have a community and you want to teach people how to do open source, that’s a good first step for a lot of folks, but we have to evolve past that where we can have actual projects that also adopt those. “Hey, we’ve got this small extension library and this is where we take first contributions.” That’s the other thing I push for, like folks don’t go contribute to Node.js Go contribute to Node.js polyfills. And Node.js polyfills are TC39. Every year they sit and/or twice a year they sit and talk about new features in JavaScript and then they create these small node libraries to then test these features in JavaScript. And the contribution to those small features in JavaScript with the testing, the release, like pull request review and all that other stuff, it’s shockingly low. If you want to make a really good contribution, go test the next features at JavaScript and report back. Write a blog post on it. You will get noticed and you will get invited to these meetings if you start really testing the stuff out. I’ve spent a lot of time working with early contributors, early devs, and I feel like we’re doing injustice to a lot of these folks by coercing them to think that they’re doing open source contributions, when in reality all they’re doing is just adding noise. If we can sort of like reduce the noise and start the conversation, like through comments, through community, like every open source project now has a Discord, it’s so much easier to sit in a Discord, watch a conversation and then someone drop an issue in there and say, “Hey, we need help on this. Does anyone want to meet with me and see how this is going to get fixed?” And this is like going back to my LeBron James pickup games, like I played sports in high school like the best way. If you’re a second string or a third string or a bench player, it’s like stand up next to the coach. And wait until the coach wants to run a play inside. He will pull you and then next time it’s a free throw and you’re in and you get to give the first string person a break and you can stand up and like start testing out stuff and reviewing PRs and triaging issues. But I think there’s a lot of fear when it comes to open source because it feels so daunting. But my whole career has been just put myself in a position that people will notice me, like through blog posts, podcasting, conference speaking, and then eventually people ask me, “Would you like to work on this with me?” And every job I mentioned that I had, like I’ve never applied to, including my first job. Every job has been somebody found me through something I did, either through Twitter or through conversation or a podcast. They reach out directly and then they ask me if I would like to work there. And I think there’s like so much opportunity. Obviously, past performance is not predictor for future growth, but there’s an opportunity there and not a lot of people are doing this.

[00:34:32] SY: Coming up next, Brian talks about fear in open source and learning through rejection after this.

[MUSIC BREAK]

[00:34:53] SY: You mentioned fear, and I think that fear is very big when it comes to open source. It almost feels like I’m walking in on a party I wasn’t necessarily invited to. You know what I mean? It’s like an open invitation party, but I don’t really know anybody there and my friends are not there. And it feels very daunting and I think that there is just a lot of just straight up fear attached to contributing to open source. How do we break through, deal with, confront that fear and get past it so that we can enter this world of open source?

[00:35:29] BD: Yeah. I mean, it really just comes down to like what I learned is by just seeing other people doing it. So finding people that are doing this and asking them questions, but really community like Becca has been doing Virtual Coffee for a couple years now, and this is literally a group where you could talk with other people looking for jobs and like early devs or maybe you’re looking for your next job and they chat. They chat about like what they’re trying to accomplish. And there’s like so many communities like this and like usually the first thing, like when people ask me questions about how I can do this or how I can do that or how I get my next job or can you mentor me, my first question is always, “What communities are you a part of?” If it’s just you and me and this is a community, like I’m going to get burnt out. So the best thing you could do is like find places where it’s comfortable, a safe space. So if it’s a community or a Discord or maybe another person and join their community, have a safe space to ask these questions and find out like what realistically it looks like to make contributions to level up, to interview, to get your next job. And that’s my recommendation. It’s like find community so that way you can eventually get enough confidence to then speak up in the community or even ask people for assistance and help.

[00:36:32] SY: And how do you find those communities?

[00:36:34] BD: Yeah, good question. Man, there’s so many different ways. First thing I did when I joined, I guess, Dev Twitter, is I Googled Top Ruby developers on Twitter. And I followed all of them. And eventually I started learning, “Oh, this is where people hang out and this is where people have conversations and these are the people who write blog post and this is where I can comment on this.” If you want a friend, you got to be a friend. So the best thing you do is comment on other people’s work and comment on other people’s code, on their blog posts, or their conference, or the YouTube videos. And just be friendly. Say, “Hey, you did a good job.” It’s amazing how many times I have a friend, James Q Quick, he always takes screenshots and shows like when people are very negative in his YouTube comments. But in reality, there’s so many other positive people, but he’s just like, “Yeah, this is funny. People just take all the energy and just want to say something negative about the way someone looks.” So instead, be that positive voice, be like, “Hey, you did a great job. I love how you approach this code base.” Or, “I tried this out and it worked for me. Thanks so much for doing this.” What I was doing on Twitter for a very long time is I would always try to tweet every day, but also I try to comment on someone else’s tweet at least once a day. And it’s funny how often like people will follow people on Twitter or be part of Discord and just don’t participate, which I think there’s obviously social anxiety and like people have other stuff they have to deal with if it’s not natural for them. But just by doing the one ritual of just responding to one person, it feels like you’re part of something, when you reply to someone’s tweet or you comment on a YouTube video. That’s my recommendation. Push yourself to comment on one thing a day, on one developer content or one community piece, and then you’ll eventually get noticed and people will start commenting to you and having a conversation and then you have that comfort to be like, “Okay, can I ask you a question? And that’s a better, rather than getting a cold DM of like hi or please mentor me, it’s so much nicer when people are like part of the conversation and part of the community. I’m so much more amenable to helping out people who I see a lot.

[00:38:30] SY: Yeah. And I’ve also heard, someone said this to me recently where they said people want to help people who are helping themselves.

[00:38:37] BD: Yeah.

[00:38:37] SY: And I think there’s so much truth to that. And I think that when you see someone who’s actively trying to be in the conversation, replying part of the community, who’s kind of doing their part as a fellow community member and they reach out to you and they say, “Hey, I’d love to ask you a question or get your advice on this specific thing,” whatever it may be, and you can see that history of their own community activity. It makes you want to support them because you know they’re doing their best and you want to kind of be a part of that journey. So I think that’s also something important to keep in mind.

[00:39:08] BD: One hundred percent.

[00:39:10] SY: So I want to get back to what you said a couple questions ago where you said, “I have not applied to any of these jobs.” These are all jobs that someone reached out to you and got, because I’ve heard people say that before and I don’t know what advice comes from that, because on the one hand, that almost sounds like applying doesn’t matter, which it feels like not the right takeaway. And I’m also wondering how scalable is that. If I’m participating in community, I’m doing my blog post, I’m contributing and I’m just kind of waiting to be found, there’s something about that just doesn’t quite feel right either.

[00:39:47] BD: Yeah.

[00:39:48] SY: So what’s kind of the lesson there? When you say I didn’t have to apply to anything, I did these activities and people kind of found me, what’s the takeaway? How do we take your story and take something from that that we can apply to our own lives? What do we learn?

[00:40:01] BD: Yeah. And I would say like you miss a hundred percent of the shots you don’t take. So you should be applying. Don’t take that away. Definitely apply to whatever cadence that feels sustainable to you. But all those jobs I apply to, like I didn’t get. My story is basically that. But I did get really good stories and good looks and then people would then introduce me in other ways. So like I didn’t apply the job at GitHub. I got invited to interview. I didn’t actually get that job. And then what happened was like two weeks later is like, “Hey, sorry you didn’t get the job, but there’s another job and it’s in DevRel. We’re hiring our first advocate. Would you like to come back?” And then every time I get a decline in the interview, I always do like a nice, “Hey, thanks so much. This was a great opportunity. I really love this part of the interview process. Best of luck with growing the team.” I send that every time I get a decline for anything. If the VC says no, “Hey, thanks so much. I appreciate it. Good luck with filling out the rest of the portfolio.” It’s like getting back on the bike and like this being cool with like rejection because like if you haven’t failed, then you’re not t trying enough is like also the mantra. But I’d also say there was a story of an engineer who’s like every time he had an argument with one of his engineers, he’d go write a blog post to prove them wrong.

[00:41:09] SY: Interesting.

[00:41:09] BD: And show that they…

[00:41:10] SY: I kind of like that. That’s cool.

[00:41:11] BD: Yeah. And show they had validation. So like when I read that, I was like, “Oh, let me just take a stand, and yeah, I’m not getting jobs. I didn’t get every job that I applied for, but I could share a story of like how I learned something.” So when I interviewed at Pinterest and I had to rebuilt the JSON Masonry, like how the Pinterest cards kind of fit with each other, that was like my coding exercise. Like I went and rebuilt that. After the interview, I rebuilt that and wrote a little blog post on like, “Oh, this is how this works.” Now if I ever get this interview again, I will know how this works. And the takeaway is I definitely don’t want people to start swinging for the fences and just waiting for all the job offers to come in. You’ve got to show up and you got to be present. When I see two bootcamp grads and they both have the same projects, they’re coming out of the bootcamp, how do I pick which one is going to be the one that gets the job? Do they have leadership potential? Do they have mentorship potential? Are they good at documentation? Can they carry on a conversation? Will they disappear and never show up for like the next two weeks until the sprint’s over? Or will they be communicative and say, “Hey, I’m blocked here, I’m blocked there”? How do you sort of pull all those extra non-coding skills? It is combing through their blog posts and seeing if they’re given conference talks and asking their referrals, like their communication patterns. That’s all the stuff that that comes up. And like getting your first engineering job or your secondary next, it would be so much easier if we were getting paid $20,000 a year. But in reality, we’re getting paid six figures. So all these jobs want to make sure they’re making the right decision the first time. They don’t want to get in six months and be like, “Ah, man, this person’s not working out.” It makes sense why there’s so many hoops to jump through to be an engineer.

[00:42:44] SY: Absolutely. Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Brian, are you ready to fill in the blanks?

[00:42:58] BD: Yeah, let’s do it.

[00:42:59] SY: Number one, worst advice I’ve ever received is?

[00:43:02] BD: People don’t look at your GitHub profile.

[00:43:04] SY: Oh, tell me more.

[00:43:05] BD: This is a thing that people are definitely doing, and GitHub’s done a really good job of adding new features to sort of represent like what your code and your contributions are. So I remember distinctly interviewing for somebody and they opening up my GitHub profile and asking me these questions.

[00:43:19] SY: Oh no.

[00:43:20] BD: On the repos I contributed to.

[00:43:22] SY: Oh, wow!

[00:43:22] BD: Luckily, I had like…

[00:43:23] SY: Were you ready?

[00:43:24] BD: Yeah. I mean, all the stuff I wrote to code on, so I was prepared.

[00:43:27] SY: Right. Okay. Good. Good.

[00:43:27] BD: They weren’t just like random clones. But yeah, I would just recommend put the best stuff on there so that way when people go look at it and you have answers to some of their questions.

[00:43:37] SY: Very cool. Number two, best advice I’ve ever received is?

[00:43:41] BD: Open your pull request early.

[00:43:42] SY: Oh, interesting. Tell me more.

[00:43:44] BD: Yeah. So this is something that I push for everyone, at least on my teams that I work with, is like go look at the feature, go try some things, but before the end of the day, open up a PR that’s a draft because what usually happens is somebody else on the team is working on something similar and can provide advice when they wake up in the morning. And this is something that I learned from GitHub. There was a blog post from a GitHub engineer and they were like, “Yeah, we diff early for that reason because we’re all async remote culture.” So if no one knows what you’re working on because you haven’t opened the PR yet, even if it’s not done, there’s a chance that you might be working on something as someone else.

[00:44:17] SY: Very cool. Number three, my first coding project was about?

[00:44:21] BD: Yeah. I mean, the first one, the one that I had the idea to learn how to code was Chuych. It was C-H-U-Y-C-H. And we put the Y in church, basically yelped for churches.

[00:44:30] SY: Oh, nice. Nice! Very cool. Number four, one thing I wish I knew when I first started to code is?

[00:44:36] BD: Open source is a free coding bootcamp.

[00:44:39] SY: Oh, I love that framing.

[00:44:41] BD: Yeah.

[00:44:42] SY: That’s really cool.

[00:44:42] BD: It really is, like people will answer your questions and even give you stuff to work on.

[00:44:47] SY: Very cool. Well, thank you so much, Brian, for joining us.

[00:44:50] BD: My pleasure.

[00:44:59] SY: You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.