[00:00:00] SY: Nevertheless, She Coded is the DEV Community’s annual celebration of women who code and the allies that support them. Over the past week, DEV Community members have been using their voices to amplify the call for gender equality, using the hashtag #SheCoded. Browse this library of inspiring, honest, funny, poignant, and relatable stories on dev.to/shecoded and then share your own. Happy International Women’s Day.

[00:00:33] 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 what do you need to know about APIs with Sue Smith, Developer Educator at Postman.

[00:00:47] SS: Aside from connecting me to job opportunities and that kind of thing, it was really life-changing because I had found something I was good at and that hadn’t really happened to me before.

[00:00:58] SY: If you have a question for Sue after listening, don’t miss the Ask Me Anything Session she’s hosting on the CodeNewbie Community Forum. Just head to community.codenewbie.org, and you’ll find her thread on our homepage and she’ll answer your questions directly in the comments. That’s community.codenewbie.org. In this episode, Sue talks about transitioning careers at 30, what APIs are and why it’s important to have a good understanding of them after this.

[MUSIC BREAK]

[AD]

[00:01:36] TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Take up the tools of software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:01:53] Ambassador Labs enables developers to ship software faster on Kubernetes. Sponsor of both the Ambassador API Gateway and Telepresence open source projects, Ambassador Labs is used by tens of thousands of developers worldwide. Learn more at getambassador.io.

[00:02:11] RudderStack is the Smart Customer Data Pipeline. Easily build pipelines connecting your whole customer data stack, then make them smarter by ingesting and activating enriched data from your warehouse, enabling identity stitching and advanced use cases like lead scoring and in-app personalization. Start building a smarter customer data pipeline today. Sign up for free at rudderstack.com.

[00:02:36] New Relic helps engineering teams all over the world visualize, analyze, and troubleshoot their software. Discover why some of the most influential companies trust the New Relic One observability platform for better uptime and performance, greater scale, faster time to market, and more perfect software at developer.newrelic.com.

[AD ENDS]

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

[00:03:03] SS: Thank you. I’m over the moon to be here and I’m a huge fan of yours and CodeNewbie. So I’m very pleased to talk to you.

[00:03:09] SY: Oh, wonderful. Oh, that’s so nice to hear. So Sue, you started development, not late in life and maybe a bit later than what’s considered traditional in our industry. Tell us about how you got to the place you are now.

[00:03:21] SS: Sure. Yeah. I was relatively late coming to tech. I was almost 30, which doesn’t seem that old, but in tech is kind of old.

[00:03:29] SY: Exactly. That’s a perfectly reasonable age. But you just keep hearing so much about people who started when they’re five.

[00:03:37] SS: Yeah.

[00:03:38] SY: Yeah. It feels older than it actually is. Yeah.

