Subscribe
Share
Share
Embed
Jill Rouleau is a senior software engineer at Red Hat Ansible who maintains AWS and other cloud modules. Prior to working on Ansible, they worked as an OpenStack engineer on TripleO, an OpenStack deployment project. Over the years, Jill also worked as a cloud reliability engineer at Canonical Ltd.; was the owner of Bespoke Software Solutions, a consultancy specializing in open source, cloud, and emerging technologies; and served as an operations engineer for Limelight Networks.
Join Corey and Jill as they discuss what it’s like to be on the Ansible engineering team, what Jill thinks about various programming languages, including Python, YAML, and XML, how familiarity with languages can help accelerate open source adoption and contributions, what Jill does to encourage first-time open source contributors to stick around, how answering the what can I do to help? question can be tricky, what Ansible is doing to increase contributions in the future, Jill’s advice on what you can do to start a career in tech, why diversity in experience and backgrounds is critical for tech companies, 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 brought to you by DigitalOcean, the cloud provider that makes it easy for startups to deploy and scale modern web applications with, and this is important to me, no billing surprises. With simple, predictable pricing that’s flat across 12 global data center regions and UX developers around the world love, you can control your cloud infrastructure costs and have more time for your team to focus on growing your business. See what businesses are building on DigitalOcean and get started for free at do.co/screaming. That’s D-O-Dot-C-O-slash-screaming and my thanks to DigitalOcean for their continuing support of this ridiculous podcast.
Today's episode is sponsored by Springboard. If you want hands-on experience, getting deeper into machine learning, check out Springboard's machine learning, engineering career track. This program is for existing software developers who want to get deeper into machine learning without driving themselves mad. With springboards one-to-one mentorship that is closer than ever. They also offer a job guarantee in which you pay nothing until you're gainfully employed. To learn more, visit springboard.com and apply for free. Use the phrase "AI Springboard," and the first 20 students will get a $500 scholarship. That's springboard.com code "AI Springboard."
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I always like talking to people in the open-source community, and that goes double if they're not lunatics. From that perspective, welcome Jill Rouleau, a member of the Ansible engineering team focused on maintaining AWS and other clouds, if that actually existed, which I'm not convinced that they do. Your day job is a senior software engineer at Red Hat, but you identify more as a member of the community. Jill, first, welcome to the show.
Jill: Thanks for having me, Corey.
Corey: Thank you for agreeing to tolerate my various slings and arrows, by which of course I mean, stupid puns. So, your day job is working at Red Hat, but you do identify as a member of the Ansible engineering team, which at first struck me as really discordant until I remembered, oh, that's right, Red Hat bought Ansible, and suddenly everything made sense again. Every once in a while I drop something off of the mental stack. But, now that I'm up to speed on this, talk to me a little bit about what is it that you would say it is you do in the context of the Ansible community?
Jill: So, the AWS modules for Ansible are entirely community-made content, all of the modules have been written, and submitted, and are maintained by various members of the upstream Ansible open source community. So, my job is mainly to, kind of, oversee that community, make sure that things are moving, help review pull requests, maintain CI, and just generally make sure that everyone has what they need to get those modules, kind of, submitted, improved, update new features, and maintained so that people can make use of them.
Corey: So, Ansible was what I like to think of as, well, I'll call it second wave, but no one is going to agree with that, so let's just get that out in the open right now. Originally, if we go—we'll ignore the early era of Bcfg2 and other terrifying things—the real first broadly adapted wave of configuration management systems was Puppet and Chef. You can decide the order on your own. I am not a cloud historian; I don't care. The next phase of, “Great, we're going to go ahead and do something better.” And the two shining lights in that space at the time were SaltStack and Ansible. I was one of the early developers behind SaltStack, which is why it, sort of, isn't the huge thing that it could have been because everything I touch withers and dies. Ansible, on the other hand, was something that I didn't touch and now has become a household name in the infrastructure automation space. How have you seen that, from someone who's actively been involved on, shall we say, the winning team?
Jill: [laughs] I think they both win in different ways. I was actually also an early SaltStack user. I, kind of, got into this space from a background as a sysadmin who was using these tools, and eventually, I wanted to start contributing back to them. I think one of the big differences you find between maybe some of the earlier tools and what we see now is the ease of use and the ease of modification. Salt and Ansible are both written in Python and maintained through a horrible series of YAML files.
Corey: Oh, yes, we should instead all organized around XML as the way in the light of the future.
Jill: Yeah, no, let's not with that. But I think Python is a very accessible language if people need to patch something, modify something, write something custom to deal with some homegrown internal service that they have. And YAML, for all of the horrible things you can do with it, is somewhat more readable than things like XML or having to learn a new DSL. It's at least approachable from looking at a playbook or a state file for the very first time and trying to read in, kind of, human language, what those things are doing. And I think that helps with adoption and with getting people to contribute back when the bar is lower because it's more familiar tools or languages.
Corey: I absolutely find that that's one of the better aspects of YAML. With JSON, it seems like you get lost in a sea of braces, parentheses, commas, missing commas, commas that need to be there, and ultimately feeling like you're trying to talk to a computer rather than something a human being can consume. For better or worse, I really do think that YAML is the right answer for an awful lot of these things. But that's not really where I tended to see most of, let's call it, the mistakes get made. For me, it was never the configuration management piece. It was the—I mean, if we look at it across the board, there was a shift that I think none of the players that I've mentioned saw coming, and that was this giant embrace of immutable infrastructure and early on that was crap. Oh, you want to do a one-line change, great. We're going to build a new AMI, we're going to ship a whole bunch of new systems out there, or VMs, or whatever the hell insane thing we're building now, and that'll be great. Your code will be in production in just 45 short minutes. And this was laughable. Then Docker, Docker, Docker came along, and suddenly, the world shifted as developer workflows started to impact operations. Everyone was angry about this. I was certainly angry about this. But you can't deny today that if you're starting something greenfield, that configuration management does not have the center place that it once did in the ecosystem. Would you agree?
Jill: I would agree with that. I think with Ansible especially, I'm not sure as much with SaltStack, But Ansible definitely had a lot of very early adoption, not from operations people but from developers. You know, when I first heard about Ansible, it was fairly new. I want to say it was maybe 2013 at, actually the Southern California Linux Expo. There was a panel and they had all of these config management tools up there. And someone from Ansible was there talking about it. And I looked at that, and I'll admit, I laughed. Oh, that's just a thing for developers who don't want to go through process. I don't want developers SSHing directly into my servers as root. Haha, I would never want something like that going on. And here we are today. But I do think that easing that developer friction caused a lot of adoption that sysadmins, maybe traditional sysadmins were not expecting and had to, kind of, catch up to.
Corey: One of the things that I think sped Ansible adoption that they got very right, and on the SaltStack side we got wrong, was the idea that every communications model happens over SSH. There have to be keys in place, it has to be able to address the right thing at the right time. But we had already—from our legacy of managing systems—we intrinsically understood SSH. We knew how it worked; we knew the security model; we knew the problems, and pitfalls, and caveats that went into that. Whereas with Salt, it was, oh, we're going to run on top of ZeroMQ, then we’re going to use some compression on top of it—it originally was Python Pickles, then became MessagePack.
And you had to learn how all of this protocol stuff worked, and there were new ports to care about in firewall contexts, and suddenly it looked like an uplift, even though it really, kind of, wasn't in some ways. Ansible nailed that in a way that I don't think we understood early on in the Salt world, that this mattered. It resonated because it fit the mental model people had of how systems were going to work. Back in, I want to say the very early 2010s, I had a boss who decided to effectively imagine a configuration management from first principles, Hacker News-ing his way through it. He was kind of right because he conceptually built Ansible in his mind, only crappy because Hacker News first principles.
Jill: You know, I would love to see Hacker News actually build something that they say they can build in the weekend, and then maintain it for eight years. Ansible has been around for almost eight years, and that's the maintenance of that thing that you build in a weekend via Hacker News, is always, kind of, the kicker. But, there are some ideas there, of having something that's simple and easy to use, and that doesn't require shoehorning into a lot of your infrastructure, that just kind of works with whatever you're doing. Ansible doesn't have to take everything over. It doesn't have to be the only answer. And you can use Ansible to deploy your Salt stuff and deploy your Puppet things if you really wanted to do that. But you're right, yeah, it fits in using the models we already have of SSHing onto a box and hopefully not doing things by hand; doing things by YAML instead, and doing a hundred boxes all at once.
Corey: What always astonishes me is no matter how dyed in the wool anyone is, they're adamant that everything we do is immutable infrastructure. It is cattle, not pets. It doesn't take more than about 30 seconds to find the exception case and, “Oh what do you use for that?” “Oh, Ansible. But don't tell anyone.” It is super easy to get up and running with. It's a great tool. The challenge, as well, is at first getting people to admit they're using a thing that for some reason the cult of Docker has convinced them that they should be deeply and profoundly ashamed about is the first problem. The next challenge is figuring out how to get people involved. I mean, you say that you're a community engineer. What does that look like? How do you get people to care about a configuration management system in this year of our Lord 2020?
Jill: Most of the people, I think, that I see coming into Ansible and then sticking around are trying to scratch some itch that they have, you know? Oh, AWS released a new feature and the modules don't support it yet. Well, I want to use that feature, so I'm going to write a patch, and submit it up on GitHub, and see if I can get it submitted for inclusion. And then, getting those people to stick around is one of the hard parts that we have to do is encouraging them that, “Hey, that's awesome. Thank you for submitting.”
Making it a good experience so they want to keep coming back, so they can see all of these things that I need to do. You know, if you're doing anything significant on cloud for all that we say we want to automate it anything away at some point, you're probably writing something. You're writing some amount of code, Why not submit that back upstream so that you can pull it back downstream and use it via Ansible or so that other folks can. It's getting people who are already doing these things in isolation to want to come back and give it back to the community.
Corey: One of the early community attributes in SaltStack, which really got me into contributing code open source is something that in recent years Ansible has adopted, and I love it. If you go back into the mists of time, from my earliest pull requests against SaltStack, you saw that Tom Hatch, the guy that built SaltStack and founded the company, would accept whatever I proposed, and then immediately there would be another pull request that was merged from him fixing my horribly broken idioms. Now, what people don't see is the fact that, first, Tom Hatch was and remains the nicest guy in the world. And he never said a word of criticism about anything I did, even though, honestly, it kind of deserved an awful lot of criticism.
It was the welcoming aspect of the community that really inspired me to continue sticking around and participating in this. And recently Ansible has definitely gone down that path as well. It gets away from some of the old traps of overly corporate software in some respects where it's well, we need to have what effectively looks like a change advisory meeting on every pull request that goes through, and you can see the governance gone amok. It seems that Ansible is largely avoided that. It's still welcoming for folks who are, “Well, I don't really know how to code, but it's Python, so how hard could it be?” as I once said. And it's there in a way that a lot of tools and projects simply aren't.
Jill: So, that's awesome. I'm really glad that you see that and feel that way because we do work hard—Ansible is a really large really, really busy project and it is challenging to scale that type of feeling for people when they come into the project. There are literally thousands of modules in Ansible on top of the actual core engine code, and everything else that we have to maintain to make Ansible work. There are hundreds of people putting work into it, and only some of them are actually core engineers or Red Hat people. The majority of the contributions that we get are from the community and that balancing act of figuring out—we're not maybe going to merge everything that folks sent in and then come along and clean it up later, but if you open a pull request against Ansible someone is going to review it and give you feedback and hopefully be welcoming and let you know that, “Hey, thanks for the submission. We have, maybe, some feedback to get it into shape.” We require, you know, CI tests so that we don't merge broken code, but we work really hard to make sure that folks have a good experience and want to come back.
And I think one of the things that has helped is we've empowered a lot of our community to be that person. You know, you don't have to wait for myself or one of my team to review your code. We actually have community members that are subject matter experts on the different things that we do, like AWS, or various other modules, and they're empowered, once they've been a member of the community for a while, to pay that forward to other people the same way that they were welcomed in and trusted to contribute to the project. So, hopefully, that's a part of it.
Corey: Absolutely. Again, if you're on the other side of this, and someone is new to the project and starts contributing, and your immediate response is, “Listen idiot—” If that's how you're starting your comment, maybe reconsider about whether that's the impression you're trying to give, even if what they're proposing is patently ridiculous, as is almost everything I wind up submitting, either intentionally or accidentally. Ansible lives on [00:15:48 GIF-huhb], or GitHub as some people choose to mispronounce it, and one of the great features that GIF-huhb offers is inside of a given project, you can tag various issues as good first issues for someone looking to get into a project. What I haven't seen yet and really wish they would put out there, and Ansible would be a great fit for such a thing is good first projects to contribute to. One of the challenges of another common player in the space is Terraform out of HashiCorp. I constantly have things I want to improve, and I periodically go over and start to build something that might address the problem, and I got about 10 seconds in before I realize, “Oh, wait, that's right. It's written in Go.” Go is for smart people, and I can only stumble my way blindly through Python, Bash, and a little bit of Perl due to previous life choices that went awfully. So, that's not really available to me.
But being able to say, “Great, I have moderate Python skill and I'm looking to get involved in an open-source project. What can you recommend?” It turns out it's super hard to get a good solid recommendation because asking any person for this, you get a giant pile of bias back of whatever project they love, whatever problem they're trying to work on this week. It isn't the most, I guess, accessible onramp for folks who are very easily overwhelmed by the sheer variety of what they could be working on.
Jill: Yeah, so and with Ansible, especially because right now, today, we have a single repo that contains the Ansible engine code, and all of the modules. This is the batteries included model, where we have everything from modules that can control your Cisco switches to your AWS Cloud to your Linux boxes, OSX machines, Windows hosts, security appliances. Someone who shows up and just says, “Hey, I want to help, what can I do?” There's almost too many things that they could do. So, some of that, for us, is asking, “Okay, what are you interested in? What are your skills, what are you as subject matter expert on?” and then maybe getting them paired up with either a working group or an interest group for that specific area, like cloud, or AWS, or network appliances, and then, kind of, moving down. But that does require them to make that initial showing up and asking.
It's a lot harder to look at just showing up to the repo and saying, “What can I work on?” because there are so many thousands of things that could be worked on, which is actually a scaling challenge that we've been working on right now, for the last year. How do we scale the size that we've gotten to and the breadth that GIF-huhb—so to say—dot com/Ansible/Ansible covers? How do we scale the management of that project, and the community onboarding, the community management of that? So, in the future, later this year, we will actually be splitting that out. Ansible Collections will be a new packaging feature for how content that goes into Ansible can be, kind of, split up and managed from a repo and packaging perspective.
So, at least for the AWS side of things, one of my plans, once we split that out into its own repository that lives on GitHub, we can have things like project boards that make sense, and wikis, and different things using some of those GitHub tools so that people can show up, just look at the repo that interests them, just look at the content that their expertise makes them a good fit for and say, “Oh, here are some projects. Here's a board that has some ideas, some open issues that needs to be worked on,” and make it a little easier for people to get directly involved with just the things that they care about.
Corey: This episode is sponsored in part by N2WS. You know what you care about? Many things, but never backups at least until right after you really, really, really needed to care about backups. That's what N2WS does for your AWS account. It allows you to cycle backups through different storage tiers so you can back things up cost-effectively and safely. For a limited time, N2WS is offering you a hundred dollars in AWS credits for setting up their free trial, and I encourage you to give it a shot. To learn more, visit snark.cloud/n2ws. That's snark.cloud/n2ws.
Corey: The problem is, is that we all have—at least those of us who've been around long enough—have experiences with the exact opposite of what you just described as far as welcoming and encouraging and enthusiastic community. [coughs] Debian [coughs]. Sorry—
Jill: [laughs]
Corey:—that's not—something in my nose here. So, as a result, some people were driven away from this. What's curious to me is your background. This is very much not your first open-source rodeo. Prior to this, you were heavily involved with OpenStack, which was a fascinating project across a wide variety of different things. And it was interesting watching that evolve. For a long time I really, really wanted to see that succeed. And for one reason or another, I get the sense largely due to governance, it didn't fulfill the promise it had laid down. And I still feel that lack to some extent. Now, it's obviously still seeing adoption in certain sectors; telcos love it. But that was interesting just watching from the outside. Can you tell me a little bit about how the community piece of that worked?
Jill: That has been an interesting challenge for me moving from a project like OpenStack to something like Ansible. OpenStack is also a very large and very complicated project or set of projects. One of the things that happened there, though, is there was a lot of hype, or, you know, like you said about, “Oh, it's going to take over the data center. It's going to be the new way of everything. You'll be able to run your own cloud, your own data center, and everyone is going to do this thing.” For all of the hype that there was, though, and all of the excitement—and there was money being thrown around; there were huge parties; there were lots of excesses—which surely aren't happening in any other communities at the moment, that hype train hasn't just moved on to any other projects—but the people that showed up to do the work, were the people from the telcos or from organizations like CERN, people that had specific use cases that weren't being solved, primarily were the people that showed up and said, “Hey, this sounds really cool. I have engineers that I want to put on this.”
It ended up being a very, very corporate-sponsored project where you had all of these different organizations showing up and saying, “I have use cases to offer. I have engineers. I have test environments that we can use, I want to do work.” And not in isolation. Public Cloud certainly had a part of it in easing barrier for smaller people to just get things going without having to deploy a private cloud. But I think that was a big part of how OpenStack ended up moving into this niche where it's serving a couple of really specific verticals for which there is almost no other alternative on the market, but a lot of that was driven by these corporations showing up and saying, “I want to commit developers to this. I want to contribute engineers. I'm going to send my operators to come bring their use cases.” And that ended up being a big part of what drove OpenStack in that direction.
With Ansible, it's a lot easier for people to make what you might call drive-by contributions to do that. Hey, I scratched an itch I had. I wrote a module or I patched a module, have a contribution, and move on. It was much more complicated to do something like that in OpenStack, where you're dealing with really complex infrastructure. There had to be, kind of, more context that you had to learn to get involved in contributing to understand how do I actually manage a hypervisor? How do I actually manage software-defined networking? So, you ended up with a different, and much more static, group of corporate and specific use case backed contributors. That pattern doesn't apply as much to something like Ansible, where people are using it for so many different things, and it's much higher up the stack, you can just have one-off, two-off low barrier to entry contributions.
Corey: You can wind up saying an awful lot critical at every big company in this space. Well, maybe you can’t. You have an actual, you know, job and employer, but I can. But there's precious little to fault with how Red Hat and its various associates, affiliated projects, and acquisitions, and divisions and whatnot, deal with the open-source community. Not everyone likes the outcome of every decision, but I don't know too many people who are going to sit up and say that they felt that their concerns were not heard. That they couldn't communicate with the rest of the community, etc. It's strange in that Red Hat feels almost like a unicorn, where they are more or less the success story about open-source companies going public, and they've been the edge case exception in many respects for 20 years. It's really interesting watching the journey continue to evolve.
Jill: Yeah, I mean, and like all open-source companies, Red Hat is full of people who care passionately about the community and what we do. We're just all, kind of, lucky enough to get to do it as our day jobs instead of side projects. But, we all really do care that much about the community and what we're doing.
Corey: So, if you were giving advice to I don't know, the people that we were back when we first met, what was it now 15 years ago almost, looking back, the road that we walked is very clearly closed. How would you go about finding the path forward into a world of contributed to open source in a day when there are so many different directions to go in, and it is always increasingly murky to find a path to get somewhere sensible? Where does the next generation come from?
Jill: So, this is actually something that I end up trying to answer a lot. I'm also super involved in user groups, I help run my local LUG. Linux User Groups are still a thing, it turns out, in 2020. And we get young folks coming in all the time, whether they're recent grads or maybe they can't afford to go to college here in America, where that's the cost of a small mortgage. And they want to know, how do they get their foot in the door? How do they get that first job? How do they get started? I got my start—I’m a career changer. This was not my original plan. I do not have a CS degree. I got really lucky that I, kind of, got in approaching the tail end of when you could just show up and say, “Hey, I know stuff about computers, you should give me a job.” And people would do that. Which is a little bit bonkers if you think about it, but that's—and I think you, kind of, joined the industry at a similar time as I did.
You can't do that anymore. You can't just show up and say “Hey, I've been playing around with—I got Linux running on a PC in my spare bedroom. You should give me a job managing your servers.” And it's hard to be in that spot now. There aren't a lot of great answers. You have the [00:26:06 unintelligible], well, throw a bunch of stuff up on GitHub, and build a website as a portfolio, and hope and pray, but the market right now is so flooded with people trying to do that, that it's hard. And the only advice I can really give people is show up to things. Show up to meetups, and meet people, make connections, network, go to conferences, if you can afford to. There are lots of really great local conferences that tend to be affordable. Show up to things and talk to people because right now it really does feel like you don't have that, the advantage of a CS degree and an internship, getting your foot in the door right now is almost entirely about networking, and meeting people, giving talks at meetups and saying, “I know stuff. I'm willing to work hard. I'm willing to learn things. Can you help introduce me to someone, give me a referral, walk me through making a contribution, connect me with a project that is not going to exclude me, or crap on my work, or not pay attention to my pull requests?”
And having that kind of personal touch, helping other people, helping the next generation get in, it's, kind of, on us to help them. There’s some paths. Outreachy is a really good one that OpenStack is a big member of, getting people paid internships that don't have to go through a CS program, and matching them up with open source projects where they're going to get one-on-one mentorship and help making those first contributions, learning their way around a project, learning the 21st-century nettiquette, as it were, for getting involved. I love Outreachy. I think they're great. I wish more projects would support them. But it's things like that, that I think we need to be doing more of.
Corey: That's the big problem that I think we see almost industry-wide is we seem to think that only the super senior people have something valuable to contribute, but that is very clearly not true, even at the company level. I lose sight of the sheer number of companies out there who I can ask them, “Great, explain to me what you do.” And they talk for a minute and, “Okay, I get it. Now, explain to me what you do if I don't have a decade of experience as an engineer.” And they have no idea where to begin. Spoiler; a lot of junior people are terrific at being sounding boards for telling these stories, or coming up with ways to make it more accessible to a broader group of folks. It's not just the people who can think about something hard enough, and it starts smoldering. Everyone has something to contribute, and I really wish that there was more of a broader awareness of that.
Jill: Yeah, I mean, if everyone that was working on software, came from the same background; had the same use case, things would be really boring. We wouldn't end up with a lot of tools and things that we have now because everyone would be using the same editor, on the same platform, with the same hardware, in the same configuration. There would be a need for less of us. We all have different needs, we have different backgrounds, we have different ways of approaching problems. I've had the good fortune to work with some really amazing junior people over the years who have caused me to learn new things and question things that I know, and I'm so grateful for that.
I can't imagine why anyone would not want to bring in more voices and more people. If we're not bringing new people in, I don't understand what we think is going to happen to our projects in the next couple of decades. Eventually, all of us will age out of being able to make massive contributions. Who is going to be maintaining these tools in these projects or building new better ones if we're not bringing new people into the industry and into our communities? Just survivorship of projects. There's not going to be any more gray-haired neck-bearded old school Unix hackers. We've got all of them. Everyone that was on IRC in the 90s that wants to be doing this stuff mostly is. We have to let new people come in and do stuff.
Corey: There's no room anymore for gatekeeping.
Jill: There never was. I mean, it was happening and it's still happening, but it was never okay. There was never room for it. I mean, we're suffering now from all of the people that we have either kept out of the industry or pushed out over the years. That's equally as much of a problem that I don't think we talk about nearly enough. How many people have been driven out of his industry because of gatekeeping that had something of value, that had experience and knowledge and we drove out? Yeah, that's not okay.
Corey: No, it's really not, and you're correct. It never has been. For some reason, I think a number of us deluded ourselves at the time into, well—believing all the tropes of, “Well, the good people will be able to put up with a toxic, crappy environment.” And what a broken, weird thing to say, or even to believe. But I was advocating for such things, many moons ago. It's was always come from place of insecurity. It's, “Well, I'm not anything special, so if we let anyone in, they'll learn that there's not anything special. So, I have to cling to this thing that makes me be unique and different, and of course, better than everyone else.” And there's room for more people at the table. My God, it's strange seeing how so many of those conversations played out, I look back at some of the things I said in the early naughts, and I'm ashamed.
Jill: And I think most people have something like that. We've all had to do learning or growing about something at some point in our lives, whether it's gatekeeping to open source communities or something else. The idea that people can't learn, and grow, and become better people is just patently false. Everyone has had something at some point in their life that they were mistaken on, or that they maybe were a bit of a jerk about it to someone at some point. If we can't just say, “Hey, oops, I made a mistake, and I'm not going to make it anymore.” And be big enough to own those things and move forward, I think that's a sign of a better person. Being able to say, “Hey, I've screwed up in the past, but I'm going to do better going forward,” than someone who just professes to be perfect all the time because no one is perfect all the time.
Corey: Oh, absolutely.
Jill: Except maybe you, Corey.
Corey: Well, hardly. I mean, when I say I did some things that I regret and feel ashamed about, I'm not talking anything horrifyingly egregious that would get me voted off the island. I'm talking about answering beginner questions on IRC with RTFM. Go read the freaking manual. I'm not talking about, “Well, you're not actually a person.” No nonsense like that. My god, I was never that big of a dumpster goblin. But even now it's everything is new to someone, and rather than viewing your castle as being under siege by newcomers, you get to share this awesome thing with other people and watch them learn. And fun story: If you teach someone something, you get to experience it again through their eyes. Also, I can't think of a better way to learn something than explaining it to someone else.
Jill: Yeah, I totally agree. I was fortunate enough a couple years ago to launch a new NOC, or a Network Operations Center, at a job that I was working at—
Corey: The home of the original Knock Knock joke.
Jill: Hahaha. [laughs], but it was at an organization where we'd never had a junior team before. And it was, “Well crap, we're going to hire these people and put them in charge of really important systems. We're going to have to train them. We're going to have to figure out how to actually work with people who aren’t super senior engineers.” So, I put together a three-week training program, went out, executed it for all of the onboarding new hires. I had a blast. I had so much fun watching these folks learn how DHCP works because you know, DHCP… We didn't have to troubleshoot all of the DHCP problems on new-hire laptops.
That was spectacular. I would love to do that again. But watching them get it, watch them figure out, how do I troubleshoot this? How does it work? And then making connections between things and then going off on their own and working, and it was like, “Oh, my little NOC techs are all independent now, and I trained them, and it was awesome.” And getting to see them grow was one of the best feelings. Seriously if anyone has not done that before, has not mentored someone at a significant level, or trained someone a totally new skill and watched them grow and learn and become independent with it, do it. It is the best natural hot you can possibly get.
Corey: Fantastic. And I think that's probably a good place to wind down this conversation. If people want to learn more about you, your thoughts on various things, or how to get involved in the community, where can they find you?
Jill: Well, you can track me down on Twitter. That's @jillrouleau. That’s J-I-L-L R-O-U-L-E-A-U. Or on the Freenode IRC network—we are still alive and well on IRC—I am jillr, and you can come track me down in any of the Ansible channels on IRC.
Corey: Thank you so much for taking the time to speak with me today. I appreciate it.
Jill: Thanks, Corey.
Corey: Jill Rouleau, member of the Ansible engineering team and senior software engineer at Red Hat. I am 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. If you hated this podcast, please leave a five-star review on Apple Podcasts and I will do my darndest to pretend to care.
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.