BT

Facilitating the spread of knowledge and innovation in professional software development

Contribute

Topics

Choose your language

InfoQ Homepage Podcasts Tammy Bryant Butow on SRE Apprentices

Tammy Bryant Butow on SRE Apprentices

Bookmarks

In this episode, Thomas Betts speaks with Tammy Bryant Butow, principal SRE at Gremlin about training new site reliability engineers. The discussion covers a formal SRE Apprenticeship program Tammy led at DropBox, and gets into ideas about the best way to teach people new technical skills. There are benefits for the trainees, the mentors, and the company, when you put in the effort to create a formal training program.

Key Takeaways

  • Hiring new site reliability engineers can be challenging. Dropbox decided to create a program to teach a cohort of students the skills necessary to be successful SREs.
  • A non-traditional approach to find engineers will naturally lead to a more diverse set of applicants. Bringing in people with different backgrounds can lead to new ways of looking at common problems.
  • Training should start with small tasks, letting the engineer learn by doing. Gradually these build from one-day tasks to longer, one-week, or one-month projects.
  • If your company creates a formal training program, it needs to be communicated to everyone, so there is understanding and proper expectations when the apprentices work with other employees.
  • In any new role, there is a need for understanding how to communicate with other people. Inviting junior employees to meetings allows them to see how senior members of the team interact to solve problems.

 

Transcript

Introduction [00:17]

Thomas Betts: Hello, and thank you for joining us for another episode of InfoQ Podcast. I'm Thomas Betts, cohost of the podcast, and a senior principal software engineer at Blackbaud. Today, I'm speaking with Tammy Bryant Butow. Tammy is the principal SRE at Gremlin, where she works on chaos engineering, the facilitation of controlled experiments to identify systemic weaknesses. Gremlin helps engineers build resilient systems using their control plan and API. Tammy previously led the SRE teams at Dropbox responsible for databases and storage systems used by over 500 million customers. Prior to this, Tammy worked at Digital Ocean and one of Australia's largest banks in security engineering, product engineering and infrastructure engineering. Tammy is the co-founder of Girl Geek Academy, a movement to teach one million girls technical skills by 2025.

Thomas Betts: Tammy, welcome to the InfoQ Podcast.

Tammy Bryant Butow: Thanks so much for having me, Thomas. Great to be here.

Thomas Betts: A few months ago, you spoke at QCon Plus about an SRE apprenticeship program, but I want to set the stage. And first, I think it would be helpful to our listeners to know what do you do at Gremlin? What's the product you work on? What is chaos engineering, as a capital C, capital E product?

Tammy Bryant Butow:Gremlin is a chaos engineering service. And as a company, we're on a mission to help build a more reliable internet. I've been at Gremlin for almost four years now, so I joined after I'd worked at Dropbox, which is where we did the SRE apprenticeship program. And at Gremlin, what we've created is a SaaS platform to help engineers safely experiment on complex systems in order to identify weaknesses before they impact customers and cause revenue loss. We're really helping folks prevent catastrophes, avoid huge downtime. Gremlin was founded by our CEO, Kolton Andrus, and our CTO, his nickname is Forni. That was back in 2016.

Tammy Bryant Butow: Since then, we've raised 26.8 million in funding from Redpoint Ventures, Index Ventures and Amplify Partners, and our customers are JPMC, Grubhub, Twilio, Walmart and many more. So it's really exciting to be able to be practicing chaos engineering and working for a chaos engineering company. I've been practicing chaos engineering for over 12 years, so a perfect place for me to work.

SRE apprenticeship program at DropBox [02:32]

Thomas Betts: Yes, it sounds like it. Let's move onto, you said, Dropbox is where you had this SRE apprenticeship program. I want to understand, why did you take the effort to make a formal apprenticeship program? What were the goals? And I guess, maybe in your own words, describe what is the role of an SRE you're trying to accomplish with that?

