[00:00:00] SY: Whether you’re a true CodeNewbie or a veteran developer, consider using your skills to create tech for good. Be a part of Code and Response, a program started by IBM to bring forward open technology solutions that can help communities in need of critical aid. Learn more and get involved at IBM.biz/codeandresponse.

[00:00:27] (Music) 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 open source and GitHub’s new Sponsors Tool with Katie Delfin, one of the four software engineers who work on the project.

[00:00:43] KD: Having these communities built up around these open source languages were what really helped me find the kind of jobs that would let me do the work that I was really passionate about.

[00:00:55] SY: Katie talks about what led to her working at GitHub, the pros and cons of open source, and GitHub Sponsors after this.

[00:01:08] Flatiron School is one of the best bootcamps around. On-campus or online, you’ll build a community of like-minded coders, and learn the fundamentals of what you need to know to dive into the rapidly growing tech field. Go to flatironschool.com/codenewbie. That’s flatironschool.com/codenewbie to get started

[00:01:30] MongoDB is the most popular non-relational database for a reason. It’s super intuitive and easy for developers to use. Now with MongoDB Atlas you get its flexible document data model as a fully automated cloud service. It handles all the costly database operations and admin tasks like security, high availability, and data recovery, so you don’t have to. Try MongoDB Atlas today at mongodb.com/cloud.

[00:01:55] If you like this podcast, there’s a good chance you’ll also like one of the other tech podcasts I host. It’s called Command Line Heroes and is produced by Red Hat. So if you're looking for some more really fun and informative tech podcasts to fill your feed, check out Command Line Heroes at Red Hat.com/command-line-heroes.

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

[00:02:22] KD: Thank you so much for having me. It’s a pleasure.

[00:02:25] SY: So tell us how you got into code.

[00:02:27] KD: Growing up in school, I always really loved math. That was definitely my strongest subject and I started going to college in a community college in Orlando where I was living and I was lucky enough to get to work in the career center at the college as a work-study student. And so like any student, I had no idea really what I was going to do when I was starting college, but I knew I wanted it to do with math, I knew I wanted it to be something that had to do with problem solving, and I knew I didn’t want to do something boring like accounting. Sorry to accountants out there.

[00:03:05] SY: That’s okay.

[00:03:07] KD: So working with the career counselors, taking a bunch of tests and doing research, I landed on computer engineering and started off learning the program there. And eventually as I started to go down the coursework, switched over to computer science because I didn’t find the hardware side of things to be as fun or compelling. And from there, just kept going.

[00:03:29] SY: That’s really awesome that you went from math to computer engineering to computer science. I love that the career counselor helped get you to that point. What kind of work did you get to do in school?

[00:03:38] KD: Probably the thing that comes to mind immediately is my junior year, one of my first courses at the university level once I graduated from community college was working on a Space Invaders game and it was the first time I’d ever used Java or even an object-oriented programming language. That was so fun. It was the first time where I just spent hours and it was like looking up the clock, “Oh, it’s 2 A.M. now. I guess I should go to bed.”

[00:04:11] SY: Those are the best projects.

[00:04:12] KD: Yeah. I loved it.

[00:04:13] SY: So when you are researching your future and your career working with that counselor, what kinds of coding jobs were you attracted to?

[00:04:21] KD: The great thing about programming as a career is you can really go anywhere. There are problems to solve wherever you go. and probably because of where I worked at the time, but education was really a problem that had my heart from the very beginning. And so once I graduated from school, I went right back to the community college where I started my education and got my first full-time job there and spent probably the next two to four years working in education at different ed tech startups.

[00:04:53] SY: What did you do at those startups?

[00:04:55] KD: I started off at code school. I was an engineer on our .com team. So our team was split into two engineering teams, one worked on the core website and the other one worked on developing the actual courses. So I was over on the side that worked on the website and did things like user management and marketing stuff or even billing. That was my first big project there.

[00:05:21] SY: Neat. And then after that, where’d you go?

[00:05:22] KD: We got acquired by a company called Pluralsight, another education startup based out of Salt Lake City, Utah and I spent a little bit of time there. I even moved out to Utah to be up in the headquarters for a little while. Yeah.

[00:05:34] SY: How’s that?

[00:05:36] KD: That was so fun. It’s very interesting. They’re a lot more mature of a company than we were, which comes with a lot more red tape, but also a lot.

[00:05:46] SY: I was going to say that can be a good thing or a bad thing, right, depending on who you are and what your needs are?

