S2E20: From Learning Ruby to Starting a 150+ Person Tech Company with Sid Sijbrandij from GitLab

Updated on | Sign up for learn to code tips


In today’s episode of the Learn to Code With Me podcast, I talk with Sid Sijbrandij. Sid is a self-taught coder and Y Combinator graduate. He is the the co-founder and CEO of GitLab, an open source tool used by developers to create and manage codebases collaboratively.

In 2007 Sid was operations director for a company that made personal submarines. He began teaching himself Ruby and started consulting with clients. Eventually, Sid transitioned into a full-time tech career. In the two years since attending Y Combinator, GitLab has grown from a nine-person company into one that now boasts over 150 employees.

In our conversation, we talk about what it takes to keep yourself motivated while learning to code. Sid highlights the importance of attending meetups and finding a supportive community. We also hear his best tips for mastering the tech interview. Overall, Sid reminds us that being fully engaged and passionate about the process makes a big difference.

Laurence:
Hey, it's Laurence Bradford. Welcome to Season 2 of the Learn to Code With Me podcast, where I'm chatting with people who taught themselves how to code and are now doing amazing things with their newly found skills.

Xojo is a development tool for creating native apps for desktop, mobile, web, and Raspberry Pi. Xojo offers lots of resources to help you get started learning modern programming. Learn to Code With Me listeners get 20% off with the coupon learn20. Try Xojo for free at xojo.com/learntocode. Xojo is spelled like Xojo.

Hey listeners, welcome to the final Learn to Code With Me podcast episode in season two. I am your host, Laurence Bradford. In today’s episode, I talk with Sid Sijbrandij. Sid is the CEO and cofounder at GitLab, an open source tool used by developers to create and manage codebases collaboratively. But before his tremendous success in the tech world, Sid was a self-taught coder. He began teaching himself Ruby back in 2007. Inside this episode, Sid shares how he began learning Ruby, how he built GitLab, a company that later went to Y Combinator, and what it’s like managing a 150 person remote company. Yes, today GitLab is 150 people.

Towards the end of the interview, Sid also shares job interview tips for new techies. This is a great episode and I am so pleased to end season two on this note. Remember, you can get Show Notes for this episode, plus a full transcript, at learntocodewith.me/podcast. Enjoy!

Hi Sid, thank you so much for coming on the show.

Sid:
Yeah, thanks for having me.

Laurence:
Great. Could you introduce yourself real quick to the audience?

Sid:
Yeah. My name is Sid Sijbrandij and I’m the CEO of GitLab.

Laurence:
Yes, I’m so excited to have you on, thank you again. You have such an interesting story, I can’t wait for the listeners to hear it. I would like to start kind of early on and rewind in time. How did you first start teaching yourself how to code?

Sid:
I saw Ruby the programming language and I purchased the book. It’s called the ‘pickaxe book’ because there’s a huge pickaxe on the front. I went through that book trying to learn Ruby. It was too hard so then I tried Ruby on Rails. It’s a book with a skateboard on the front. That was a lot more doable. I went through that book, did all the exercises, and then about halfway through it got too hard. I knew enough to be dangerous and I started doing assignments and then later on I went through the book two more times. The second time I actually got everything and the third time I actually mastered the subject. That book was a huge help and of course most of the time you’re just getting stuck and googling and looking at Stack Overflow to dig yourself out of the hole.

Laurence:
So what year was this when you first started learning?

Sid:
It was end of 2007. I was working for another company and doing other things. I always thought of programming as something that was tedious. Then I saw some code examples of the Ruby programming language and it looked so beautiful. It looked like art, like something that is, there’s nothing to subtract anymore. I thought, “Wow, this language is making programming a lot more fun, so I should get into it now.”

Laurence:
What were you doing at the time, when you started teaching yourself? Did you have another job, were you a student or anything like that?

Sid:
I had a job, I was operations director for a startup that was making submarines. I guess it wasn’t a startup at the time anymore. I worked there for five years, so this was my last year. We weren’t growing really fast anymore as a company. It was about 15 people. I was responsible for business operations and the electrical systems of the recreational submarines we were building. I slowly transitioned. I started first learning it and at some point I started working part time on the submarine and part time trying to earn some money consulting by developing for our customers.

Laurence:
So wow, you were there for about five years. After that job experience, did you get a tech job right away? Was it right after you learned to code and then you went into tech or did something happen in between that?