Tammy Bryant Butow: When I first joined Dropbox, I was the SRE manager initially for the databases team, and they'd ask me can you please look after this team first, which is... Dropbox, at the time, had 200 million customers, 500 petabytes of data, a lot of responsibility there. And the team was very small, so when I first started working at Dropbox the databases team was about four people. And we definitely needed to be able to hire more SREs to work at Dropbox, work on the infrastructure team, but it's very hard to hire SREs. Everyone would know this out there. If you've tried to hire site reliability engineers, it's hard to find them. A lot of the time there's not so many of them, and they work at companies where they're very happy. They're enjoying their work, so it's hard to get them to come in. Hey, what about coming over to work with us?

Tammy Bryant Butow: We thought, well, instead of trying to poach SREs from other companies, what if we could create more SREs? So I sat down with one of our directors of engineering, his name is Andrew, and we decided to think through how could we create these SREs? First off, we thought, well, what about some type of apprenticeship program? And in my spare time, I've been running a company called, Girl Geek Academy, where we train up girls and women to learn technical skills. And we've had a lot of success there teaching folks how to code, how to use tools, like Raspberry Pi, different types of things like that, 3D printing, all sorts of stuff. Basically, we could teach them anything in a day, and they would be able to just do it.

Tammy Bryant Butow: We were like you really can teach folks things, if you have a great curriculum and you make sure that you focus on what you want them to learn. And you're very, very clear about that. What the success metrics are. What the goals are for this curriculum and this training program. Using those learnings, we then also thought let's try and take folks who have no experience, at all, and then let's also see are there folks who would like to become SREs? Because a few people had said, "How do I become an SRE, if I'm an engineer already, or if I'm, maybe, a technical program manager?" And so, we made the program open to both types of folks. And that was also a really good experiment to be able to see who thrives? Can this work for both types of different people? And that's originally where the whole idea started.

Tammy Bryant Butow: We got approval from our VP of infrastructure engineering, and his name's Akhil, really awesome. It was so cool that he was 100% onboard and supportive. And we got approval and everything from the people team. They were super supportive, as well. Obviously, recruiting was very happy to help out with this. And it was just such a cool thing to have support from everyone across the company. We also thought it might help us improve diversity of talent, as well. Actually, we hired two women through the program. Three women, actually, two women of color, as well, so pretty amazing and it was small. The first cohort was actually three women and one guy.

How to train an SRE [05:51]

Thomas Betts: And then, what were you seeing as these are the skills of the site reliability engineer. You said you can teach anybody anything, as long as you know what your goals are and you have a good curriculum. What do you see as the actual skills? Because I like the idea that you don't have to have a degree in computer science to be good at SRE, but what does help? Is it a mindset? Is it just skills you need to learn?

Tammy Bryant Butow: Yes, it's definitely a bunch of different things. It's always interesting too. My background is very traditional. I studied computer science as a bachelor's degree. I did master's degree, as well, later on, after working for several years as an engineer. I didn't come from a non-traditional background. I just did the traditional path straight out of school. I'd been on the internet since '95. I've been building computers for as long as I can remember, making things on the internet. But I really was like there's not so many of us. When I look around, I don't meet many women like me. That's just not normal. I've had three women in my entire degree. My master's degree was even less women. Most of my classes had no women.

I knew that really wasn't going to be the best approach, if we wanted to improve diversity, as well. And so, thinking through what do you want folks to be able to do? What are the key critical skills you need to do to be an SRE? A great thing to think about is what do you interview for? You can reverse engineer it like that. At Dropbox, we already had our SRE interview, which was focused on coding, troubleshooting, architecture, communication skills, culture. Those are the five areas that we focused on. So, if you think about it like this, we're going to run an apprenticeship program for six months. And at the end of the six months, we would want these SRE apprentices to be able to pass a regular SRE interview. Is that possible? That's the experiment.

Principal engineers as mentors [07:38]

Tammy Bryant Butow: And the apprentices that we ended up hiring, they're on proper great salary, similar to what their co-workers on. They're on the same salaries and everything, but they knew that it was an experiment. You don't have a guaranteed job, it's a six month apprenticeship. And at the end, if you pass the interview, you'll have a job. And so, it was all about that. How can we help them learn the skills that they need to be able to actually be able to pass that interview, and then be able to perform their job. And since that time, it's actually been five years since we've launched the apprenticeship program. I didn't want to speak about it too early, because who knows if it was going to be a success. But since then, all of these folks are still working as engineers doing really great in their careers, have gotten promotions. We've then went on to hire more apprentices after that, so pretty amazing.

