Screaming in the Cloud - Learning Tech in Public with Ceora Ford

Episode Date: October 27, 2020

About Ceora FordCeora Ford is a digital marketer turned software engineer based in Philadelphia. She is really into Python, AWS, education and diversifying tech. She's had the pleasure of teaching with Kode With Klossy, BSD Education, and more recently, egghead.io. When she is not coding, she's usually watching movies and pretending to be a film critic.Linksegghead.io: https://egghead.io/Eight Resources for Learning Python blog post: https://www.ceoraford.com/posts/8-resources-you-can-use-to-learn-python/Twitter: https://twitter.com/ceeoreo_Personal Blog: https://www.ceoraford.com/ LinkedIn URL: https://www.linkedin.com/in/ceora-ford/Ceora’s Website: https://ceoraford.com/

Hello, and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. those boundaries. So it's difficult to understand what's actually happening. What Catchpoint does is makes it easier for enterprises to detect, identify, and of course, validate how reachable their application is, and of course, how happy their users are. It helps you get visibility into reachability, availability, performance, reliability, and of course, absorbency, because we'll throw that one in too. And it's used by a bunch of interesting companies

you may have heard of, like Google, Verizon, Oracle, but don't hold that against them, and many more. To learn more, visit www.catchpoint.com and tell them Corey sent you. Wait for the wince. N-Ops will help you reduce AWS costs 15 to 50 percent if you do what it tells you. But some people do. For example, watch their webcast, How Uber Reduced AWS Costs 15% in 30 Days. That is six figures in 30 days. Rather than a thing you might do, this is something that they actually did. Take a look at it. It's designed for DevOps teams, and Ops helps quickly discover the root causes of cost and correlate that with infrastructure changes. Try it free for 30 days. Go to nops.io slash snark. That's nops.io slash snark. Welcome to Screaming in the Cloud. I'm Corey

Quinn. I'm joined this week by Ciara Ford, who is, among other things, a software engineer, a digital marketer, historically, and an educator at Egghead.io. Ciara, welcome to the show. Thanks for having me. I'm so excited. So as of the time that we're recording this show, it is before I go out on parental leave. But when people are listening to this, you will have put out this week's issue of Last Week in AWS.

So people should at least have some passing familiarity with who you are, at least among this audience. So it's interesting having conversations in the past from when people listen to this about something that is yet to happen. So we're assuming the newsletter goes out on time, that 2020 hasn't gotten worse because, oh, wow, they haven't even mentioned the giant meteor yet. It turns into interesting times. But first, I want to start by thanking you for letting me take some time off and actually spend

time with my family rather than writing these things part-time in between bottle changes. Of course. I'm so excited that I get to have this opportunity. The way that I see it, though, is it's always a problem where I started this whole ridiculous newsletter once upon a time where it was this labor of love.

It was built on my crappy personality defects, which people misinterpret as a sense of humor. And then it turned into something that sort of caught on, but I never built it with the idea of other people being able to take it over, which pro tip, if you're building something and trying to scale it, maybe have a succession plan in place. That becomes a bit of a challenge. And it was, well, great. What am I going to do? Well, now I'm experimenting and finding out. If people aren't listening to this show by this point, great, good to know.

Now at least I've learned that, no, it dies with me, good to know. I don't think that's going to be the case, but we'll find out. So enough about that nonsense. Let's talk about you. What are you doing these days? Okay. I feel like I have a million and one things going on always. I'm one of those people that as soon as I feel like I have a chance to relax, it's like, oh, let me find something else to do. So right now I am working

on a couple of different projects. So one of the things I'm doing is I'm looking for a lot of speaking opportunities. People have been passing for a lot of speaking opportunities. People have been passing on a lot of information about different conferences and things like that. And now since they're remote, I have a lot more availability for different things. So expect more of that from me as well. More conference talks and things like that. I'm also working on completing my Udacity course and officially becoming a cloud DevOps engineer. So probably by the time this is published, I'll be finished with that, hopefully. And then I have several different projects on the side that I'm working on. One that I just started recently is called

100 Days of Projects. So it's like a community-based movement, I guess you could say, that just encourages people to work on their projects consistently. It doesn't matter how much you do or how little you do, as long as you're taking the time to put forth some effort on the projects that you build. I feel like myself included, a lot of us developers have tons of project ideas and not enough time, or sometimes we just forget about them. And I am in that category so much. So I decided to start this project that would help me and others get more involved in building your projects consistently and learning in public as you do it. So yeah, those are some of the things that I have going on. I probably missed