[00:05:49] KD: Yeah. I think it was an adjustment for all of us, but it was really great to be a part of a company that was a little bit more grown up and had a little bit more figured out.

[00:05:58] SY: So why was ed tech so important to you?

[00:06:01] KD: I’m just really passionate about solving problems that help other people create a living and get to invest in their passions. I’m really passionate about getting to improve the lives of other people and helping empower other people.

[00:06:17] SY: And how does ed tech help you do that? Because you can do that kind of in a number of different ways, right? You can be a teacher, you can create content, you can work as a software engineer for other people who are doing that. What about the engineering side of things was so attractive?

[00:06:30] KD: I think the great thing about it is that when it comes down to prioritizing the work that you’re doing, it’s always tying back to the mission. You’re always tying back to how is this going to give our users the biggest advantage and I just find that to be so motivating, especially when you encounter problems that maybe aren’t as fun to work on. If you’re not a huge fan of refactoring things, it could become a slug and you can feel like projects are dragging on but being able to tie that back to what it is that we’re here to do just helps ease that.

[00:07:08] SY: And now you actually work at GitHub, which is one of the biggest open source platforms. Can you tell us a little bit about what open source is and what it looks like?

[00:07:17] KD: So open source is a method of developing software where the code is free and open. It’s just openly available and a lot of the work and strategy behind developing that software is done out in the open. The great thing about it is that anyone can contribute and anyone can benefit and use the software in their own company.

[00:07:41] SY: Open source is such an interesting idea because I think that the mission of creating something and then putting it online and then allowing anybody to use it, you know, fork it, to make a copy of it and do whatever they want with it, I don’t feel like that’s a normal thing. You know, like I don’t think that you draw a picture and put it out in the world and like want people to just take a copy of your image and kind of do what… you know what I mean? It feels special. It feels like, “Hey, that’s my thing I don’t want to share it,” not necessarily something that I want people to work on. So what is the pull? What’s the draw for open source?

[00:08:18] KD: Yeah. I think the thing that’s really motivating for a lot of people who work out in open source is getting to work on something that’s bigger than just yourself or bigger than just the one thing that you’re doing. And it’s kind of amazing to see the little seeds that you plant just to solve this one sliver of a problem that you had over here could be used to have an even greater impact that you could never have imagined.

[00:08:43] SY: So do you have any favorite open source projects?

[00:08:45] KD: I think I have to say Rails just because it’s really what accelerated my career once I learned about it in my first job. I was working in ColdFusion and it was not the best situation. It is very outdated, very old practices.

[00:09:01] SY: Yeah. What is ColdFusion?

[00:09:02] KD: Oh, ColdFusion is this proprietary programming language I think by Adobe and it’s very interesting because it kind of looks like Angular. It’s the scripted tag-based language that was very difficult to use in a way that kind of had a separation of concern. So there’s a lot of logic happening in your views and it wasn’t the easiest thing to maintain and organize.

[00:09:33] SY: But Rails, the web development framework, that was much nicer to work with, I imagine.

[00:09:38] KD: Yeah. It was a lot nicer to work with. It really introduced me to the whole model-view-controller concept and how to organize a web app and how to approach it in a way that was a lot easier to maintain.

[00:09:51] SY: So how important were open source resources to you early on in your coding journey?

[00:09:57] KD: It was super important. Modern web languages were not a thing that you really touch on in a computer science degree. Coming into the workforce, having these communities built up around these open source languages were what really helped me find the kind of jobs that would let me do the work that I was really passionate about.

[00:10:19] SY: So did that kind of disconnect between what you were learning in school and then what you needed on the job? Was that frustrating at all?

[00:10:28] KD: So it was and it wasn’t. I started working in an environment that was a little bit behind the times. So at first, I still felt competent and being able to perform on the job and contribute to my team even as a junior developer. But as I learned more, then it became frustrating because I was very excited to be on the cutting-edge and that was not something that I was able to do at the job that I was at. Once I learned about what was happening in the industry and what was cutting-edge, it was very easy to come up to speed. So it was a little bit frustrating at the beginning to not have that knowledge at the outset and not have that education to know what to look for in jobs. But once I learned about it, it was very easy to use the skills of reading documentation, breaking problems down that I learned in college and solving that problem.

[00:11:33] SY: Was there a moment in your education where you felt particularly frustrated with that reality? Was there a moment you remember thinking, “Oh, man, I really wish I’d learned this in school”?