Thomas Betts: I was wondering, did some of the apprentices become teachers for subsequent apprentices?

Tammy Bryant Butow: Yes. Initially, we didn't want them to feel overloaded with that, because they have a lot to learn still. And honestly, I think it's better to have folks who are principal and staff engineers be the mentors for SRE specifically, because there is just so much to learn. And that's what we did with the initial first batch. Part of the apprenticeship program, one of the most important things is to have this match between a Jedi and a Padawan. You want someone super experienced to match with the Padawan to teach them everything they need to know, and to be this wise person that's going to help them. The idea there too is that, you had to do it in six months.

An SRE apprentice that's just graduated could teach someone else to be an SRE apprentice, but it's going to take them way longer. That's not their core knowledge yet, so they helped out a little bit but it wasn't their primary job. Their main goal was to just focus on being the best SRE that they could be.

Thomas Betts: I think that's also one of those things that defines what principal and senior roles should be. You're not just doing the work, you have this mentoring responsibility. And I think a lot of companies are trying to find informal ways to do mentoring, and it's not often you encounter something that's this formalized, where a dedicated part of your job is training this other person.

Tammy Bryant Butow: Yes, totally. And I actually way prefer that. One, it's way more rewarding for the principal staff engineer, the senior engineer. They're able to be like our goal is to help you get round up, to help you learn everything you need to be to be an effective member on my team. The other thing too is this person is on your team, so they're doing work that you can assign to them. You're reviewing their code. You're able to help them grow and learn. And that's really cool, because they're an extra person to help you out to hit your milestones. And all of the principal engineers are very, very happy with that. They're like this is great. I can assign them work. They'll come to me and ask me great questions. They are learning a lot from all of the questions they were being asked, as well. And everybody passed the interview.

To cut to the end, everyone passed the interview. They did a really great job, and they all were so thankful to their mentors, their senior engineers that helped them on the journey.

Thomas Betts: I want to pull that thread a little bit. What did the principal engineers learn from the experience? What did they then take back to their job and say, well, I've done the apprenticeship program. Maybe they signed up for another cohort, maybe they went back. But, obviously, I know I learn from trying to explain things to other people. That the act of having to be coherent enough to explain something makes me understand something that much more. Do you find that's same growth happened on both sides, and that the principals were better at their jobs in ways?

Tammy Bryant Butow: Yes. So many things came out of that for these senior engineers. I'd say one of the main things is they developed rock solid leadership skills. That was huge. They already, obviously, have leadership skills, because they made it to that senior level of engineer. For folks listening, who are already senior, you know what that's like. You need to be able to get into a room with your CTO, with other executives, people from, maybe, other departments, as well, and present a plan. Maybe it's even a two five year transformational journey plan of how you're going to completely transform everything and what that's going to look like. Get buy-in, get head count, all of these things take a lot of leadership skills, but their leadership skills dramatically improved through doing this one-on-one mentoring session for six months, which is pretty amazing.

It was, I'd say, like a mini-leadership training, but very dedicated and very focused. And also, all of them got promoted after, as well, which is amazing. Because they just excelled at their work after that, and they did so well that they all got promotions. Which we didn't know that was going to happen, but that did happen.

Thomas Betts: Yes, the unintended consequences, they're really good to hear.

Tammy Bryant Butow: Yes.

The importance of visibility [12:14]

Thomas Betts: I wonder, did you, for secondary cohorts, did anyone from within the company apply and say, "I want to shift over and be an SRE." Maybe they had been trying to do a little bit of the work, and then said, "I like experimenting and trying this chaos stuff or looking into it." And they said, "I want to go through it, but I need some help."