Sid:
No, after I had done a few projects myself, through my network, I heard of someone that needed a better website. It was a distributer of hosting tools. I set off to build that website for them. That was my first customer. Of course you don’t have any track record. I did a very low hourly rate for them to make that happen. I did not invoice a lot of time I spent because it was just my inexperience that caused me to spend a lot more time on it. I was able to make what they needed. So that was a successful collaboration. But you need someone in your network to kind of trust you to do the right thing.

Laurence:
Yeah, I love that. I love how you, it sounds like you kind of threw yourself in there to this project and you maybe didn’t know a whole lot at the time, but you googled your way out of it and you ended up making it work. You finished the project for the client.

Sid:
Yeah, and I think projects that are ideal are projects that require a lot of interaction with the customer or that requires some kind of custom thing. If there’s nothing very time consuming there, there may be a better experienced programmer that can quickly flesh out the project. If it is something that will also cost an experienced programmer a lot of time, you’re a better fit for the job, because your time is way less expensive. In this case, what they wanted, they had an existing database that they wanted to import or synchronize to their website. The product names and everything had to come from this database and this database was undocumented. We just had a database with some column names and I had to figure out what actually reflected the stock position and what actually reflected the price. It sounds easy but it was super hard because it wasn’t a set price. The price was calculated based on numbers, discounts, and other stuff. I kind of had to reverse engineer the existing program and it was not necessarily a programming job, you feel more like a detective trying to get there. That means that I was as effective as an experienced programmer would have been, so that made it a really good first project.

Laurence:
Do you remember at all how long it took you to do that first project?

Sid:
It was many months. I’ve kind of shut down the business, not completely, but I’m now a full time CEO so I don’t have time any more. It was so hard to replace the project, that server and that website is still going on today. Once a year I send out an invoice for keeping that server online.

Laurence:
Oh wow, so the thing you built, in what year was this? 2008 or something?

Sid:
Exactly.

Laurence:
Yeah, so it’s still up online today and you still invoice for it, for the server. That’s a great story. I always tell people all the time, one of the best ways to learn is through building your own projects or of course doing client work or building them for other people.

Sid:
Of course, the first thing is probably you playing around and doing a few projects for yourself, but client work is really nice because there’s this external pressure to keep going, to deliver something. Programming, when you learn it, it is very hard to stay motivated. By charging people for it and having a project that you have to finish, you remedy some of that. It is like your external motivation to keep going, so I think that was very helpful.

Laurence:
Yeah, I love that. I think so many of the listeners can totally relate. When you first started learning, how did you stay motivated? Was it doing the client work? Was there anything else you did to push along?

Sid:
I went to meetups around Ruby on Rails and I think that was really great. What I hear when a lot of people are starting to learn to program, they think they have to learn everything before they go to a meeting. That’s not the case. Most of these meetups are just organized by people who are passionate about it, so as long as you’re passionate about it, you’re welcome there and it’s okay to ask stupid questions. I think that really helps, seeing other people that are excited about things.

Laurence:
Yeah, without a doubt. At this time when you were learning and started building these projects and then attending meetups, where were you living at the time?

Sid:
I was living in the Netherlands, so the meetups were mostly in our capital city in Amsterdam, so I traveled. Mostly in the evenings so you go there for dinner, have a pizza and attend a meeting, network with people and go back home.

Laurence:
Yeah, that’s cool. I was asking that because I know you now live in San Francisco. I was curious, when did you end up moving to San Francisco?

Sid:
I ended up moving in 2015 at the beginning of the year, because we were attending a program called Y Combinator. It’s an incubator for startups. Alumni include Airbnb and Dropbox and Stripe. And we got into the program for three months so we moved the whole company there. Afterwards we took investment and I stayed in the US for the majority of my time.

Laurence:
And this is really ironic because the episode before yours, the guest was also into Y Combinator, which is just by chance. I think you guys are the first two people on the podcast who have gone to Y Combinator. Or both had companies that have gone through the program. That’s kind of funny it ended up being right next to one another. In any case, what was the experience like? I kind of want to rewind a little bit, so you had started GitLab before you moved to Silicon Valley, and then you moved to Silicon Valley to do Y Combinator through the company GitLab. When did you first create GitLab?