[00:11:43] KD: I think the moment that hit me was when I learned about Git. So in my first job, the way that we pushed code to production was to make changes on our files locally using Dreamweaver. And then when we were done and we were ready to see those changes in production, we would FDP them up to our production server, which was not great, especially when you’re working in a team and conflicts can occur. So once I learned about Git and it was not something that I had encountered in school or anywhere else, I was a little bit frustrated, all the problems that it could have solved me leading up to it, but I was glad I finally found it.

[00:12:25] SY: Yeah. Git is one of those things where once you use it, you just see how could you not use it.

[00:12:30] KD: How could you not?

[00:12:32] SY: It was very important. It’s like it’s the basis for GitHub, which is the company you work for. That’s super, super important.

[00:12:55] If you’re looking to excel in a new, rewarding career in tech, you can start right now by signing up at Flatiron, a global school that has helped thousands of students from all backgrounds invest in themselves by learning to code online or in-person. Not only will you be able to learn popular languages like JavaScript and Ruby, but also important skills like how to ace your job interview. A bold change begins with a single step. To take yours, go to flatironschool.com/codenewbie to learn more. That’s flatironschool.com/codenewbie

[00:13:30] As a programmer, you think in objects, with MongoDB, so does your database. MongoDB is the most popular document-based database built for modern application developers in the cloud era. Millions of developers use MongoDB to power the world’s most innovative products and services from cryptocurrency to online gaming, IoT, and more. Try MongoDB today with Atlas, the global cloud database service that runs on AWS, Azure, and Google Cloud. Configure, deploy, and connect to your database in just a few minutes. Check it out at MongoDB.com/Atlas.

[00:14:09] SY: So I want to get back to talking a little bit more about open source. There are all these criticisms about open source where it feels sometimes it can feel a little exploitative for people who just might not have extra time or support to work for free on other people’s projects. How do you address that? How do you reconcile that?

[00:14:28] KD: I think that problem in open source is very near and dear to my heart as someone who considers themselves a champion of diversity. I want to see these opportunities be accessible for anyone who’s interested and the way open source is structured sometimes isn’t conducive to that. You need to have the time, you need to have a computer, you need to have internet, you need to have all of these things that isn’t accessible to everyone all over the world, and funding is definitely a part of what’s going to help make that a little bit more sustainable.

[00:15:04] SY: So if you think about open source in the most sustainable way possible, if we get the most sustainable version of open source, what would that look like?

[00:15:13] KD: That’s a good question. I think primarily what I would want to see there is just having open source be accessible to everyone. Anyone that wanted to contribute and making it super easy to enter into a new project and be productive and not just for developers but also for designers or writers or anyone. There are so many problems and so many different tactics that we can use to solve the problems that open source is solving. Aside from that, I think there’s a lot of room for us to develop better tooling and automation around open source. Maintaining a project can take up a lot of time and is very draining. So I think anything that can make that process really smooth around the task that end up being very redundant that you do a lot checking security vulnerabilities, doing updates, things like that, anything that can be automated there I think would create an amazing sustainable worlds for open source, and the last one funding, just having the ability to have the resources to evangelize projects or train people up on how to use it or just be able to spend some time adding new features.

[00:16:29] SY: And one of the tools that you’ve been working on to help with that as you mentioned earlier is GitHub’s Sponsors. What is that?

[00:16:35] KD: GitHub’s Sponsors is a program on GitHub where open source maintainers and contributors can get paid for their work that they’re doing in open source.

[00:16:48] SY: So how does that work? I’m a maintainer. I work on this amazing project called, you know, “Help Everyone Learn to Code”. I don’t know. Something like that. And I want to get some money, some funding for my project, what do I do?

[00:17:03] KD: Yeah. So once you enter into the program, it’s time to set up your GitHub Sponsors profile. It’s a fairly quick process. You start by just giving a description about what projects you’re working on and what work do you want this funding that you’re getting from GitHub Sponsors to support. Then you set up your tiers. This is similar to Patreon where you can set an amount and then for that amount, what the sponsor would get in return for supporting your work at that level. And I believe you can set up to 10 tiers right now. And with that, we do a little bit more on the background to get you set up for payment and all of that and then you’re good to go. Your profile goes through a quick approval process and then you’re published.

[00:17:56] SY: So one of the things that I found with Patreon because we do have a Patreon account. It’s not doing very well, but we do have one. And one of the struggles with Patreon, I’ve heard this from other people who are on Patreon as well, is that you do the work, you do the project, right? And then with the rewards, people pay you and then they want a reward and the reward might be stickers or might be write a personal newsletter or it might be, I don’t know, sign a poster or whatever it is. But putting together those rewards takes time and takes money, think about the cost. Yeah, let’s say stickers, let’s say stickers are one of the lowest tiers. Let’s say it’s two bucks. It probably cost three bucks to print a sticker and to mail and all of that. So how do you kind of think about that? How do you think about the reward system not being yet another workload that people who are maintainers now have to add to the open source work they’re already doing?