Tammy Bryant Butow: Yes. That even happened, actually, for the first cohort, too. Originally, we were going to just hire external folks. The good thing about having a structured program like this, something more formal, is that you can promote it internally. It's not like secret mentoring that's happening that no one knows about, and that's really important. The reason that it's important is think about it like this. We go up to engineering all hands. Share that we're going to run this apprenticeship program. There's project managers in the room. There's engineering leaders in the room. There's senior engineers. There's junior engineers. Everyone knows about it now, so they're able to tell their friends. We're running this experiment. If you'd like to get involved, let us know if you want to be a mentor, if you want to participate.

So we did have one program manager put her hand up, and she was a TPM. He had been working at the company for a few years already and she'd done great work, but she wanted to learn to be an SRE. She was like, "Really, I love seeing what the SREs do. I would like to have that as a job. Can I apply for the program?" And we're like, "Yes, totally. You can interview with everyone else." If you pass the first interview, there was an apprentice interview, which was not as hard as the SRE regular interview, and she passed it so then she was accepted into the program. The other thing too, just to explain, how did folks get promotions from doing this work, these senior engineers? Often people talk about how hard it is to get promoted from the work that you do, but I think a lot of the time is because that work is invisible and that's not good. You need to be able to actually share with people what you're doing.

And if you've already got buy-in to run a program. You participate in a program. You've been super open the entire time about the results. People have seen you do that work for six months. That's way better of a story than, "I've been mentoring 10 different people over the last year." And then, "Who are these people? How did you actually help them? What was the result? What did they achieve? Did anything come from it?" There's just no good story there. This program, making it public, inviting folks to participate, sharing the stories during the program, I think that was a way better way to do it.

Apprenticeships vs. internships [14:36]

Thomas Betts: Yes. I think a lot of big companies do have a summer internship program and that's the only time. But even then it's sometimes a little squishy. We might have a project that someone can pick up, and we let people run on their own. I always like the end of the summer. Here, we're going to see what these people did. And after 10 weeks, you're like, "Really, in 10 weeks you did all of that? And you had no experience? This is your first time sitting down, hands to keyboard, at a real job, and you're able to produce that." I think back to when I was an intern. I did some stuff, but you're always impressed with what people are able to do. It's just that learning growth opportunity, and then it's displayed publicly for everyone to recognize. This is going on. This is what we recognize in the company.

Tammy Bryant Butow: Yes, totally. The best things I've seen there, as well as a science fair of intern projects, where every engineer across the company is invited to actually go and see what the interns created. And they have a little table with their computer and they demonstrate it, so definitely recommend doing those things to for regular internship programs. I think the reason that a regular internship program doesn't work as good for SREs is because we have had a few people come through the intern program as SREs, but six months is a really good amount of time to help someone train up and learn about your systems enough. Because it is such a critical role in terms of you're going to want to put these folks on call for production. Can you trust them on call? I don't think I've ever put an intern on call, ever. But the idea is that at the end of this apprenticeship, your SREs would be able to be on call. Because they're trained up and they've passed the interview.

And so, that's a big responsibility. I was put on call when I very first started, pretty much on my first week of work graduating straight out of university. But I don't know if that was a great idea, looking back.

Thomas Betts: Yes. I think on call is one of those things that a lot of companies struggle with, with new employees. Well, you get your feet wet. You jump in the deep end. Whatever metaphor you want to have. But you also, sometimes, are setting people up to fail because you have to have enough of a support net for them to not drown when they jump in the deep end. And the idea of saying to someone, who's only here for 10 weeks for a summer internship, is a lot different than you're here for six months this is for the long haul, and you're hoping to stick around afterwards.

Tammy Bryant Butow: And that's the thing too. The engineers are going to put in a lot of effort to train these folks up, to teach them about the systems, to help them shadow on call situations, because they know that these folks will want to stick around. Sometimes with an intern, they might come and do their first internship with you, then do another internship somewhere else. They might never return, so it's very different. Also, I come from Australia, where we don't really do internships that much. It's not very common, so not every country does internships like in America. If you're listening in from a different country, and you're like, "What are these 10 week internships? Never heard of it." I hadn't either until I moved to America, so all good there.