Sid:
GitLab was created by my co founder Dimitri. He thought, “How hard can it be, I’ll just make my own.” He was living in the Ukraine at the time, being part of a consulting company with 200 people. I saw it a year later, I thought, “This is a great idea, I should become part of this.” I started running GitLab as a service, so gitlab.com. Most of the people were and still are running GitLab themselves. You can just download it and run it on your own server. Then a year later, I learned that it was pretty hard to make money with a website, but there was a lot of demand for additional features. When Dimitri tweeted, “I want to work on GitLab full time” out to the world, I emailed him, “Great, I’m this guy that emailed you a year ago that was starting gitlab.com, can I pay you to start working on it?” He said, “Sure,” so I ended up wiring him a monthly paycheck to get going. That was a success so a year later we incorporated and a year later we got into Y Combinator.

Laurence:
That’s so awesome. I apologize Sid, because you actually cut out very briefly right when you began talking about it. What did you say your cofounder started it as?

Sid:
My co founder needed something like GitLab for his day to day work. So he just thought, “How hard can it be, I’ll make it and I’ll open source the code.” Pretty quickly people started contributing to it. By the time I saw it a year later, it had already had hundreds of people that contributed to the codebase.

Laurence:
Alright, awesome, thank you for clarifying that for us. When you moved to Silicon Valley and attended Y Combinator, what was that experience like?

Sid:
It was amazing. It’s kind of hard to explain because I’ve seen so many people that attended Y Combinator and are raving about it. I thought, “Is this something, that they’re all being so positive?” Then I attend myself and I find myself to be one of those people. Many people think that an incubator, they have a big place and everybody works from the same place, but it’s not like that at all. They encourage you to work from your own location, so we rented a house in Mountain View and we moved everyone in the company there. It was a very intense period where you just focus on growing your business and going faster. It forces you to remove any speed bumps there are in your company. At a certain point we were going so fast, releasing so many new features, that the one person that did join us was like, “What happened to you, what is happening?” We kind of found a new speed. We worked hard, but it wasn’t so much putting extra hours in, but just really confronting yourself like, “Why is this taking so long, can we find a way to do it quicker? Can we get this out sooner?” At Y Combinator, apart from pushing you to go faster, they also advise you on all the mistakes you commonly make when you start a startup. After you graduate, you’re kind of prepped to deal with investors, to deal with sales, to deal with marketing. It was an enormous change for us. From 2011 to 2015, the company grew to nine people. From that time, within two years we grew to 150 people. It really accelerated our company.

Laurence:
Wow, how big was the company when you went to YC?

Sid:
When we were in YC we were nine people.

Laurence:
Nine people, okay. While you were there, did you hire anyone?

Sid:
No, and actually they discourage you from doing that. What you do, you try to go faster with the existing people. Hiring people takes a lot of time, so it kind of distracts from the effort, from all the other things you have to focus on. Many companies don’t hire a single person during YC.

Laurence:
Got it, yeah. Actually that does make a lot of sense when you explain it that way, with the program and all. So you were in YC with nine people and that was in 2015. Now how big is the company?

Sid:
Now we’re 150 people and actually we have our summit today, so significant others are welcome here so we have 200 people arriving here today in Mexico, so it’s amazing to see how fast we’ve grown in so little time.

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

Xojo is a cross platform development tool for creating native apps for desktop, mobile, web, and Raspberry Pi. With Xojo you really can just write one version of your app, say on a Mac, click a button, and have a completely native Windows version 2. Xojo lets you extract yourself from specific platform details so you can focus on what makes your app unique. All apps have completely native controls, even if they weren’t developed on that platform. Just use drag and drop to create your user interface in one language to program the functionality. Xojo is perfect for people who aren’t programmers by trade, but who learn to program to make their jobs easier. Users also include Fortune 500 companies, commercial developers, IT developers, hobbyists, and students. Anyone who wants to build apps faster. Learn to Code With Me listeners get 20% off with the coupon code learn20. Try Xojo free at xojo.com/learntocode.

Yes, that’s so crazy. Now you’re at 150 people. I also know from a previous conversation that we had, that the company is entirely remote, correct?