a few things because like I said, I just have so much happening right now. Oh, believe me, I understand the feeling. I love the idea of learning in public. That's something that for whatever reason, when I was starting out in my career, I never felt like I could do that. It was always a learn, study in your own time cram. So whatever happens, your employer never finds out that you're a giant fraud. And I figured that I would wind up being able to stop doing that when I stopped feeling like a giant fraud.

Fifteen years later, I'm still waiting for that moment to hit. So I've had to, I guess, readjust that approach. I mean, something I've actually learned is that when you're interviewing people for various roles, a mark of seniority is when people admit they don't know something. It's very hard for people to do for whatever reason. So whenever I see people doing the learning in public thing like you do I'm generally incredibly impressed it's something that I wish I had had the courage to do back when I was starting out yeah well I have fortunately especially through my work with egghead I have been introduced to this concept a lot lately

people at egghead are really big on pushing you to learn in public. And even if you're a beginner, create content for others. So I totally understand your hesitance because I felt that way for the longest. I was always scared that I'm going to be exposed as a fraud or someone's going to pick out one of my mistakes and hate me or something. Coming up with all these different scenarios. And sometimes, yeah, you do get reply guys who are like, oh, well, actually it's not like that. But for the most part, I feel like learning in public is great for so many reasons, especially I have the personality type where I need external sources of motivation. So external sources of motivation for me are other people watching me, knowing that I'm like expecting something from me. So if I'm public about, oh, I'm learning, I'm trying to work on getting this AWS certification, or I'm working

on this project, and I tweet about it, I share on my blog or whatever the case may be, I know that people are watching and they expect something. They expect the finished product. So it pushes me to actually do things and finish things. And then also when you are learning in public, sometimes some forms of that are basically you're teaching other people what you're doing. So if you're writing an article, if you're streaming on Twitch or whatever the case may be, you're teaching information that you just recently learned. And I feel like that's a way to spur your own understanding exponentially. Because if you have to teach other people, it forces you to really make the ideas and concepts your own. And it forces you to see like,

okay, if I'm a beginner and I'm completely new to this concept, whatever the case may be, you're going to be looking at everything in a much more in-depth point of view, which I think really helps you to learn and solidify your knowledge much faster. So I'm a huge fan of learning in public. I wish I would have done it earlier, just like you were saying, but I'm trying to get over that fear of failure or imposter syndrome or whatever the case may be. And just like put myself out there a little bit more because in the end, it ends up being not only beneficial for me, but other people who are beginners or other people who are looking to learn something new that I'm also learning. So yeah. One thing that continues to take me aback is people in your position who are looking to,

all right, I'm going to start learning tech. And one of the technologies and areas of focus that you've talked about is going into learning about AWS, which is, okay, that's daunting. So what's your goal? Oh, I'm going to learn all about AWS. Yeah, I'd like to do that someday too. There's no outcome there. It's one of those, looking at how stupendously complicated and overwrought and vast just that one company's product offering is, I despair of ever being able to attain mastery over even a small part of it. Oh, yeah. I totally agree. AWS is so, it can seem so daunting. And honestly, I'm not even sure what even convinced me that,

oh, yeah, this is something I want to tackle. Because now looking back, I'm like, what was I thinking? Because it's so, okay. So for me, I don't have an IT background or like a networking background or even like a back-end engineering background. So a lot of those concepts I've become introduced to through AWS, which is great in a lot of ways, but also because AWS is such a huge thing within itself. And sometimes, I've talked about this on Twitter before, but sometimes AWS docs are not very helpful. So sometimes I've been so confused about certain concepts that I've been introduced to through AWS. But the thing I am thankful for is even though AWS is not always

the most welcoming way to be introduced to some of these things, especially like networking and stuff like that. I don't think I would have learned about those concepts otherwise. I probably would have just stuck with the basic, not the basic, I won't say basic, but I probably would have just stuck with front end web development, those kinds of things. But AWS has helped me to broaden my horizons and learn a lot more, which I'm happy about. But yeah, it's so much packed into one product, I guess, that it can seem very daunting. It's something that it's a valuable skill to know,

but like you said, there's no way, if you're one of those people who like, I need to master this and I need to know everything about it, you'll be reaching for that for the rest of your life with AWS. Oh yeah, what amazed me when I started getting deep into the space is I'll of your life with AWS. Oh yeah. What amazed me when I started getting deep into the space is I'll talk to someone at AWS. It was an absolute wizard when