Advice for training any co-worker [17:30]

Thomas Betts: And it's also very regional. You have to have enough of a university around so that companies can hire, and they know that there's enough people coming in. There's a whole support system that has to be in place for it to exist. I do want to go back. You said something about teaching people on call, and it was shadowing. I think that's a great skill for SREs, but I think there's also something to be said about how do you just teach someone? Because a lot of our listeners are not site reliability engineers. They're developers, programmers, principal engineers, whatever, but they do have some of the mentoring. How do you sit down and teach somebody what you're doing? In most cases, they have coding skills, but how do you teach them here's what's important in our domain? Here's how you do it. Do you just come up with scenarios that you made up for the purpose of training, or is it better to sit down with real world examples and walk them through? Let's solve this problem together.

Tammy Bryant Butow: I'll break it down in terms of coding projects, and projects where you're building, tooling, automation, and then also on call. So there's two different approaches for those different things. If we're talking about coding projects, then what I really recommend is allowing the apprentices to learn by doing. The important thing there is they should be allocated task work, and it should be broken into, at the start, small bite sized tasks that they can take on. And if you read books, like Accelerate, great book. I was just reading it again recently and wrote up a book review on my medium. If you read Accelerate it says you should make sure if you want to be a high performing technology team that you can do work within less than a week, and you can ship an MVP.

That book is very much against the whole idea of doing code for months, and months, and months, and then shipping out a huge big patch of work. And that's not possible in all industries, for example, games. But if you're working in a majority of other types of industries, you can do that. You can break your work down into week long tasks, or less even. What I recommend for apprentices is actually starting off by giving them one day of work. Today, I want you to do this, and you have to do the estimation for them. You have to get to know them. Sometimes you might give them a little bit too much, a little bit too less, but you really need to think through that. How much can my apprentice get done in a day? And then once you feel pretty comfortable you know how much they can do in a day, maybe that's a week worth of one-day tasks. Then the next week, you extend it a little bit more. Give them some two-day tasks, some three-day tasks, and then see how they go with that.

Because you're gradually just giving them more space to be able to learn, to grow and encourage them too to not just come to you as their mentor, but to also go to other folks. You don't have to know all of the information. Encourage them to chat to the other apprentices in the program. That's why it's also really good to have a cohort, at the same time. And then ask them to meet other people and other teams. Invite them along to meetings so they can hear how you talk to other people. The other thing we would do for code review. At the start of the program, we didn't do regular code review, where you just submit your code via GitHub and someone reviews it remotely, and then you see the result. It's a little bit too invisible for an apprentice. They don't understand what's happening and they can't ask questions easily, so it's really not a great approach for an apprentice.

Great for a senior engineer because you can just keep moving, get feedback quickly, and go on with your day. But it's better to do it in real time with an apprentice. So what we would do is we would pull up their code on the big screen in the office. You can do this on Zoom. Pull up their code, and go through it line by line, and give them feedback, and ask questions, and have a discussion about it. Why did you choose to do this? Why did you choose to do that? Imagine it like if you were doing a coding interview and you're asking someone why they chose to do certain things with their code. That's what we'd do. Then we would give them some tips for how to improve it for performance, or reliability, or security, whatever it was. And then, at the end, they submit that code, so it's actually like a real life code review.

That actually worked really well. We didn't do so much pair programming, which I think pair programming is great actually. And I learned to code, definitely, in my early days doing a lot of pair programming. I remember I sat next to this one guy that was an amazing senior engineer, probably, for three months we were working on a project together, and we sat together every day. That as awesome, actually. I learned so much from him, but that's hard to, in this remote world, where people are very busy and going to a lot of meetings. I think these days doing the you write your code, and then let's review it together. That works well.

Thomas Betts: Yes, especially when I was younger, early in my career. You tend to thrash more. You sit there and are like, "I don't know where to go." Being able to get that quick feedback is like, "I'm just stuck on this. Help me walk through that a little bit," the pair programming helps. And besides, even just a rubber duck, you needed to have someone to talk to and just explain your problem. And so, having someone you know you can always go to, and having that... I like the I can go up to the principal that's my primary mentor, but also I can go sideways to the other apprentices and see, well, you might have something similar, let's talk through this from the same level.