Sid:
Yeah correct. We’re a remote only company. We don’t have an office. We were used to working remotely and what we see in hybrid companies that do have an office and some people remote is that people often feel a bit remote, they feel left out of the conversation. We kind of figured out along the way that we really didn’t need an office. Everyone’s on the same level. We have people in 33 countries and we strive really hard to make sure that we have great communication, both the formal communication about the job, that we write things down and document things. We also try to stimulate the informal communication. We have lots of ways in which we try to make sure that people do feel connected. That being said, it is really fun to have everyone together for a week.

Laurence:
Yeah, that’s really nice that it kind of lined up with this, so you’re with everyone for the next week. It’s usually a remote company, which is also very cool. I know a lot of listeners for the show want to work remotely. I always think that technology is a great way to do that, working in tech and what not. I thought it was really interesting as well what you said about how the hybrid doesn’t work. Where some people are in the office and others are remote, because then the remote people felt left out. So you went the other direction where everyone’s remote so then everyone’s on the same level.

Sid:
Yeah, we think that if you’re in an office, a lot of the communication happens verbally, so there’s no artifact to share of the communication, you’re not recording yourself the entire day. If you’re remote, everything is written down. Now the trick is just to make sure that it happens so everyone can see it. We really try to simulate, instead of direct messaging people, do it in a channel. Instead of sending an email, write it on a public issue tracker so that these artifacts are there for everyone to see. We also try really hard to over communicate. It’s probably not over communicate, but communicate more efficiently than most companies. For example, yesterday I sent our investor update, not just to our investors, but also to everyone at the company. So everyone knows how we’re doing, what we’re working on. We just try to document everything. Our strategy is available, it’s documented on our website, accessible not only to people who are already at the company, but also to applicants in the rest of the world.

Laurence:
Yeah. I feel like communication is such an important part of any job or any company, whether you’re in the same room or same building or remote. It’s great that you write everything down and keep everyone active and engaged. I write and research a lot about tech careers and so forth. I’m just curious, what is it like hiring at an entirely remote company?

Sid:
It’s probably not that different from most companies. I think one of the things that are funny, because we are so transparent, people kind of self select for the way we work and our culture. We got a lot of inbound interest in wanting to work for us, especially for developers. They actually said they want to work remotely, they want to work in a company that’s transparent, so that’s a huge blessing to have a great choice of great candidates. The interview process, we commonly use video calls to interview people. I think that gives a really good, you’re able to see a lot of the same things you’re able to see when meeting in person. It’s not necessary to fly people out. The thing that we don’t see is how high people are because that’s hard to tell, but that’s not something we select for. Yeah, it’s mostly the interview process starts with some questions to weed out candidates, then a call by our two dedicated recruiters. Our recruiters are not outbound, they mostly get with people that are applying and help people with the process. And then a couple of, four video calls before we make an offer.

Laurence:
Nice, thank you for sharing some of that information. Yeah, it doesn’t sound too different from an in person interview. Is there anything someone can do who is interviewing for a remote position to stand out more? I still feel like meeting in person can kind of, I don’t know how to say this, can make a big difference in the application or the interview process. Once you meet someone in the same room, of course the whole first impression, actually feeling someone’s energy, is there any advice you can give someone who’s interviewing for a remote role on how to stand out?

Sid:
Yeah, obviously we want people that are engaged and get results. I think we’re actively trying not too...you’re not recruiting a friend, you’re recruiting a team member. You want to get results. You don’t want to select for people that are like you or that you would hang out with normally. I don’t think the in person meeting would add a lot. It actually might cause us to choose less diverse candidates. I’m actually, we could try not even doing actually video calls, but there’s no much non verbal communication that I kind of like the video calls, otherwise things kind of tend to get lost.

How candidates can stand out is by showing interest that they want to work at our company. If you send a cover letter and it’s the same cover letter you could send to another company, that doesn’t help. Try to make sure that there’s stuff in there that’s specific to this company. As you get calls with people, make sure you prepare a little bit. If you’re talking to someone, you know there’s a lot of information to find. Many people read all the pages that we have in our handbook, that’s not required, but make sure that you understand what division someone is belonging to, what are the things that they are working on right now.

If people invest a bit of time that’s a good indication that they’re thoughtful, that they’re motivated to work at your company, that they’ll be as thoughtful and motivated after you hire them too. For example, for developers at GitLab, a lot of the people we end up hiring are people that contributed to GitLab before. It’s absolutely not a requirement, but if you are interested in contributing to open source anyway and want to work at GitLab, obviously it speaks volumes if someone already has shown that they can contribute functionality to GitLab. That said, we hire a lot of people that have not contributed yet.

Laurence:
Yeah, I have not interviewed nearly as many people as you have, but whenever I’m interviewing someone and they haven’t ever looked at the product, or used the product. At my company Teachable, we have a free version of the product, so it doesn’t even cost money to create an account, it takes 10 seconds. I think that’s a huge, I think it’s a red flag if the person you’re interviewing hasn’t checked out the product at all. As you also said, shown an interest and a passion for working at the company, that can really say a lot about the candidate.

Sid:
Yeah, let’s take a product for a spin. One of my standard interview questions is, “How can we improve the product?” You don’t have to get it perfect but it’s nice. One of the best answer is, “I don’t know, but I use the product to do this and this and that and this is how I experienced it.” That just shows that you’re interested. One funny thing is that, by default, our technical interviews are contributing something to GitLab. So if you don’t want to, we can hand you an alternative assignment, but our technical interview is like, “This is the issue on our public issue tracker, so please make this. This is the same work you’d be doing if you join GitLab.” It does a few things, it causes us to really be able to focus on the results so we get rid of a lot of complexity there, because it’s the same work. It also means that we’re really motivated to judge your work accurately, because if we say it’s okay, it’s going into GitLab, it will be part of our codebase. This is not just some other thing. Commonly you’ll get multiple people reviewing your code. It’s kind of fun that it’s for real instead of a fake whiteboard assignment.

Laurence:
Oh wow, that’s really interesting. I don’t think I’ve ever heard of someone doing that. It’s usually a fake assignment or something that isn’t actually implemented into the product.

Sid:
Yeah, and this is a real issue with all its complexity and all its sharp edges. Make sure that we hire for the skills that we need. It’s not whiteboard, like how do you do a double link list in C or something like that. It’s about you need all the skills you need to have as a developer. So expressing yourself clearly, understanding, working through the problem, asking the right questions, responding to feedback, working with a large codebase. I hope it makes us, and I think it makes us recruit those people that are able to be effective after they join the company.

Laurence:
Yeah, certainly. I feel like it’s kind of, you’re literally working with them. You’re not just seeing their skills, but as you said, you’re seeing if they can express themselves clearly, are they asking the right questions, how do they work with others, can they take criticism. That sounds like a really awesome project you have people work on before they even get started.

Sid:
Yep, and of course for the people that contribute to GitLab without the expectation of a job, if you look at the people that most contributed to GitLab, most of them ended up joining the company eventually. If someone contributed a few awesome features, we’ll reach out to them and say, “Hey, are you interested?” It’s just awesome to have those people do in a paid role what they used to volunteer for before. And getting paid to do something they love. That’s an awesome thing about having a company around open source. There’s plus and minuses, but this is definitely a great thing that you can pay these people to do what they love.

Laurence:
Yeah, that’s really awesome. It makes me think, one of the things that a lot of beginners can do and I think it’s great, is contributing to open source. A lot of beginners, and even people who are intermediate and maybe even advanced, are scared to do that sometimes. Do you have any thoughts or advice on that? On contributing to open source projects?

Sid:
Yeah. Try to find a community that is welcoming. They tend to be newer communities, so if you have a newer technology, it tends to be a more welcoming community than something that is older. Then try to find, don’t bite off too much. Don’t start off trying to make a giant thing. At GitLab for example, you can filter our issues by accepting merge requests, so these are issues that we really welcome code for. Then there’s issue weights, so pick something with a low issue weight that’s easy to do. Ideally, your first contribution to a project should be updating the documentation somewhere. Just go through the flow. Read the documentation, find something that could be better, update it, and just get your first commit in. Then take it from there. Start doing incrementally harder things.

It’s important not to put in a lot of work without getting feedback. If you’ve worked on something for a few hours, share what you’ve done. Hopefully it’s finished, but even if it’s not finished, say like, “Hey, this is not finished, but what do people think?” So that you don’t spend weeks working on something and then getting, “Oh, we’re not really interested in this feature or you took a completely wrong approach to the architecture.” It’s important to pick a community that will give you feedback. See what people are contributing. If people aren’t contributing merge requests or pull requests to the project, see if that is being responded to. That can be a challenge at GitLab, we get thousands of merge requests but we have people full time working on making sure that all these requests at least receive a response and that we take care of that. We can always do better and if you’re not getting a satisfactory response, join the IRC channels or other channels or tweet at the company. Ask, “Hey I submitted this, can someone help me, can someone review it, etc.”