it comes to networking, for example, and how AWS networking works because they work there and they help build part of it. And it's, yeah, I am a giant fraud. I am never, ever going to attain anything approaching this person's level of expertise. And then I'll ask a question about elastic beanstalk. And their response is elastic what now? Is that a real thing? Or are you making that up to have fun at my expense? And it's, oh, I keep forgetting that my failure mode is that I come from a world of small companies where a big company has 200 people. The idea of a company that is so vast that people don't know what other parts of it are even supposed to be building or working on is ridiculous to me, but that's the world we live in.

I've long since passed the point where I can talk convincingly about services that don't really exist and not get called out on it when I'm speaking to large groups of Amazonians. It's, no one has this all in their head. Yeah. Yeah. I totally agree. I totally agree with you. So it's like one of those things, I guess this kind of ties back to learning in public too. When you're learning AWS, you cannot feel bad about not understanding certain things because no one understands everything about AWS. Nobody.

So it's kind of the perfect thing to just share that you're learning because all of us are just figuring it out. Honestly, like no one's an expert. That's not something... I learn new things about AWS every single day. And admittedly, I haven't been in the space for long, but still, that's still major. There are some people who kind of reach a point with certain frameworks or languages where they kind of reach expert level, but I haven't met anybody yet who's like, oh yeah, I'm definitely considered like an AWS expert because nobody feels that way. We all know there are things that we just don't know and probably will never figure out. One of the transformative moments I've had is I was getting

coffee back in the before times when that was a thing we could do without taking a deadly risk. And I was talking with Jeff Barr, the chief evangelist at AWS, who writes, I think at this point he is approaching 3,500 blog posts published. Wow. And I asked him about this because I've started to experience an aspect is I don't write nearly as prolifically as he does, but there are times where I will Google something and find the answer. And, oh, great, this is an awesome article who wrote it. It was me, and I have no recollection of writing it. And it turns out that his answer was, oh, as soon as he writes something, he tends to mostly put it out of his head. So if I come and I ask him a technical question about a blog post he wrote, he will, sorry,

what service is that? Is that a real service? I guess it would be. It's one of those moments where you can't retain all this in your head. That is why we write things down. One of the things that you mentioned a few minutes ago that I really liked was the idea of teaching something as a way to learn it. And that really resonates. For me, it was I built a conference talk, Terrible Ideas in Git. Because when you get a conference talk accepted and you have to give it in four months about a technology you know almost nothing about, that is what we know in computer science is a forcing function. If it doesn't, you're going to learn it or you're going to give a really crappy talk. Yeah.

And do I know Git now? Of course not. Git makes everyone feel dumb. The only question is how far along the path you get before the floor drops out from under you. But by building that talk and making it accessible, I understood a lot more about it than I did when I started. There's really something to be said for teaching others as a learning style. Oh, yes. Oh, for sure. Actually, what you're saying right now about giving a conference talk about something you're not very familiar with, that's actually something I've been doing recently. And again, like I said, I need external sources of motivation to do anything pretty much at this point, because I'm not a very self-motivated kind of person. Like I would lie to myself and say, yeah, I'm going to do this thing and I'm going to do it so well. But if I don't tell anyone else about it, it's basically not going to get done. So that applies to almost every part of my life,

especially the tech side of my life. And it seems so bizarre. When you see someone giving a conference talk, you automatically assume that this person must have years and years of experience and they're an expert and they know everything and they're just like, oh, they're so confident and that's why they're giving a conference talk. I was asked recently to be on a panel for Jamstack, which is something not super related to AWS, kind of with the serverless side of things. But at that point, I knew about it, but I didn't really know enough about it to like really, you know, be on a panel. But, you know, I was given the opportunity. So I was like, okay, I'll accept it. And that was the first time I ever confronted this idea of these things that we assume only experts do. Making videos or writing articles or even giving a conference talk, you do not have to be an expert. Like I repeat, you do not have to be an expert to do those things.

In fact, it's a great way to learn enough to talk about something in a knowledgeable way. I feel like that's my new learning tactic is like, if I want to learn something, the next thing I automatically plan is like, okay, I'm going to write this article or I'm going to sign up to give this talk about this subject so that it's going to force me to learn enough about it to be able to talk to people and know what I'm talking about to a certain degree. So yeah, I love this idea of you don't have to be an expert. In fact, not being an expert gives you a different perspective that probably is really useful to a lot of people. So yeah, I love the idea of, yeah, give that talk. You don't know anything about this subject. You don't know anything about AWS. Well,