Tammy Bryant Butow: Exactly, exactly. We encourage them to build bridges. That's super important. And that's a great skill for them as they continue in their career. That they can build their own bridges across the organization. They can build relationships. A lot of it also is about teaching them how to communicate with other engineers in different teams. What context do you need to share before you ask for help to solve a problem? That's something that, I think, is really key. But they learn that really fast. You just demonstrate, if you're asking someone to solve a problem, share this information out front. Then give a link to what you want. Then ask them or tell them any urgency related to that, if it's due soon, or something like that. That helps people be able to help you.

The value of being "in the room" [23:16]

Thomas Betts: One of the topics we highlighted in this year's InfoQ Software Architecture and Trends Report, or two of them were designing for resilience and designing for observability. I feel like that's right in the sweet spot for site reliability engineering. Software architects, your primary role as an architect is to take in and understand multiple viewpoints. And sometimes you can get a lot of insight from a fresh set of eyes. If you keep talking to the same people over and over again, you hear the same answers. You get someone brand new, like an apprentice coming in, you said you brought them to meetings. Do you think that it's useful to have an apprentice, in a safe situation, talk to the architect, and the architect would benefit from showing them their designs saying, "Where should we improve this? What do you think we need?"

Tammy Bryant Butow: We definitely did that, for sure, 100%. We definitely did that for architecture discussions, when we were designing new architecture. Because you want to stick around, so you want to have them in there. Because, eventually, they're going to be contributing to this platform, or software, that you're building out. So when we were designing a new system, maybe, say at the time, we were working on improving our backup system. Invite them into the meeting. Have them see all of the discussions that are happening. See how we love white boarding. I'm a huge fan of white boarding during work hours to be able to explain something. It's because I'm very visual, so it just helps me when someone will white board something and talk through it. And you can do that online these days with tools like Miro, but that helps them learn too how to communicate their ideas.

You don't just have to sell your idea by talking about it. You can draw a diagram live. That's even better often than coming in with a pre-prepared diagram. If you can draw it live and explain it to folks, it just helps you communicate what you're trying to talk about. And it gives them a chance to ask questions. It doesn't overload the people that are there, and they learn so many skills from just watching the staff engineers and principal engineers that they can then do that themselves when they are presenting their ideas to get feedback from their engineer that they were matched with. I saw so much great stuff from that. The other thing we invited them to was postmortems. That was really good too, because they could see what happens when something goes wrong. And the VP of infrastructure is in that meeting, and he would talk through things, ask great questions. The engineers on the teams would respond, so the apprentices were always there to be able to observe, and learn and everything.

That was awesome too. I ask them afterwards if they enjoyed that, if that was good use of their time. They're like, "Yes, that was so interesting. I learn so much about how all the systems work together." Because in postmortems, we would do a lot of white boarding about dependencies and there would be 20, 30 people in the room, so you just learn a ton in that one hour session.

Thomas Betts: And then, what's the flip side? If the apprentice sat down in the room, what advice can they give to the architect? The staff engineers? Do they bring that perspective of what's important to me is I need to be able to find out when an incident happens? What's going wrong? And so, does your design account for that SRE viewpoint? Because I think sometimes the SRE is an afterthought, and we're trying to get better at that. It's like we didn't think about making it observable, because no one was in the room. Can the apprentice, brand new, come in and say, "I needed this because this is what's important to my job."

Tammy Bryant Butow: Yes. I would say that would be great if apprentices did that. I think, generally, they often are a bit shy, because they just started. Usually they were more asking questions about how are we building this, or trying to clarify what the architecture looked like. What type of database? Maybe they might ask how are we going to monitor this? What kinds of alerts will be set up for this? More like questions like that, just gaining the basic information about the system. And then understanding how it relates to what we do as SREs, definitely. But I think over the six months they definitely grew, as they got more experience. And that's okay, it takes time to be able to understand things. First, you might go into a room and just be like, "What are they talking about? This sounds like they're from a different planet." That's really what it's like for apprentices.