Laurence:
Awesome, thank you so much for sharing that. I’m sure listeners are going to benefit, because I know that’s something a lot of people think about and are oftentimes scared to make the first jump. So, is there any final advice you can give to people teaching themselves how to code, especially as someone who is self taught?

Sid:
Yeah, I think that it’s hard. It’s a very long road. You never know everything. I think a lot of people kind of have the expectation like after a year or two years you’ll know everything. But the more you dig in, the more there is that you know you don’t know yet. At a certain point that you understand everyone is specialized. You can’t know all the things. You can’t understand all the things. So don’t be too hard on yourself. It’s a question of motivation. Don’t try to create motivation by being harder on yourself. Try to create motivation by external triggers. Try to pair up with someone and start learning how to code together. If you can share that journey, it’s way easier. Go to meetups, join a community and contribute to that community so you have familiar people that you can reach out to and that are actually into your work. In the end, you can’t do things by yourself, so try to make it a social thing. That will really help with your motivation, first of all because people expect something from you but also you have someone to reach out to when you’re stuck and you’ll get recognized for your contributions and your increasing skill level. For me, that’s what kept me going.

Laurence:
Awesome. Thank you so much for sharing that. That’s so helpful. I definitely agree that a community is so important when you’re learning and learning alone is never fun and it helps you stay motivated. Finally, where can people find you online?

Sid:
Yeah, so our company GitLab, you can google that, GitLab. I’m pretty active on Twitter. My Twitter handle is @sytses.

Laurence:
Awesome, thank you. We’ll definitely add those links to the Show Notes so people can find you. Thank you again Sid, for coming on.

Sid:
Thank you very much, my pleasure.

Laurence:
I hope you enjoyed my conversation with Sid. Again, the Show Notes for this episode, plus a full transcript, can be found at learntocodewith.me/podcast. If you’re listening to this episode in the future, simply click the search icon in the upper navigation of the website and type in Sid’s name. It’s spelled like this: Sid, that’s the first name. The last name is Sijbrandij. Regardless, if you liked this episode, go to my website learntocodewith.me where you can get even more code related content, like my 10 Free Tips for Teaching Yourself How to Code. Thank you so much for tuning in. Again, this is the final episode of Season 2. Make sure you keep an eye out, or should I say an ear out, because soon a minisode is coming with details about Season 3. Cheers!

SPECIAL THANKS TO THIS EPISODE’S SPONSOR
Xojo: Want to create native apps for desktop, mobile, web, or Raspberry Pi? Check out xojo.com/learntocode and get 20% off with the coupon code learn20.

Key takeaways:

  • You don’t need to learn a lot before you go to a meetup. As long as you’re passionate about the subject, you’ll be welcome in a group of like-minded people.
  • Client work is motivating because it adds pressure to get something done. Don’t try to create motivation by being harder on yourself. Try to create motivation by external triggers.
  • Candidates stand out by showing a genuine interest in a company. Tailor your cover letter so it’s specific to the organization where you want to work.
  • Take the time to prepare for your interview. It shows you’re thoughtful and motivated, which means you’ll bring the same traits to your job.
  • During an interview express yourself clearly, ask the right questions, and respond to feedback.
  • When you’re looking for an open source community, find one that is welcoming. Start off small, ask for feedback, and slowly increase your contributions.
  • Everyone is specialized, so don’t feel like you have to know everything. The more you dig in, the more you realize how much you don’t know. Don’t be too hard on yourself.

Links and mentions from the episode:

Thanks for listening!

Thanks so much for tuning in! Remember, you can listen to the Learn to Code With Me podcast on the following platforms:

  1. The LTCWM website (https://learntocodewith.me/podcast/)
  2. iTunes
  3. Overcast
  4. Stitcher

If you have a few extra minutes, please rate and review the show in iTunes. Ratings and reviews are extremely helpful when it comes to the ranking of the show. I would really, really appreciate it!

Special thanks to this episode’s sponsor

Xojo: Want to create native apps for desktop, mobile, web, or Raspberry Pi? Check out xojo.com/learntocode and get 20% off with the coupon code learn20.