use it as a way to learn about it. So that's something I've definitely been doing recently, especially I mentioned earlier, I'm trying to do more speaking opportunities and things like that. So that's what I've been using as a way to learn and also get more speaking opportunities as well. If you're listening to this and looking for a speaker at your events, you should be paying attention to this. This episode is sponsored in part by our friends at Linode. You might be familiar with Linode. They've been around for almost 20 years.

They offer cloud in a way that makes sense rather than a way that is actively ridiculous by trying to throw everything at a wall and see what sticks. Their pricing winds up being a lot more transparent, not to mention lower. Their performance kicks the crap out of most other things in this space. And, my personal favorite,

whenever you call them for support, you'll get a human who's empowered to fix whatever it is that's giving you trouble. Visit linode.com slash screaminginthecloud to learn more. That's linode.com slash screaming in the cloud to learn more. That's linode.com slash screaming in the cloud. You had a post on your blog back in May, eight resources for learning Python. Yes.

And reading through it, I've tried most of these resources myself, and I have come to the conclusion that they are all crap for my way of learning. And that's what it comes down to. Giving a talk for a conference is a great way that works. For me, though, the best way to learn something like a programming language, I've tried classroom courses. I've tried videos. I've tried books. The only thing that works slash sticks is me building something with it.

And it is not a particularly efficient means of learning things. If I was capable of paying attention and absorbing something in a structured sense, I wouldn't spend three hours Googling the difference between a string and an int when I'm trying to diagnose some arcane error. It's one of those effectively wind up, oh, cool, so what's the secret

to wind up building a Lambda function? Oh, you just go ahead and iterate forward. And every time you do a new deployment, it winds up incrementing the version number. Why are there 5,000 versions of this Lambda function? Iterative development. It's one of those, oh, great, typos. Did you know that there are editors for writing code that will do syntax checking? Today I learned. It comes down to getting it hilariously wrong and iterating forward for me is the right answer. And people look at this like, oh, some people be called a self-taught learner, but it appears you were never taught, period. But it's like, this is the worst run code I've ever seen. Ah, but it does run. Yeah, that's the, it's awful. I don't recommend that,

but it's the only thing that I found that works. And I am incredibly envious of people who are able to learn without breaking things in hilarious fashion. Well, I have an interesting perspective on this because I'm going to get really nerdy right now, but I am a language, like spoken language. I'm not talking about like coding languages. Like spoken languages are very, very interesting to me. And when I was 15, I made this life goal that I'm going to become a polyglot and I'm going to learn six different languages. That never happened. But one of the interesting concepts in the language learning space is this idea that you learn enough of the language to hit a certain goal. So for instance, if your goal is to go to France to go visit Paris for two weeks weeks You're going to learn enough french to get you through those two weeks or if your goal is to like

Oh, i'm going to teach at a university in spain. Say you're a biology professor. You're going to learn all the spanish biology Terminology so that in that space you'll be able to have full-fledged conversations, but maybe outside of that not so much So I kind of apply that to, that's how project-based learning is to me. You learn enough to get the job done and you may not be super knowledgeable about other things involving the language. You know, if you build something in Python, you might not need to know about tuples or you might not need to know about lambda functions in Python and things like that, but you will be able to get something done that works. So in some ways, it can be very useful, which to me, I love learning in public and I love project-based learning because that to me is like super important and it works for me as

well. But it also, in some ways, you do miss out on some context sometimes, but I don't think it's that big of a deal. If you're trying to build something, Google is going to be your best friend. If there's something you want to do, Google it. And that's what I do all the time. To be clear, when you say Google it, you're talking about looking something up in an online search engine, not turning off something beloved that people have come to depend upon. Yes. Yeah, that's what I mean. So like in the context of Python, that's probably the language I probably learned in, you know, air quotes, the traditional way, taking courses and reading articles. But I've also done a lot of building with it and like breaking stuff and figuring out things in a certain context. So yeah, I probably like a combination of those things. But like you said, project building is the best for you. And I think it's important for people to know that everyone learns differently. There is no linear path to anything in tech, really. Everyone is different. Some people do best with having a CS degree. Good

for them. Some people do best going to a bootcamp. Some people- I have an eighth grade education. I was never the book learning type. It doesn't work for me. Also, it turns out that if you learn only by screwing it up seriously, maybe neurosurgery is not your field. But like with tech. What do you want to do next? Be a pilot? Yeah, that doesn't go well. No, no, no.

But that's not what we're saying here. But like with tech, learn however you want. There is no direct formula for how to become a software engineer or a cloud engineer or whatever your goal is. So yeah, I hope that people become more open to this idea that, you know, there are some thought leaders who are like, you have to do this and you have to learn this first and then do that thing and then read up on it. Like, no, do whatever works for you. Honestly,

do whatever gets you to your end goal. Just like with learning a language, sometimes the way that people do it is they absorb a whole lot of words and some people just have an end goal. They're taking a trip. They want to be able to hold basic conversations. So they learn all the vocabulary they need to know for that. So like whatever your end goal is,

do what you need to do to get there. That's just how I feel. So something you mentioned a few minutes ago was that you were doing front-end work for a while and then moved into Python. There is a perception on Twitter that is crappy and wrong, that, oh, front-end is easy, back-end is the hard stuff, and it's where all the good engineers go.

Well, I don't pretend to be a good engineer, but I can beat things together in Python for a back-end moderately well. I can effectively take this beautifully crafted precision screwdriver set that is Python and use it as a tremendously crappy hammer. But what I'm not able to do is understand the first thing about frontend or JavaScript

or whatever it is that makes that whole stuff work. I have tried repeatedly and I end up more confused than I did when I started. A week in like, what the hell is asynchronous mean and why is it doing this? Yeah, it doesn't go well. So my answer for how I wind up handling front-end has always been, I pay a professional because I find it completely lost. It is, from my perspective, way harder than back-end. Oh yeah. What is wrong with that entire misperception? Okay. Actually, I kind of have a few different philosophies on that because everyone thinks that frontend, well, not everyone, but if you search, oh, learning to code, a lot of the bootcamps or

articles from these tech thought leaders will encourage you to start with frontend, HTML, CSS, JavaScript, because there's this perception that it's easier, like we were just saying. So when I first decided to learn to code, that's the route I was going to take because that's what everyone was telling me to do. Learn HTML, CSS, JavaScript. It's easier. It's a great way to start things out. It was not easy for me. I struggled. It took me so long to get the basics of CSS down. And then when I finally got to JavaScript, I became even more confused and it made me stop. I got to DOM manipulation and was so freaked out that I just was like, you know what, I'm going to take a break. And that break ended up lasting for like six months. So what I decided to do was I'm going to try this backend

thing. I had just gotten a scholarship to the Cloud DevOps Udacity program I was just talking about. And one of the things they mentioned was Python for some reason. So I was like, okay, I have this scholarship. I'm going to get into the cloud thing. And then I'm going to learn Python. Maybe this is going to match my brain better.

So I decided to learn Python and I loved it. It made me fall in love with coding again. And I have this idea that the reason why people view front end as easier is because it's very visual. It's a lot of design aspects to it, especially with the HTML and CSS. It's a lot of colors and all that kind of stuff. And I feel like a lot of people have this perception that anything design-wise is easier and that anything remotely artistic is kind of feminine as well. So automatically anything sometimes for certain people that's perceived as feminine is, oh, well, that must be easy. Drawing and making animations with CSS in JavaScript is easy.

Or creating a front end for an e-commerce store is easy. And it's not. Like, it's not easy. It's the farthest from easy. Like, it's not. It's easier to learn in public even as a white guy, for God's sake. If I wind up getting something wrong, my failure mode is a board seat and a book deal somewhere. It's absolutely, effectively, I am playing life on the easiest of easy modes. So, yeah. One of my first introductions to coding

was through an organization called Coba Closy. And one of our instructors was saying how I believe in one of his CS courses, they like pushed all the women to do web design because web design is seen as like artistic and oh yeah, you design some things. And I guess that has like a feminine flair to it. And so it's automatically perceived as easier. And I'm like, no, it's so not easy. Like I wish that we would get rid of this rhetoric, just demolish it for good, because it's

really not easy to me at all. And not that anything in tech is easy, but we need to erase this idea that, oh yeah, you know, backend engineering is for the real software engineers. Like you're not a real engineer unless you do backend stuff. Like, no, I don't believe that at all. Give all the glory and the praise to frontend engineers because they're doing the thing. I could never, I only touch frontend when I absolutely have to at this point. So yeah. One of the strangest things that I see is that I look at the body of things that I understand and have learned how to do. And my instinctive response that is, oh, that's easy. Whereas all the things I don't know, well, those things are hard. And

this is absolutely not correct in any meaningful sense. However, this is a very common thing where people believe that things they don't know are harder than the things that they do know, which means it directly leads to people discounting the things that they have already learned. The alternative is some of the PhDs I used to work with at a university where they believe, wow, I am the world's leading expert