I didn't realize that until we did the program, but just even things like, what is Nginx? How do I even say that word, when I see it written down on a piece of paper? Things like that. People are just like, "What is all this stuff?" There's just all these words that, when you've been an engineer for a long time, you know what everything means, and you understand where it fits in your architecture. But this is so much knowledge to grasp, when you first start out as an apprentice. Yes, that's what I would say. Give them the time to learn, draw them diagrams, help them understand where things fit into the bigger picture. And then they'll start to ask really great questions, and then that will help you improve over time.

Girl Geek Academy and closing [28:00]

Thomas Betts: Yes. There's always a learning curve with any industry. I feel I can say software has got more acronyms, but I think you go anywhere, everyone has acronyms, everyone has terms, some that you have to learn by doing, and I'd like that the apprenticeship was a little bit more of an intentional program to say we're going to take the time to teach you these things, and we're going to teach you how to say Nginx. I wanted to wrap up. You've mentioned it briefly, but I was curious more about the Girl Geek Academy and trying to teach women and girls technical skills by 2025. You said it's technical skills. It's not just teach girls coding. How are you doing that? Where is it? And how do people get involved?

Tammy Bryant Butow: We have a website, girlgeekacademy.com, and we're also on Twitter at Girl Geek Academy. Mostly, we're just focused in Australia, because I'm Australian, live in America now though. And the Australian government has been very supportive. They gave us over $1 million to be able to do this work, which we've been doing it for several years now. And mostly, we do it through running hackathons. That's actually been really cool. And we do them for different age groups, so we do have a Miss Makes Code, which is about helping young girls learn to code when they're around five to eight years old. And then, as you get older, we teach you, not just coding, but other skills, as well, so a lot of hardware hacking too, which I think is pretty cool. When you think about Raspberry Pi, why was that invented? They really wanted to be able to create a technology that helped get folks curious about how computers work, instead of just learning about software on top of it. Understanding like... And this makes a great computer scientist.

Tammy Bryant Butow: If you go and go to university, it's really great to understand how things actually work underneath, inside the computer, if you can build your own computer. And we also taught them 3D printing, really anything that they wanted to learn. We would do it off requests. Also, how to build games, because one of our founders actually makes video games. She's won a lot of awards for that her name is Lisy. She works at League of Geeks full-time, a gaming company, been there many years. And we also have a security engineer too, so we teach that too. So lots of different skills, but primarily just for Australia, right now, if you're lucky to be in Australia.

Thomas Betts: I know we have listeners all around the world, so hopefully someone will hear and maybe be enough to get involved, or have their daughters and other friends go and attend.

Tammy Bryant Butow: Yep, sounds great.

Thomas Betts: That's about all the time we have for today. I want to thank Tammy Bryant Butow for joining me on the InfoQ Podcast. We hope you'll join us again soon.

Tammy Bryant Butow: Awesome. Thank you so much for having me.

Thomas Betts: Thank you, Tammy.

Mentioned

About the Guest

Tammy Butow is the principal SRE at Gremlin, where she works on Chaos Engineering, the facilitation of controlled experiments to identify systemic weaknesses. Gremlin helps engineers build resilient systems using their control plane and API. Tammy previously led SRE teams at Dropbox responsible for databases and storage systems used by over 500 million customers. Prior to this Tammy worked at DigitalOcean and at one of Australia’s largest banks in security engineering, product engineering, and infrastructure engineering. Tammy is the co-founder of Girl Geek Academy, a movement to teach 1 millon girls technical skills by 2025.

Learn how to solve complex software engineering and leadership challenges. Attend in-person at QCon London, (April 4-6) or attend online at QCon Plus (May 10-20).

QCon brings together the world's most innovative senior software engineers across multiple domains to share their real-world implementation of emerging trends and practices. Find practical inspiration (not product pitches) from software leaders deep in the trenches creating software, scaling architectures and fine-tuning their technical leadership to help you make the right decisions. Save your spot now!

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT