Subscribe
Share
Share
Embed
Ceora Ford is an instructor and learner advocate at egghead.io, a web development screencasting platform. She’s also a technical writer at DigitalOcean and an advisee at BUILT BY GIRLS, an organization that prepares the next generation of female leaders in tech.
Join Corey and Ceora as they talk about why Ceora enjoys learning in public, why people who enjoy mastering topics might want to steer clear of AWS, how AWS is so big that even people who work there don’t know much about what’s happening at AWS, what it’s like to give a conference talk on a subject you’re not familiar in, how learning in public also helps other people learn the material at the same time, project-based learning and why Ceora finds it particularly helpful in certain situations, why Ceora believes there’s a misperception about how difficult front-end development is, and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: 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.
Corey: This episode is sponsored in part by Catchpoint. Look, 80 percent of performance and availability issues don’t occur within your application code in your data center itself. It occurs well outside 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, you know, 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.
Corey: nOps will help you reduce AWS costs 15 to 50 percent if you do what tells you. But some people do. For example, watch their webcast, how Uber reduced AWS costs 15 percent 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. nOps helps quickly discover the root causes of cost and correlate that with infrastructure changes. Try it free for 30 days, go to nops.io/snark. That's N-O-P-S dot I-O, slash snark.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Ceora Ford, who is among other things, a software engineer, a digital marketer—historically—and an educator at egghead.io. Ceora, welcome to the show.
Ceora: Thanks for having me. I'm so excited.
Corey: 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 listening 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’s… 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.
Ceora: Of course. I'm so excited that I get to have this opportunity.
Corey: 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 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 the show by this point, great. Good to know: now at least I've learned that, nope, 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?
Ceora: Okay. Ah, 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 different projects.
So, one of the things I'm doing is, I'm looking 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 for 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 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, you know, sometimes we just forget about them. And I am in that category so much, so I decided to start this project that will 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.
Corey: 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, 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.
Ceora: Oh yeah.
Corey: 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.
Ceora: Yeah. Well, I have, fortunately—especially through my work with egghead—I have been introduced 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, you know, someone's going to pick out one of my mistakes and hate me or something. Like, coming up with all these different scenarios.
And sometimes, yeah, you do get reply guys who were 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 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 to a 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.
Corey: 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.
Ceora: 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 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—[laughs].
Corey: No.
Ceora: [laughs]—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, you know, 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 don’t want to say basic—but I probably would have just stuck with, you know, front end web development, those kind 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, “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.
Corey: Oh, yeah. But what amazed me when I started getting into deep into the space is I’ll talk to someone at AWS who is 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? 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.
Ceora: Yeah. Yeah, I totally agree. I totally agree with you. So, it's 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. 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 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.
Corey: 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 3500 blog posts published.
Ceora: Wow.
Corey: And I asked him about this because I've started to experience an aspect of this. 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 asked 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.
And 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. You're going to learn it, or you're going to give a really crappy talk. 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.
Ceora: 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, 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. 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, 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.
Corey: If you're listening to this and looking for a speaker at your events, you should be paying attention to this.
Ceora: [laughs].
Corey: 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/screaminginthecloud to learn more. That's linode.com/screaminginthecloud.
Corey: You had a post on your blog back in May, “Eight Resources for Learning Python.”
Ceora: Yes.
Corey: 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/sticks is me building something with it. And it is not a particularly efficient means of learning things. I
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—“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 5000 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 are 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 and 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.
Ceora: 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 coding languages. 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, 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 super important. And it works for me as well, but it also, in some ways you do miss out in 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.
Corey: To be clear, you say Google it, you're talking about looking something up in an online search engine—
Ceora: Oh, yes.
Corey: —not turning off something beloved that people have come to depend upon?
Ceora: [laughs]. Yes.
Corey: Excellent.
Ceora: Yeah, that's what I mean. So, 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 breaking stuff and figuring out things in a certain context. So, yeah, probably 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 boot camp, some people—
Corey: I have an eighth-grade education. I was never the book learning type, it doesn't work for me. Also turns out that if you learn only by screwing it up seriously, maybe neurosurgery is not your field.
Ceora: [laughs]. But, like, with tech—
Corey: What do I do next, be a pilot? Yeah, [laughs] doesn't go well?
Ceora: No, no, no. But that's [laughs] not what we're saying here. But 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 that.” 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, whatever your end goal is, do what you need to do to get there. This is how I feel.
Corey: 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 front end, 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, 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.
Ceora: Oh, yeah.
Corey: What is wrong with that entire misperception?
Ceora: Okay. Actually, I kind of have a few different philosophies on that. Because everyone thinks that front end well—not everyone. But if you search, oh, “Learning to code,” a lot of the boot camps or articles from these tech thought leaders will encourage you to start with front end, HTML, CSS, JavaScript because there's this perception that is 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.
You know, 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 six months.
So, what I decided to do was I'm going to try this back end 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 had 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, CSS, it's a lot of, you know, 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 and JavaScript is easy. Or creating a front end for e-commerce store is easy. And it's not. It’s not easy. It's the farthest from easy. Like, it’s no.
Corey: 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.
Ceora: [laughs]. So—
Corey: Ah.
Ceora: Yeah. One of my first introductions to coding was through an organization called Kode With Klossy, and one of our instructors was saying how, I believe in one of his CS courses, they 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 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, back end engineering is for the real software engineers. You're not a real engineer unless you do back end stuff.” No. I don't believe that at all. Give all the glory and the praise to front end engineers because they're doing the thing I could never—I only touch front end when I absolutely have to at this point. So, yeah.
Corey: 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 no, 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 of what you already know. I'm a huge believer in the idea that everyone could give a credibly 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.”
Ceora: Oh, yeah, I agree with this 100 percent. And admittedly, I'm not very good at applying this to myself because I always have this little voice in my head that like, “Oh, everybody knows that already. Nobody wants to hear you talk about it.” But 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 shared with them how I understand classes and object-oriented programming, and it's a very corny—but 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 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—
Corey: Well, someone's better at Build-A-Bear than I am.
Ceora: [laughs]. So, some bears will have different outfits, different colors, different eye colors, and stuff like that, but they're all 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 as a bear. So, that's how I understand classes and 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—
Corey: Does anyone?
Ceora: [laughs]. I guess probably one of those AWS type things that you'll never become a master at. But I heard these conference speakers give talks, and they blew my mind. 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 can be incredibly valuable, So I think it's super important to 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. [laughs].
Corey: I feel like that's that is probably one of the best life advice tips that anyone can get. Like, “Yeah, I’m trying to do better.” That's the…this stuff is hard, and you're never 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 in public journey, where can they find you?
Ceora: So, I'm most active on Twitter, my username on Twitter is @ceeoreo_. 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 just created my blog ceoraford.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.
Corey: Excellent. I will of course include links to that in the [00:32:30 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 is listening to this off so I can watch the next generation learn to effectively cry itself asleep.
Ceora: [laughs]. Of course, I'm so excited for you and excited for this opportunity and all that kind of good stuff.
Corey: Thanks once again, Ceora 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 along with a comment telling me what other jobs you should not accept while failing the first time.
Announcer: 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.