in this one incredibly narrow field. Therefore, I'm also very good at everything else. And that's a bit of a negative expression of that. But there's really something to be said for don't discount the value that you already know. I'm a huge believer in the idea that everyone could give an incredibly compelling conference talk about something that they know that they think everyone else knows. But the response that they're going to get from the audience is, holy crap, I just learned something awesome. Oh yeah. I agree with this 100%. And like, admittedly, I'm not very good at applying this to myself because I always have this little voice in my head that's like, oh, everybody knows that already. Nobody wants to hear you talk about that.

But like I've told people before, your experience and perspective is uniquely yours. So everyone has something valuable to bring to the table. I know that there are some ways that I understand concepts, even with AWS, because a lot of coding concepts are very abstract. So I have a special way of thinking about things. Even though I'm not a huge fan of web design and front end, I am a very visual person. I'm a very visual learner. So it means that when I tackle

something in AWS, for instance, I have to see things. I have to be able to really visualize it to understand it. And that is a perspective that a lot of people don't have and a lot of people haven't heard of. And they may be visual learners too, but they never think about things that way. So me sharing my perspective could be very helpful to someone. Someone tweeted, oh, I'm trying to explain some JavaScript concepts, but I don't want to drone on and on. And I share with them how I understand classes and object-oriented programming. And it's a very corny, but like, it's the way I understand it. And I think it helped the person to be able to see different ways that you can teach a concept. So, you know, usually when you think of a class, I've heard the car metaphor or whatever, like, oh, the make and the model or whatever. The way I look at it, I look at classes as little

Build-A-Bear workshops in your code. So like everyone who goes to a Build-A-Bear workshop comes out with a bear. Every bear has eyes, every bear has arms, every bear has feet, but the way they look is different, right? So. Well, someone's better at Build-A-Bear than I am. So like, so some bears will have different outfits, different colors, different eye colors and stuff like that, but they're all the bears and that's what classes are. They're all going to be the same object. They just might come out differently depending on how you define them. So each kid is going to go in wanting something different and come out with something different, but it's a bear. So that's how I understand classes in object-oriented programming.

But that's my unique perspective. And everyone has a unique perspective when they approach anything that they're learning or that they're working with. Share that perspective. Share it in a conference talk. And I guarantee you it will blow people's minds. There have been times where I went to a virtual conference and hearing people give talks, even about concepts that I don't know anything about, like React. I don't know anything about React. Does anyone? I guess not. It's probably one of those like AWS type things that you'll never become a master at. But I heard these conference speakers give talks and they blew my mind. Like to this day, there are some things I think about from those talks and I'm sure they thought it was just something normal.

It wasn't a huge revelation to them, but to other people, it could be incredibly valuable. So I think it's super important to like share your perspective and share how you view things, how you view the world. It could be so meaningful to other people and you might not even realize it, which I'm really bad at doing. Like I'm saying all this stuff, but I don't even take my own advice, but I'm trying to do better. I feel like that's, that is probably one of the best life advice tips anyone can get. Like, yeah, I'm trying to do better. That's, that's the, this stuff is hard and you're never going to be able to master it all. But it's definitely of interest watching people evolve and how their learning path goes. If people want to learn more about what you're up to,

who you are and follow your learning and public journey, where can they find you? So I'm most active on Twitter. My username on Twitter is C-O-R-E-O underscore. So that's C-E-E-O-R-E-O underscore. And I talk a lot there. I probably spend more time there than I should. And I also have my,

I just created my blog, C-O-R-E-O-R-E-O dot com, where I'll be posting more articles and sharing my thoughts on various things. And yeah, that's basically the only two places that I post a lot of tech related things. If you want to keep up with what's going on with me and keep up with my journey. Excellent.

And we will, of course, include links to that in the show notes. Thank you so much for taking the time to speak with me today. And, of course, for letting me take the time that anyone's listening to this off so I can watch the next generation learn to effectively cry itself to sleep. Of course. I'm so excited for you and excited for this opportunity and all that kind of good stuff. Thanks once again. Ciara Ford, learner advocate and instructor. I'm cloud economist Corey Quinn, and this is

Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. Whereas if you've hated this podcast, please leave a five-star review on Apple Podcasts. Whereas if you've hated this podcast, please leave a five-star review on Apple Podcasts, along with a comment telling me what other jobs you should not accept while failing the first time. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold. This has been a HumblePod production. Stay humble.