[00:18:50] KD: Yeah, that’s definitely something that we’ve been thinking about and hoping to help and coach people in the program to do a good job at. One of the things we’ve discussed is the idea of decoupling the contribution from the work and the work is something that you do because of your motivations for being in open source and the contributions are a bonus. And so I always like to refer back to Henry’s Zoo and his tears. I believe one of them is playing a game of ping-pong with you and that’s a really unique way to go about it where you’re saying, “I’m motivated to do this work and I’m doing it and this is what you’ll get out of it is this continued support, but I’ll give you a thank you and just my own way of giving you a thank you for supporting this work that I’m doing.”

[00:19:48] SY: So the idea being that the rewards are not the reason why you’re supporting, like you’re not going to get, I don’t know, a personal book or something, like you’re not really doing it if there were, but just a little token of appreciation.

[00:20:00] KD: Exactly.

[00:20:00] SY: What are you hoping GitHub Sponsors results in? What impact are you hoping to make?

[00:20:06] KD: I’m hoping to see a lot more people in open source. I’m hoping to see a lot more diversity in open source and making open source work as something that’s sustainable for people who come from different backgrounds or maybe have different life priorities. That’s the biggest thing that I’m in it for.

[00:20:26] SY: Yeah. And I’m wondering what your personal goals are for funding because going back to Patreon as the example, most projects don’t really get a lot of funding, right? Because the levels are one to two bucks and you get like your friend group, maybe your friends and family, maybe a little bit more into the acquaintance side of things, but you get maybe a couple hundred bucks a month to work on it. It’s not many of the projects that reach really a sustainable amount of money where you can live off of it and really like start paying bills off of it. So when you think about GitHub Sponsors, is the idea just to alleviate just a little bit of the tension? Is it hoping to result at the equivalent of a salary? What are the funding goals for this project?

[00:21:08] KD: I think that we’re not looking at it from the angle of being too prescriptive with how our users set their goals. It’s more so making it normalized that open source should be funded. One of the things that we’re very aware of is GitHub Sponsors and individual peer-to-peer contributions and support is not going to be the final answer to solving sustainability in open source and there are lots more that we’re thinking about in order to make it so that if you want to support a career or have your entire salary paid for through GitHub Sponsors, that’s something that you can do, and we do that through both hoping to normalize it in open source, but also hoping to expand the program and see how we can get companies involved or create more structure with groups of people who are working on a similar project. We’re not necessarily being prescriptive as to what kind of funding we want to see or what goals we have for each person or projects funding but we want to have just whatever array of options available to all of the users.

[00:22:26] SY: So you talked about the idea of normalizing funding, which I think is a great goal. I love that idea. What do you think is the hardest part of making that happen?

[00:22:35] KD: I think the hardest part of normalizing funding is how nuanced of a problem this is when you talk about the incentives around open source and why people do the work, will money corrupt those incentives? Will it change what open source is fundamentally? I think those are the trickiest parts of being at GitHub and trying to solve this problem.

[00:22:58] SY: Oh, tell me more about that. I didn’t even think about how it might change what open source is. What are the different ways that might do that?

[00:23:06] KD: I think it comes down to those incentives. If I’m contributing to Rails because I just love it as a project and I want to support her, I want to use it in my day-to-day, will projects that maybe get more funding be more attractive to new contributors or to contributors that have been there a long time? Is it going to change what motivates people to contribute to open source? And how will it do that? I think it’s a little bit of a question mark right now, but it’s definitely something that we have our eye on.

[00:23:43] SY: When you think about changing open source in the way that it works and the way that people view it, is there a possible negative outcome? Are there things that you might worry about if things go wrong?

[00:23:55] KD: I think one negative outcome that I personally worry about are projects that are very important, but maybe not very flashy that are in the background that will get left behind. And so how do you surface these tools that may be a lot of open source projects depend on or a lot of the internet depends on in a way that competes with new cutting-edge, flashy projects?

[00:24:23] SY: Can you tell me an example of a non-flashy project that’s super important?

[00:24:27] KD: Yeah. First thing that comes to mind is cURL who, by the way, the founder of cURL is a part of the GitHub Sponsors program.

[00:24:36] SY: Nice.

[00:24:36] KD: But for listeners that don’t know, cURL is a command-line tool for getting or sending data using URL syntax. So any time you are in your terminal and you need to hit an API endpoint, cURL is what you’re using.

[00:24:53] SY: And so for a project like that, which frankly sounds really cool, especially if you've never used cURL before, the idea of using it sounds really exciting, but what makes it not so flashy?

[00:25:03] KD: Well, it’s a project that’s been around since 1998, I believe, and it’s just become a very routine part of the developer tool belt. So it’s cutting edge. It’s not something that is brand-new or shiny, but it’s something that’s very important in your day-to-day development and probably powers a lot of scripts that are written.

[00:25:31] SY: Coming up next, Katie talks about what went into building GitHub Sponsors and the importance of having a pre-mortem after this.

[00:25:46] Did you know JavaScript was created in 10 days? Command Line Heroes, an original podcast from Red Hat that I host is back for Season 3 and it’s all about programming languages. In this clip of Episode 3, we chat with Charles Severance, a professor at the University of Michigan School of Information about Brendan Eich, the man who created JavaScript in 10 days and how he created it like a Trojan Horse.

[00:26:14] When JavaScript was released along with Netscape Navigator 2.0on November 30th, 1995, all that magic was housed into a powerful little seed of a language, 28 companies, including America Online and AT&T agreed to use it as an open standard language. When it was released, there were some old pros looking down their noses at JavaScript. They thought it was just a language for newbies. They missed its revolutionary potential.

[00:26:46] CS: Brendan decided he would sneak in all these super advanced concepts from languages that are not well-known that were very like advanced object-oriented languages. So JavaScript is almost like a Trojan Horse. It’s sort of sneaked into our collective consciousness with the idea that it was silly and fun and easy and lightweight but then built-in from almost the very beginning was a powerful, deeply thought, well thought out programming language that’s capable of doing literally almost anything in computer science

[00:27:17] SY: You can find it wherever you get your podcast and make sure to check out the show at redhat.com/commandline.

[00:27:28] So we talked about what GitHub Sponsors is, how it hopes to make an impact. Now I want to talk about how you actually made it. How did you go about making GitHub Sponsors?

[00:27:38] KD: Yeah. The idea of sustainability and funding in open source is something that GitHub as a company has been thinking about for quite a while and it was something that I think we all wanted to give a lot of thought and make sure that we were building the right solution. And so this past year, Devon Zuegel, our product manager, joined the team and spearheaded the GitHub Sponsors Program. We finally had a solution that we felt we were confident was going to be the right first step in solving the problem of sustainability in open source. Once she joined the team, we got the four of us together from different teams at the company and built GitHub Sponsors on top of some existing infrastructure used to power the GitHub Marketplace.

[00:28:29] SY: Oh, very interesting. I love when you can just reuse some of what you’ve already built. That’s really convenient.

[00:28:34] KD: Yeah. It was super useful in helping us get off the ground quickly and get to validate what we were building with our users very, very quickly.

[00:28:45] SY: And I understand you also had a pre-mortem.

[00:28:48] KD: We did. So this is my favorite part of the project.

[00:28:52] SY: What is that? I don’t think I’ve heard of that before.

[00:28:55] KD: At the kickoff of a project, right after you have your general plan mapped out, you pretend that you’re at the end. You pretend that you’ve completed the project, and unfortunately, it failed. So I believe the term for that is called “Prospective Hindsight” and you ask yourself why. Why did this fail? And it was a really great exercise and being able to take a beat and really get all of our worries out there as a team. We weren’t trying to find solutions. We were just trying to really define what are all of the things that could potentially go wrong and that really helped us kind of aligned on what was unique about GitHub approaching this problem and how we could use it to set ourselves up for success.

[00:29:43] SY: Interesting. What were some of the failure scenarios?

[00:29:46] KD: That we wouldn’t be able to appeal to a diverse set of users.

[00:29:56] SY: So once you have that failure scenario in your mind and you’ve have it out loud, you’ve been talking about it, how do you protect against that? How do you use that information as you’re actually building?

[00:30:07] KD: So the first step once you have all the problems out on the table is to ask yourself if there’s something that you can do about it. Some problems are scenarios that you can’t really prevent. Just to use a wild example, say there was an earthquake that hit one of the data centers and everything is just up in flames, that’s not something that you can prevent, do anything to prevent, but that’s something that you could create backup plans for. So you decide whether it’s something that you can build with that in mind and make sure to take the steps to prevent it or you build backup plan. And so one of the things that we did as we were building this to protect against some of the things we were saying is a lots of customer interviews and lots of talking to our users and understanding what is at the core of the problem for them and what are the things that they absolutely need in order to solve the problem.

[00:31:08] SY: What did you take away from it? What are some things that you prioritized as a result of it?

[00:31:12] KD: So one interesting thing that we took away from it was prioritizing some of the social signals that we had built into the product. I think when we initially set out to build this, you know, you prioritize your core features first. Those are things that you really need to be able to launch. You need people to set up their profiles. You need people to actually be able to give money. So part of the features that were a little bit lower on the list, we’re being able to surface that, “Hey, I’m Katie and I sponsored Mike over here.” And as we were doing the pre-mortem, we realized these social signals were actually what set GitHub apart and being able to, as you’re interacting with people on issues or pull request, see that they either supported you through GitHub Sponsors or as a reminder that you support them in their work. So then that got a lot higher up in the priority list after we did the pre-mortem work.

[00:32:12] SY: How did that influence what you build and how you built it? Did any features come from it?

[00:32:17] KD: Yeah. So the feature that we ended up shipping with was a little badge. So in the user’s hover card or even on their profile, if you encounter user that supports your work and contributes to your work through GitHub Sponsors, you’ll be able to see a little “Your Sponsor Badge”, which by the way shout out to Kat Fukui, a little heart that expands when you hover it and it’s the cutest thing ever.

[00:32:45] SY: How big was the team?

[00:32:46] KD: We have four engineers, a designer, a product manager, and our engineering manager.

[00:32:51] SY: Okay. So pretty tight team, pretty small team What was your role on the team?

[00:32:55] KD: I’m one of the engineers and I kind of fit myself in a little bit of like between engineer tech lead role, somewhere in there. It’s a lot of work that I enjoy doing. I helped our product manager, Devon, scope some of the project and inform some of the technical decisions, but really we all just kind of came in and just split things up very ad hoc. We didn’t have super defined roles, which turned out to be really great because now at the end of the project, we all have a fairly distributed understanding of the project as a whole and there’s not a lot of silos of information.

[00:33:33] SY: So is GitHub Sponsors itself open source?

[00:33:37] KD: It isn’t.

[00:33:38] SY: It isn’t. Oh, interesting. Any plans to make it open source?

[00:33:41] KD: So right now GitHub Sponsors is part of our main GitHub monolith and I don’t think there are any plans on making that open source just yet.

[00:33:53] SY: Now at the end of every episode, we ask our guests to fill in the blanks of three very important questions. Katie, are you ready to fill in the blanks?

[00:34:01] KD: I’m ready.

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

[00:34:05] KD: Don’t try so hard.

[00:34:07] SY: Oh, interesting. Tell me about that.

[00:34:10] KD: It’s very early in my career because I have a lot of energy and a lot of drive to prove myself and one of my co-workers was very concerned for my ability to sustain what I was doing and setting expectations that were maybe a little bit too high. And so his advice was that I take it easy, lay low a bit.

[00:34:33] SY: Yeah.

[00:34:33] KD: It’s not really my personality so much. I just regarded that advice.

[00:34:38] SY: Me too. Yeah. Yeah. And did you end up okay?

[00:34:41] KD: I think it turned out okay.

[00:34:43] SY: Okay. Okay. Good. Good. Good. Number two, my first coding project was about?

[00:34:49] KD: It was a website on Geocities, which I think is true for quite a number of people. Yeah. It was a Card Captor Sakura site, which is an anime, and all I remember is just like learning everything there is to know about how to manipulate backgrounds on HTML websites.

[00:35:07] SY: Nice. Number three, one thing I wish I knew when I first started to code is?

[00:35:14] KD: That asking questions, even if they’re super obvious is a superpower.

[00:35:21] SY: I love that. Yeah. Tell me more about that.

[00:35:24] KD: It’s one of the things that’s just been like a personal obstacle for me because I’m one of those people that just wants to just intrinsically already know everything. I want to come to the table with the answers. But when I found myself in situations where I’ve been able to put my ego aside and just ask questions, it helps lift up everyone around you and you asked these questions that maybe seem really obvious but sometimes can uncover the fact that it was an assumption and everyone else is making assumptions and maybe they’re not all the same one.

[00:35:58] SY: Yeah, I love that. Well, thank you so much for being on the show Katie and sharing your journey with us.

[00:36:03] KD: Thank you for having me.

[00:36:11] This episode was edited and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.