[00:03:41] SS: Yeah. I was basically doing a little bit of dead-end jobs that made me miserable. The service sector jobs, I was just desperate to get myself some sort of better job. And in Scotland, we actually don’t pay tuition. So I was lucky enough to be able to get a degree and then I was able to do a master’s in software development and also the master’s was funded by the Scottish government. Because at this time, there was a shortage of people working in the software industry. And so they were basically just funding any course that had anything to do with computers. So I was just really, really lucky. That was a 12-month course. It was very intense. I don’t think I could do it. I think I’m too old. It was really tiring and it was really, really intense, like long hours every day. And we learned the foundation in software development. And I really thought I was going to fall flat on my face. I had no idea what I was signing up for. I didn’t really know what programming was, to be honest with you. So to my surprise, I found that I actually loved it. And aside from connecting me to job opportunities and that kind of thing, it was really life-changing because I had found something I was good at and that hadn’t really happened to me before. So that was kind of a profound experience from that point of view. The first few years I did what we called web development. We don’t really call it that anymore. We just call it software development, software engineering. I did a lot of web development and multimedia development work, which was using Flash, which is kind of a controversial subject because it was notoriously inaccessible, Adobe Player Flash, and people have probably seen the recent headlines about it finally being retired. One of the cool things about Flash was that the authoring environment was actually a great low barrier place to learn about coding. And so lots of people got started coding in, say, Flash because it was just a really user-friendly environment. So I did that for a number of years, and I did a little bit of education mark. I would do tutoring. I did some teaching at the university that I had been at, and I did some technical writing. So gradually what I kind of started to specialize in was I would learn how to code something and whatever technology and then I would write tutorials or make videos to help other people to learn the same skills. And this was before Developer Relations was really well-known as a field. It existed, but people were doing it under lots of different job titles and it just wasn’t really well known. So I think like a lot of people who end up doing this kind of work had sort of cobbled together this weird mix of activities that turned out to be developer relations. So for a while, I did that. I specialize in Android development for a while. And then I was lucky enough to get a contracting job at the Mozilla Foundation, which I did on and off for a couple of years. And at this time, Mozilla had a lot of education programs that they run. Unfortunately, I don’t think they do any of them anymore. And after doing that for a couple of years, I really wanted to do something like that in my own community. So with a friend of mine, I co-founded an organization called Hack Aye where we worked with the public sector and other local organizations to help young people learn some coding skills, but we were more focused on helping them to use open tech and whatever projects they were working on. And we were building a bit of momentum. But to be honest with you, by this time, I was just fed up being self-employed. I wanted a job. I wanted to know that the bills were going to be paid at the end of the month. And so luckily, Developer Relations by this time had become more of a known career pathway and I managed to get myself a job as a developer educator at a low-code startup, which was called Dropsource. What happens to most startups, we run a runway and that startup ceased to be, and then the Postman job came up as developer educator. And this was just a kind of dream for me because Postman is so integral to the developer landscape and it’s also accessible to people who can’t write code at some usable on a completely no code basis. And I thought this is a place where I can really enable people on a massive scale. And so that’s where I have been for the past year and a half.

[00:08:38] SY: Yeah. Wow! I love your story. I think it’s so rich. You’ve done so many things in your career and it’s absolutely impressive. I want to kind of break down a little bit of some of the journey you talked about. So let’s start with just the challenging part. With all the stuff that you’ve done in your career, what would you say was the one most challenging thing in your journey so far?

[00:09:00] SS: I’ll tell you about something that I think was one of the most impactful things that I learned, because I think that it speaks to what was personally a challenge for me. When I started working at Mozilla, they have a very open way of working the open source ideology. It isn’t just about tech. It’s about transparency and sharing openly and being collaborative. So they would do things like if you were working on a new project, you would be dumping your thoughts into a collaborative notepad and other people are watching your thought process unfold, basically because they share really early and they collaborate really early. And this was horrifying to me because I had always worked on my own and I wanted things to be perfect before I shared them with anybody. And so it was really quite terrifying to have people see me work and see my thought process unfold and see all the mistakes. And it just turned out to be the most liberating experience that I had. And to this day, that’s how I work. I share things when I have half a thought, it’s like a half formed idea because I’ve really learned the benefit of getting that collaborative input early. Someone will see something unexpected and you’ll go off in a completely different direction. And so that’s something that still really determines the way that I work to this day.

[00:10:27] SY: Teaching in education is a big passion of yours. Tell me more about that.

[00:10:30] SS: Sure. So as I mentioned for me, learning that there was something that I was good at and that was valued, that was just so life changing that I wanted to make other people have opportunities to have that experience. And in tech, we have a lot of gatekeeping, but it’s a very privileged field and it really doesn’t have to be. So I really wanted to do anything that I could to enable people who maybe don’t have access to the traditional kinds of education and something that I’m finding really exciting, the CodeNewbie community is really representative of this, is that people are learning a really valuable skill set without necessarily going through the traditional route. One of the programs I work on at Postman is a student program and we partner with education institutions to help people learn about APIs. And so we work with educators and universities, colleges, bootcamps, community organizations, and what we’re really finding is that when it comes to APIs, the traditional institutions are really miles behind. There will be people learning computer science at a university and they don’t even learn about API. They don’t know what an API is. APIs are really essential to the future of software development. Whereas with the bootcamps, we’re finding that a lot of them are actually API focused and they’re centering their entire head learning program around APIs. So I feel that this is a time where there’s really a kind of tipping point where these more vocational courses that are really turning out people with really valuable workplace skills. And I think that can only be a good thing for tech. The more equitable it is the more diverse workforce we have. That has to benefit all of us.

[00:12:28] SY: So you mentioned that your first full-time developer job was at a small app startup that you worked at until it basically went out of money. Tell me a little bit more about your role there. What was that experience like working at a startup?

[00:12:42] SS: Sure. That was an interesting one because the company was based in the US, I’m in the UK, and I thought, “I know how to work remotely. I’ve done this before. It’s fine.” But what I hadn’t realized was that it’s really different when you’re the only person who’s remote and everyone else is on the same time zone. And that was a whole other challenge. But on the Developer Relations side of things, I learned so much because it was a tiny, tiny team. And so I was the Developer Relations team. So I would do documentation, I would do training, events. I would do community management. I was the support team, and eventually I transitioned to develop an advocate and that involved advocacy to the product team based on what I was hearing in the community. And so I got to try out a real breadth of developer relations, which is handy. It can be good to be a generalist and I think that’s partly why I got the job at Postman, but at the same time, sometimes you need to get a bit more mix. And I think that’s the case for a lot of fields in tech. Being a generalist can be valuable, but sometimes you need a bit of specialism in the mix too. That’s something that we’re finding at Postman now that we’re building the team out a little bit more, that we kind of had a team of generalists who could just do whatever needed done, but we were maybe lacking a bit of technical depth in particular places. We were maybe lacking a bit of depth in certain practices in Developer Relations. And so I think that’s something that’s good to keep in mind, especially for people who come to tech from a different background, maybe you’ve done a different job as a real advantage to have more than one type of career behind you, but it’s also important to make sure that you have a bit of technical depth here and there too.

[MUSIC BREAK]

[AD]

[00:14:54] Want to learn more about Kubernetes, but don’t know where to start? The Kubernetes Initializer lets you build your own application right in Kubernetes’ playground in just a few clicks. Automatically configure Ingress, a continuous integration pipeline, authentication and more. Try it for free at getambassador.io/codenewbie.

[00:15:14] RudderStack Smart Customer Data Pipeline is warehouse first. It builds your customer data warehouse and your identity graph on your data warehouse with support for Snowflake, Google BigQuery, Amazon Redshift, and more. Their SDKs and plugins make events streaming easy, and their integrations with cloud applications like Salesforce and Zendesk help you go beyond event streaming. With RudderStack, you can use all of your customer data to answer more difficult questions, and then send those insights to your whole customer data stack. Sign up for free at rudderstack.com.

[AD ENDS]

[00:15:52] SY: Now you were at Postman. Tell us a little bit more about what Postman is and what you do there.

[00:15:58] SS: Sure. So Postman is a platform for collaboration around APIs. And an API is essentially a way of accessing data and services. So if you imagine you had a job and maybe you have all your products and all your data in a database and you’ve got a website and a mobile app, the idea of an API is that rather than you building two essentially completely separate applications, that you stick an API in the middle and that manages the way that you connect to the database and that way your mobile app and your web app can use the same API. So it would basically cut down on a lot of the implementation investment. It means that both your app and your website are easier to maintain. You have fewer points of change. But what has also started to happen over the last few years is that APIs have become a product in their own right. So in a lot of companies now like Twilio is the typical example that we give. Vonage another company that does something very similar where the product as an API or a set of APIs. So they specialize in messaging. And so if you’re building an application and you need to have some sort of solution for messages in your customers, instead of you implementing that yourself, you just plug into Twilio API or whatever, and they specialize in that and you know that that part is taken care of. And this allows people to build really complex applications in a modular way, by plugging all these sort of Lego bricks together. And so this is becoming more common. And for anyone who’s maybe going into software engineering, it’s worth keeping in mind that you might be working on a product where your users are actually developers, they’re like you who will plug in your service into whatever they’re building. So the reality of working on software now is integrating with a lot of APIs and something that I always tell people who are maybe on a course or maybe learning is that it’s really messy. It’s very unpredictable. There’s a real lack of standardization. And so if you get on to a real world project and you’re like, “I don’t know what’s going on, it seems like chaos,” it’s not you. It’s very, very messy and unpredictable. And this is one of the reasons that Postman exists. Our CEO, Abhinav, was actually working as a software engineering intern and he created this little tool to just make his life easier. And he shared it with a few people and it genuinely just spiraled through word of mouth and became this platform that’s used by millions of people.

[00:18:49] SY: That’s beautiful. Yeah.

[00:18:50] SS: And so the core purpose initially was to help people to make sense of the APIs that they were integrating with. Our core use case still to this day is what is my API request doing. So if you’re trying to integrate with an API and you can’t figure out what’s going wrong, you pop it in a Postman, that gives you a bit more visibility, it helps you to make sense of it and troubleshoot. And so this was the core use case of Postman. But since then, the platform has evolved to support a lot of different parts of the API development life cycle. So you can write documentation for an API in there. You can mark API data. You can do all sorts of parts of the testing process. And so it’s become a place where people collaborate and hear something not even in technical rules around API projects.

[00:19:46] SY: Tell me about some of the components of an API request. What is it made of?

[00:19:50] SS: So an API request will have an address, and that is just exactly like the address that you pop into your browser address bar. It’s exactly the same. It will have a path. And that’s normally the bit that comes after a forward slash. And typically an API will provide what we call end points and each endpoint will provide a different operation. So maybe you’ll have one that is for retrieving data. Maybe you’ve got one that’s for retrieving a list of products. You might have another one for adding a new product. You might have one for updating, deleting. And in order to do these, you’re also going to use different methods. So the methods that are more common are get, post, put, and delete, and get as for fetching data, post this for adding data, and put and delete are for updating and deleting it. So these are the core components of a request. And again, it’s really, really similar to what you see in your browser. If you start using a client like Postman, you’ll see that actually the user interface is kind of similar to our browser. You just put the address in. You pack a method and you hit send. And when you do that, hopefully the API will send your response. And the response is structured data. Mostly it’s in JSON. Sometimes we see XML and other formats, but for the most part, you’re going to be dealing with JSON data and hopefully it will be the data that you requested. It might not be. It might be an error response. Your response would be associated with a status code that will indicate the success or otherwise of the request. And if it was not a success, you’ll get a different code. And again, that is something that is just part and parcel of working with APIs. And the more that you work with them, the more you come to see editor responses as progress. Maybe you’re like, “This isn’t working. Why am I getting an error?” And then you get a different error and you’re like, “Okay, I must be making progress. I got a different error this time.” It’s just such a minefield in particular. The hardest part is authorization. And this is something that I always encourage people. If you’re trying to learn about APIs and you’re getting hit with authorization errors, join the club. It’s not because you don’t know what you’re doing. It’s because they’re notoriously difficult to navigate. So authorization, it’s about making sure that you only have access to data that you’re authorized to have access to. So it’s part of security and you’ll find this in particular with third-party APIs and they all use different authorization methods. So it was very, very complex to navigate. But again, it’s one of the things that at Postman, which I think make a little bit easier. So hopefully, you get an error message that at least tells you how to move forward, but that’s really down to how well designed an API is. Unfortunately, they’re not always designed well to help you to navigate the errors.

[00:23:02] SY: So that’s all about using the API. What can you tell us about building and sending API requests? What did that look like?

[00:23:09] SS: Something that I use a lot and I would totally recommend for anyone who wants to learn about building APIs is Glitch. And I know that you’ve talked about Glitch on this podcast before. So Glitch is a fantastic community-based coding learning environment. And one of the huge advantages to it is that you can remix existing projects. So for anybody who wants to learn how to build an API, instead of starting from scratch, I would thoroughly recommend going to Glitch, find one and remix it. And one of the advantages to that is that it’s immediately deployed so that you don’t have to deal with deployment, which is a bit of a nightmare, to be honest. And although this stuff is really handy for people who are learning, I know how to build APIs, but I don’t want to deal with that stuff unless I have to. So I use platforms like Glitch. Life’s too short. If I don’t need to deal with some sort of deployment headache, then why would I?

[00:24:08] SY: Yeah.

[00:24:10] SS: And so I would recommend finding a Node.js, Express, API on Glitch. I think there’s one called “Hello Express”. And it just shows you the nuts and bolts of what an API looks like on the backend and you can remix it. You can add a request to it and then you can meet requests to it from Postman or wherever else you like. So what you’ll have in your actual API is a definition of the end points that the API provides, and then you have what we call a client app, which you can use Postman for, to make requests. So this is your backend and front end of the API.

[00:24:51] SY: So what do you think is important for people to learn about APIs and really understand them? What are some things that they should really be comfortable with maybe before they actually dive in and use them?

[00:25:02] SS: I mean, I encourage people to dive in and use before you know anything. I’m a believer in learning by getting your hands on tech, but what I would probably see again before you dig into the API as it is really messy and unpredictable and not to be put off by that, there has historically been a lack of standardization, but now we’re starting to see some consensus that aren’t standardization and that has making things a little bit more predictable. But that’s going to be a work in progress. I would encourage you to get stuck in. Go in a Postman or go in a Glitch. Have a look at an API, try extending one, try making a request to one, because the best way to learn tech is by messing around with it, in my opinion.

[00:25:48] SY: Where can things go wrong? Tell me about some of the ways that APIs can get messy and what we can do to prevent that.

[00:25:55] SS: Sure. There are so many. One of the huge problems that we have in APIs is a lack of documentation. No one wants to spend time on it. And so you’re trying to integrate with something that isn’t documented, that’s very challenging, or the documentation is out of date so it hasn’t been maintained. Even where we have documentation, sometimes it’s too granular. So you may have documentation that explains what our request does, but it doesn’t explain why you would want to do that. It doesn’t maybe put the pieces together. Give you the bigger picture and explain the purpose of the API. And so I think the onus really is on API providers. One, to design the APIs in a way that is easy to onboard with them, and two, to provide these learning materials that help people to figure it out, how and why they would want to integrate with that on applications.

[00:26:57] SY: Do you think it’s bad to base a lot of your app, maybe even most of your app on other companies’ APIs? Is there the possibility of being too dependent on something that isn’t yours?

[00:27:11] SS: I would say this is the nature of software now. And to me, the benefits outweigh the risks because being able to build software in such a modular way, it really allows you to achieve a level of complexity so quickly that historically just would not have been possible without access to massive amounts of resources and it lets you focus on the unique aspects of what you’re building. But it’s an interesting question and we probably should be more mindful of the nature of dependency, especially with startups. If you’re dependent on something that’s maybe provided by a bigger company, it could be a vulnerable position to be in. So yeah, it’s an interesting question, but my gut instinct would still be that the benefits outweigh the risks at this point.

[00:28:03] SY: And kind of related to that, what do you think about dependencies, having a lot of dependencies in your application, whether it’s APIs or gems, libraries, other things? Do you have a position on that? Is there a limit of how many dependencies you should have? And should we be striving to decrease that number?

[00:28:23] SS: I think that we should always be mindful of it. I think that to some extent we’ve kind of sleepwalked into just using dependencies by default when maybe implementing something yourself would be a trivial task. So I would always be mindful of whether you need a dependency or not. But again, I think for the most part, it does enable us to build for complexity. It’s kind of a house of cards and it’s one of the reasons that I think that we need people to get more serious about testing. One of the parts of Postman is monitoring where you can basically run tests on a schedule and find out if something is broken. And so if you see your product has a service level agreement with your customers and then one of your dependencies goes down, you need to know about that quickly. And I think we’ve kind of got carried away with how quickly we could build complex things and are having to catch up now on making sure that we know all these things that we’re dependent on functioning that maybe we even know how these things are getting made because there have been so many cases of dependencies failing when this dependency that tons of massive software applications we’re using was like maintained by one person as a volunteer. And that’s kind of a dangerous position to be in. So we probably could all do with get more informed about where these libraries are coming from and how they’re being maintained and how they’re being funded.

[00:29:58] SY: So I know that you’re also really passionate about accessibility. Where do APIs fit in here? And do you think that we should be doing more in terms of accessibility in APIs?

[00:30:07] SS: Yeah, absolutely. I think aside from having a gateway for people to learn tech skills because they want to do a developer job, I think we really need people on a mass scale to understand more about APIs because the entire future of software is dependent on them. And so something that I’ve been really excited about Postman is what we’re calling “API Literacy Learning” and that really is not about the product at all. We’re really just focused on helping people to learn about API. So we have an API 101 course that people do. We’re leveraging the fact that you can learn inside Postman without writing code. So people from non-technical backgrounds can do this. Either because they want to learn tech or because maybe they’re working in a job that’s adjacent to an API, but they need to know about the API in abstract level, but they don’t need to be able to code it. So we will teach them the basics of what we just talked about, what an API request is, and I think having that genital level of literacy around APIs is going to be really, really important in the future.

[00:31:29] SY: Coming up next, Sue talks about what her biggest piece of advice is for other career transitioners like herself after this.

[MUSIC BREAK]

[AD]

[00:31:49] Explore the Mysteries of the Pythonic Temple, the OSS ElePHPant, and The Flame of Open Source all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:32:08] New Relic knows that the planet needs our help. That’s why they’ve partnered up with our team at DEV to host Hack the Planet. From now through February 28th, you can take advantage of their free tools to build a climate change monitoring app with the power of software observability. It’s a great chance to win cash, community bragging rights, swag from New Relic and DEV, a tree planted in your name, and other prizes, too. Learn more about the Hack the Planet Contest on New Relic’s dedicated community hub, therelicans.com. The Relicans is your place to connect with other developers. Meet the team behind New Relic’s software monitoring platform and show off the app you built for Hack the Planet. That’s therelicans.com. Happy coding.

[AD ENDS]

[00:32:57] SY: So when you think about education, universities, bootcamps, one of the things that we hear a lot is, specifically for people with CS degrees, that they don’t necessarily prepare you for the actual job. It’s a little too theoretical. So when you think about college, when you think about bootcamps, which are a lot more practical, I guess, is one way to put it, do you think that people are being prepared well enough to use tools like APIs? Do you feel like they’re learning enough to be able to make use of that resource?

[00:33:26] SS: It really depends on the organization. And like I mentioned, the educators that we work with, we’re finding that the more vocational courses are much more oriented towards workplace skills are much more focused on teaching people the realities of being in the workplace in tech terms. Whereas the likes of universities and the more traditional institutions, they are a bit theoretical, where teaching people things that very, very few people are going to use in the workplace. And that’s fine, depending on what field you’re going into, but it creates a false sense I think of the type of work that you’re going to do. But again, I think this is a real strength for the bootcamps and I think it’s why a lot of bootcamps are turning out really high quality graduates. You’re having great success in the workplace. My manager at Postman, Joyce, who’s the Director of Developer Relations, went to bootcamp. She has a real technical depth and has this phenomenal career. So there really is no limit to what you can achieve if you come from a more vocational background. And in many ways, I think it can be an advantage to be honest with you.

[00:34:40] SY: So for folks in our audience who were also career transitioners like yourself, what would you say is your biggest piece of advice for them?

[00:34:48] SS: I would say see it as an advantage. Don’t think that because you came to tech late and everyone seems to have been writing code since there were five that you’d at a disadvantage because more and more, any job that you do in tech, but in particular jobs like what I do in developer relations, any kind of job where you’re focused on engagement, being able to communicate with a wide range of people is hugely important. If you’ve only ever worked in tech, you’re just less able to do that. If you’ve worked in different industries, if you’ve had different experiences in life, you’re just able to engage with a broader range of people, and that’s a huge asset. And not just in developing relations. We have roles for example in customer engagement, solutions engineering where you need people to have more than the tech skills. So I would say don’t see it as a disadvantage. See it as an asset.

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

[00:35:57] SS: Yes.

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

[00:36:02] SS: I worked somewhere in the past, which shall remain nameless, where I was lucky enough to be able to hire people, to help with the support and community development. And so I had drafted this job spec and I was getting really excited about being able to hire someone and someone who came from more of a kind of corporate background said, “We should just hire a load of recent college graduates. It doesn’t matter what their degree.” He was saying, “We should just hire a load of college graduates.” And I was really astonished by this because there was absolutely nothing in the job that required the person to have a degree. And they weren’t even advocating a specific type of degree. And it was really the first time that I had seen in action this tendency people have to just want to hire other people who are like them and just that kind of inherent bias and I was really shocked to see it. I’m glad to see that we did not do that. But it was kind of an interesting lesson for me to see that. And that’s how we end up with such bias and white people hire another white people. It’s just people hiring people who are from the same background as them essentially.

[00:37:20] SY: Number two, best advice I’ve ever received is?

[00:37:23] SS: Best one, I’m going back a long time when I was learning to drive. In the UK, we drive manual cars. I think sometimes people call this a stick shift where you have a gear stick and the clutch pedal. And controlling the clutch is like the hardest part of learning to drive. And we have this fear that you’re going to stall the car all the time. And when you stall a car, the engine cuts. So we spend a lot of the time learning to drive, just trying to avoid this. And a family friend was helping me to learn to drive. And he was like, “We’re going to go off down the side street where it’s flat and there are no other cars. Stall the car.” And I was like, “I don’t want to stall the car.” “Just take your foot off the clutch and stall the car.”

[00:38:11] SY: Wow!

[00:38:12] SS: And I did. And I was like, “It wasn’t that bad. It wasn’t such a big deal.” And that’s something that I think is really relevant for coding because getting comfortable with failure and mistakes and error messages is just such an important part of learning to code. And to some extent, I don’t know about you, but my school education really drummed into me, “Avoid failure, avoid making mistakes at all costs,” and that’s really such an unhealthy mindset. And so I think we need people to embrace the mistakes a bit more because we can’t learn anything without making mistakes.

[00:38:48] SY: Number three, my first coding project was about?

[00:38:51] SS: My first real substantial coding project was at the end of the course that I did. And this was supposed to be a substantial software project that you built from scratch. But I picked one where I was actually extending an existing system and I did not realize at the time that this would be a lot harder. So that was kind of a shock. The first thing I had to do is fix all the bugs that were on it and then I had to learn how to build on top of the system that someone else had built. But in retrospect, it was actually a much more valuable experience because of that because very rarely are you going to be building a system from scratch. You’re going to be working with other people’s messy buggy code. And you’re going to have to figure it out how to integrate with it and hope to fix it. So it was actually a great experience.

[00:39:42] SY: Number four, one thing I wish I knew when I first started to code is?

[00:39:46] SS: What I wish I knew was that the technologies aren’t really important that all you learn on annual learning experience, whether it’d be a formal course or self-taught learning as a foundation, the technologies that I learned in my course, I don’t use any of them anymore, but what I learned was something more abstract that was transferable on different technologies. And one of the most important things that you learn is how to learn. It is something that I always like to ask people when I’m interviewing for jobs is to talk to me about how they learn, because you’re always going to be solving new problems, you’re always going to be learning new technologies. And being mindful of your own learning process I think is a huge asset and I wish I had known that more at the time, instead of focusing too much on the detail of the technologies that I was learning.

[00:40:37] SY: Well, thank you so much again, Sue, for joining us.

[00:40:40] SS: Thank you. It’s been a pleasure.

[00:40:48] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, 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.