The Changelog: Software Development, Open Source - Learning-focused engineering (Interview)

Episode Date: October 1, 2021

This week we're joined by Brittany Dionigi, Director of Platform Engineering at Articulate, and we're talking about how organizations can take a more intentional approach to supporting the growth of their engineers through learning-focused engineering. Brittany has been a software engineer for more than 10 years, and learned formal educational and classroom-based learning strategies as a Technical Lead & Senior Instructor at Turing School of Software & Design. We talk through a ton of great topics; getting mentorship right, common coaching opportunities, classroom-based learning strategies like backwards planning, and ways to identify and maximize the learning opportunities for teams and org.

What's up? Welcome back. This is The Change Law. We feature the hackers, leaders, and the innovators of the software world. Today, we're joined by Brittany D'Anigi, Director of Platform Engineering at Articulate, and we're talking about how organizations can take a more intentional approach supporting the growth of their engineers through learning-focused engineering. Brittany has been a software engineer for more than 10 years and learned formal education and classroom-based learning strategies as a technical lead and senior instructor at Turing School of Software and Design. We cover a ton of great topics today, getting mentorship right, common coaching opportunities, classroom-based learning strategies like backwards planning, and ways to identify and maximize learning opportunities for your teams and your org. Of course, thanks to our sponsors, Linode, Fastly, and LaunchDarkly. We love Linode.

They keep it fast and simple. Get $100 in credit at linode.com slash changelog. Our bandwidth is provided by Fastly. Learn more at fastly.com. And get your feature flags powered by LaunchDarkly. Get a demo at launchdarkly.com. This episode is brought to you by our friends at Influx Data and their at LaunchDarkly.com. Databases are the fastest growing database segment, providing real-time observability of your solutions. Get practical advice and insight from the engineers and developers behind InfluxDB, the leading time series database. Learn from real-world use cases and deep technology presentations from leading companies worldwide.

Also, for those who'd like to get hands-on with Flux, our listeners get $50 off the hands-on Flux training when you use the code CHANGELOCK21. Again, this event is happening October 26th and 27th. Learn more and register for free at influxdays.com. Again, influxdays.com. So Brittany, you're the director of platform engineering at Articulate, but you haven't always been. You want to tell us how you got here? Yeah, sure. So I started at Articulate about two years ago at this point. But prior to joining Articulate, I was an instructor at a coding boot camp during school in Denver. And I did that for about four years.

So I spent a lot of time there teaching brand new software engineers how to code, how to build applications, all the ins and outs of debugging and getting things up and running so that they could eventually get into software engineering themselves and make a change in their career paths. So that part of my career was super enlightening and has actually guided a lot of what my goals at Articulate are in my current role. So after I switched from teaching into management over at Articulate, trying to translate and transfer some of these educational strategies that I've learned into a company that we're a SaaS company, we sell e-learning software, and we have a typical

range of engineers that work for us. So trying to translate all these educational strategies that are really classroom-based and formal into our day-to-day work processes to help level up our engineers is something that I've been working really hard towards in my role. And in platform engineering, we are working with every single engineering team. So I'm working internally with all of our product developers, our QA developers, our infrastructure developers. And I see a lot of the strains that organizations have on creating really good learning opportunities for their engineers and being able to support engineers just of all levels and all different backgrounds and technical skill sets.

So share some of those insights. You're at Turing School, you're teaching people day in, day out, and you're learning very quickly about that process. What'd you find? That we're really bad at it. So I don't think anybody recognizes how hard teaching is until you fail at that miserably. And our industry puts senior engineers in a position where we say like, okay, mentorship is part of your job description. Now, this is one of your responsibilities, but we don't do anything to teach our senior engineers how to be good instructors, you know, how to be good mentors to other engineers. So when I first started teaching, I think anyone that first starts teaching, it's almost like a rite of passage where your first lesson will go terrible. And

everyone just knows it's going to go terrible if you've taught before. I had a lesson that I taught years ago on JavaScript, intro to JavaScript, like JavaScript 101 for, I think, Startup Institute in New York. And I thought it went pretty well. And at the end of the lesson, the lecture, I asked for a little bit of feedback. And I remember one of the women in that class was like, I think this will be really helpful. Like once we're in it a little bit more, once we have a little bit more, you know, our footing a little bit better. And I was like, okay, that's good feedback. Like, great. Like, I think it went pretty well. And then years later, I found my slide deck and I looked back at it. And by the fourth slide in i was talking about prototypal inheritance so that and that is not an intro to javascript topic like that was the indicator to me i laughed when i saw it

like that did not go as well as i thought it did so our blissful ignorance at how bad we are at teaching is something that's super obvious to me that I don't know if the rest of the industry is as aware of. Well, you forget the things you learned and how challenging they were to learn. And even on ramping anybody from zero coding ever to coding something, even a whole world is such a margin. And there's so many parts like the terminal and just different things we take for granted because we touch them and live them and eat them and breathe them every single day. It's just like, well, that's just common. You know, you're supposed to not breathe underwater.

Did you know that? You know what I mean? Like, if you go for swimming for the first time as a kid, you're like, I should breathe in the water because I breathe. Right. I'm a human. Yeah, exactly. And even if you're at an organization where you're not mentoring people who are brand new to software engineering, like maybe you're bringing in engineers that have a couple years of experience, mid-level engineers, maybe some more junior engineers, that develop all of these instincts and all of this intuition. And then it becomes very difficult to know how to teach here for this type of information unless someone else is pointing that out to you and forcing you to answer those types of questions?

How much does humanity come into play? Like shame or the fact that, you know, like I just don't know because there's a large majority that's self-taught to some degree. There's a large majority that have gone to school and it's a big handbag of all those variances. At what level am I? How much skill do I actually have in comparison to my other seniors or juniors? Or, you know, how much does humanity come into play whenever it's pushing back on that ability to instruct or that ability to teach and lead? Are you trying to bring up a little bit of like the imposter syndrome and empathy aspect of becoming a good instructor or kind of I mean like if uh let's say I think I'm really good at my job yeah right I I have this belief I'm really good and you come to me you say well Adam you could improve in these

ways to help lead or instruct those around you in these ways I might take shame because I'm you've now attacked my abilities, my, you know, what I think are very personally, my skillset that I've cultivated. And I mean, so you kind of get into this gray area of like, well, I'm not just trying to help you improve. Well, now it's like, I take that personally that I don't meet the level of whatever it might be, you know, and somehow I'm, I'm not enough. Sure. What I would ask then is, have you cultivated that skill set? And has your manager supported you in cultivating that skill set? Have they provided you resources to actually cultivate that mentorship skill set that they're

saying you need to have? There is a blog post recently by Camille Fournier who listed out a bunch of essential skills that senior engineers need and non-exhaustive, obviously, but one of them was like knowing how to mentor other engineers, but then also being able to take feedback that's like, we need to improve on this skill set and go be able to act on it. And I think the problem there is that I don't think many organizations or companies give their senior engineers the support that they need in order to cultivate that skill set. So it isn't fair to a lot of seniors, I think, to expect them to be really good at this thing that we're not teaching people how to do. Yeah. I draw an analogy over at board

games because there's lots of complicated, fascinating, deep board games now. And everybody has in their friend group, I think, that one person who's really good at explaining the game to somebody who's new. And the rest of us can play the game and understand it intimately and have strategies, very advanced knowledge. And the person who's coming to the new board game, it's not like they're unfamiliar with the way board games work, right?

Like they have experience, but they need to understand this particular game. And some people are just really good naturally at teaching and understanding how I'm going to explain this board game so that you grok it quickly and start strategizing with us and start playing and having fun. And then the rest of us are actually like, even if we're really good at the game, it's grok it quickly and start strategizing with us and start playing and having fun. And then the rest of us are actually like, even if we're really good at the game, it's our turn to explain it. And it's like, this is not, I can't. I'll do it. Yeah.

This is hard. Yeah. Because teaching is a completely different skill set than doing. Right. And so, like you said, Brittany, like, have you cultivated it? Have you been supported? How many times have you explained this board game to other people? Because it gets easier with time. So there shouldn't be shame, I don't think, for any of us who struggle to teach because teaching is really hard. And some people, there's like a scale of how you have naturally inclined to do it.

And just because we're good developers or good engineers, it doesn't mean we're going to be able to impart that without instruction, without learning and experience. Yeah, I would. Normally, I hesitate to say that like certain people are naturally good at something and others aren't. I feel like sometimes that perceptive perception is like a little bit unclear. But when in this particular context, like someone who's naturally good at instruction or explaining a board game or something, I would say that it lose sight of very easily as senior engineers or as we get further in our experience and get comfortable in our expert roles. And the more time we spend there, the less we stay in touch with what it feels like to be learning something brand new, what it feels like to not have a comprehensive view of the tools and the systems

that we're relying on. And you lose a little bit of the tools and the systems that we're relying on. And you lose a little bit of that empathy and you lose sight of where that starting point is for certain people. So is it safe to say that it's smart to keep in touch with your beginner mindset or your beginner place? And that beginner slides, right? Because beginner might be actually beginner at a high level thing, not a low level, like an entry point. Right. So beginner is not necessarily like brand new. It could be brand new with something very advanced.

Absolutely. How do you keep in touch with the beginner mindset? So I think always be pushing yourself to learning something brand new in tech or in related directly to your job, because you already have some significant level of expertise there that you recognize, like on paper, it's your resume, it's maybe your job title, it's your years of tenure at your company, and how much historical knowledge you've gained, like, go try to learn how to knit if you've never knit a sweater before. Like that is something that's completely outside your comfort zone maybe. And that's what's going to really give you a lot of that beginner perspective empathy that you need in order to recognize like, wow, this is what it

feels like to be a beginner here in this space. And you're not going to feel like a total beginner when you're learning something new in an industry that you've been working in for years, because you still have a leg up on how to go about learning that new thing, and where to go do your research, and what bits to pay attention to and what bits to not pay attention to. So you already have a leg up where you're not going to get that true beginner mindset if it's in something that you've been working with for a while. I think another part of keeping in tune with your beginner mindset too is, like I mentioned before, always asking yourself,

how and why did I know how to do this? Which I don't, I mean, it was never a part of my development process when I was in an IC role to like be asking myself those questions when I was just coding along all day. But if someone else asked me that, it was like, oh, I have no idea. Like, let me think about that. Let me get back to you on that. And that's a lot of the stuff that you need to be consistently asking yourself because a lot of the things that we think are instinctual are not like there can be teachable rules and patterns to those i think that comes

into play a lot with debugging in engineering like think about jared or adam like how do you go about googling an error message? What do you do? This could be a precursor to a future show we'll do. This is actually a deep subject. How do you Google, essentially? We aspire to do a deep dive on all the multifacets you can do to Google. A problem set. I'll tell you, having been experienced in specific errors, the first thing you do is copy and paste the exact text into Google

to see if somebody has actually put the text into a blog post and you find an exact match. That's a great way to start. From there you've got other things. But for sure, if you can get the exact error, now you may have to scrub the unique parts out and just normalize it. And get rid of the parts that are unique to you and keep the parts that are general,

otherwise you're not going to get a hit. How do you know what parts are unique to you? Give me an example of a part that would be unique to you in an error message. A timestamp or if it's a web request, specific parameters that are put into the thing or stuff like that. The first line of your terminal,

not usually somebody else's. I mean, your prompt. My prompt that says Jared in it, yeah. Your computer, yeah, exactly. Jared at MacBook, whatever, you know? Right. Yeah. And then what do you do?

If you scrub all that information out, you have an error message, you copy and paste it, and you don't really get a ton of results or you get some results that might be related but kind of vague. Right. Then I'll often generalize the search query even more. And instead of putting an entire message in, I'll find what kind of error it is and I'll put that in along with my circumstance, like Elixir 1.12 or something.

And then this particular error. So you're just kind of tweaking it. You're just trying to give Google exactly what it needs to find that. Yeah. And that's something that our engineers, some of our new engineers when I was still in my instructional role, they did exactly that first step. Just copy and paste the error message and throw it into Google but didn't know to take out the file names or parameters or function names that were specific to them or didn't know to take out the file names or parameters or function names that were specific to them or didn't know to add keywords about what library they were using or what framework

they were using. So teaching those types of things is like super insightful, but most people's first step in teaching that and where a lot of people stop short, which you didn't, is just copy and paste the error message into Google, like go Google it. And that's about it. But there's a lot more teachable things in that. Right. Yeah, it's kind of the individual steps. I'm thinking about TDD a lot because, you know, in test-driven development, you want that first test to fail. And as a person who practices it over time, it's so silly making it fail first, right? It's red, green, refactor. And a lot of times we know what the green looks like because we've just done it a hundred times.

And it's like, am I really going to make this test fail again for the thousandth time? Am I going to put everything right into Google or am I going to generalize it? Because I know it's not going to match perfectly. So the intuitive part is actually just iterations of experience where I've realized I can skip the red part. Sorry, TDD purists, but a lot of times I'll just skip the red and I'll go say to the green and everything's fine. You know, the world doesn't end. The program continues to run because I just have. And other times I'll do the red because I think I need it.

And those are things I think are intuitive, but they're actually just iteration experience. But when I go to teach that, it's like this is the way I need it. And those are things I think are intuitive, but they're actually just iteration and experience. But when I go to teach that, it's like, this is the way I do it. It's hard to actually go back to those individual steps like you're mentioning and teach it that way. Yeah. And it might seem silly to teach it that way when it's something that, you know, like, you know, 99% of the time it's going to be fine if I just skip to the green part and head that way. But I think one thing that you're touching on with this is like the efficiency of being able to teach that type of stuff and get someone from the point of always wanting to rely on that red to feeling comfortable and confident with just relying on starting with that green step. So yes, teach like the basics and the foundations of like kind of where you started,

but as long as that's exposed to them and they understand the why and the how, the earlier they get that type of instruction, the faster they're gonna be able to skip through however many layers of iteration you had to do to get to that point. Like you might've had to iterate and get a hundred times of experience

going through that process. And maybe they only need to do it 20 times before they get to that same level because they have that insight. And you've explained that intuition and instinct to them that they needed. Seems like a lot of responsibility on a senior engineer. Like not only do you have to be able to do all the things that your job entails, like what would be listed on your job, but then also you have to become a really good teacher and mentor and help sponsor people. And these are all things that we agree like we should be doing. But holy cow, isn't this like a lot of responsibility on seniors to say it's not good enough to achieve it? What's written on your job priorities, but also you got to learn how to do this better.

Absolutely. I think this is why it does seem to fall to the wayside at a lot of organizations where mentorship kind of takes a backseat to the other high priority, like either feature work or bug fixes or on-call rotations, everything else that senior engineers have on their plate. Mentorship is pretty much always listed as a responsibility, but then very much deprioritized. And I understand why, because those bandwidth concerns are universal. Everyone's got bandwidth concerns. It's really hard to do that. But the more efficient we get at our instruction and our mentorship, the less of a burden it is on senior engineers. And the more senior engineers you develop, you create, you make that talent with the efforts that you put into your instruction and your intentional mentorship. Is the struggle organizational support of this mentality,

this mentality of like instructing and cultivating and teaching, not just product feature, go, go, go. Because like you have to continuously learn. The software by nature has extreme entropy. Like it's changing every single day. Like this very moment moment a brand new a thousand repos were just created in this in this moment you know what i mean like there's something new just happened just now that we're not going to catch up to until yeah you know

months weeks years from now potentially it just moves so fast so is it how do organizations take this and run with it is it a commonality for organizations to embrace this idea for internal education, internal mentorship and sponsorship and supporting it? Because this, to me, takes the margin in an organization to enable that outside of feature set, outside of product. Yeah. So I think organizations can have a lot of different types of goals in this space. There's organizations that might be really ambitious about stuff like this, where they want education first. That's one of their core values. They are trying to prioritize always leveling up their engineers.

Maybe they have goals around being an organization that's known for creating really amazing engineering talent, more so than just attracting it, simply attracting it, right? And really supporting a lot of people's professional development goals and educational growth in this space. I think that's like the most ambitious end of the spectrum for organizations. And I don't think many organizations are there. Articulate is an education-based company. So we try to kind of live and breathe it in and out. And we're still not even there. That's something that we're going to be still

working towards for sure for years to come, I'm sure. But those really ambitious goals would kind of put organizations in line with what you might think of with teaching hospitals, where those hospitals are known for still doing surgeries, procedures, providing medical care, but at the same time, they have education ingrained into their everyday processes, everyday policies. That is just how their business model is built from the ground up. There are other organizations that might have way simpler goals, smaller goals that are simply just maybe we want to ramp up our engineers faster. Maybe we want to be able to hire engineers that maybe don't have every single checkbox of technical skills that we're looking for, but we know we can trust that we're going

to level them up just fine on the job. And maybe they just want to make it easier for engineers to get the answers to their questions and promote good cross-team collaboration. But even those really tiny goals can seem insurmountable for organizations because of how inefficient we are with our instruction and our mentorship right now, because we don't provide any sort of formal training on those types of things. I think a lot of organizations right now lean on providing stipends like professional development budgets, education budgets, maybe 20% time to go learn something new or hack on a side project.

I think those are great. Organizations should continue to support these types of growth efforts in those ways. But that's like the easiest thing to do is here's some money, here's some time, like use it as you please. But formal training in this space is something that would make a lot of those tiny goals a lot more feasible to achieve, a lot more achievable for folks. This episode is brought to you by Teleport. Teleport lets engineers operate as if all cloud computing resources they have access to are in the same room with them. SSO allows discovery and instant access to all layers of your tech stack, behind NAT, across clouds, data centers, or on the edge. I have Ev Contavoy here with me, co-founder and CEO of Teleport.

Ev, help me understand industry best practices and how Teleport Access plan gives engineers unified access in the most secure way possible. So the industry best practice for remote access means that the access needs to be identity based, which means that you're logging in as yourself. You're not sharing credentials from anybody. And the best way to implement this is certificates. It also means that you need to have unified audit for all the different actions. With all these difficulties that you would experience configuring everything you have, every server, every cluster, with certificate-based authentication and authorization, that's the state of the world today. You have to do it. But if you are using Teleport,

that creates a single endpoint. It's a multi-protocol proxy that natively speaks all of these different protocols that you're using. It makes you to go through SSO, single sign-on, and then it transparently allows you to receive certificates for all of your cloud resources. And the beauty of certificates is that they have your identity encoded and they also expire. So when the day is over, you go home, your access is automatically revoked. And that's what Teleport allows you to do. So it allows engineers to enjoy the superpowers of accessing all of cloud computing resources as if they were in the same room with them. That's why it's called Teleport. And at the same time, when the day is over, the access is automatically

revoked. That's the beauty of Teleport. All right. You can try Teleport today in the cloud, self-hosted or open source. Head to GoTeleport.com to learn more and get started. Again, GoTeleport.com. so we're at a place right now then we're having to teach people how to teach essentially if you say that's the place that lacks is how do you sure i want to teach sure i believe in education i don't want to just give you a thousand dollar stipend or whatever the number is to do courses or whatever you want I want to enable that to do free reign go learn something new so maybe that's in addition to but how do I teach you how to how do I know how to teach if that's the trouble like that seems to be the

the core issue how do we do that yeah we don't have a lot of experts in this space right now, which is the main blocker. My number one recommendation for organizations would be go seek out engineers who have taught before, have taught at coding boot camps or do open source education efforts and training courses and embed them into your organization, embed them into your engineering teams to start learning how they teach and what works well and what doesn't in courses that they've done and lessons or materials that they've provided online. classroom-based strategies that you might learn if you had gone to college to be an educator, to be a public school teacher or any other sort of professor, right, that are pretty unknown to people in the engineering field because we've never had to learn those types of things. So I think the first step for organizations is A, just being able to identify and leverage like any potential learning opportunity that you can create for folks. And those happen at the organization level, they happen at the team level, and they can happen in these more one on one intimate levels as well. Organizationally,

I think at articulate, like we've done a couple of things. We recently partnered with Jelly.io and they do incident analysis work. I'm not sure if either of you have worked with them or heard of them in the past. Super talented people over there. And they helped us facilitate a lot of incident review calls, which are open to all of engineering for anyone to attend. And those types of opportunities are really great for creating a lot of consistency and predictability in a learning environment where you're going to review an incident and not only what happened, but and how did we fix it? But how did the people who were involved know what to do? Let's suss out their instincts and how they got this to resolution.

What can we learn from this? What can we learn that was interesting about the systems that were involved and the tools that were involved? And those types of opportunities don't require a ton of in-depth preparation. Yeah. Yeah. Preparation from certain folks, but they allow for a really wide audience and are very focused on like exposure, which is sometimes half the battle. Like exposure is 50% of the battle in terms of like knowing where to get your answers to your questions, knowing that something exists, knowing where to go find something, even if you don't actually know the answer to your question. Those types of learning opportunities, minimal effort, like super wide audience, and really focused on creating a lot of links, mental links for people across the organization.

I think other organizations probably do lots of things like lunch and learns. We also do dev discussions, which are just hour-long technical topics that someone wants to present. Things like that are very consistent learning opportunities that you can be creating at the org level. And then at the team level, this is where a lot of these classroom-based and educational strategies come into play. I think things that we've done on our team that some have worked, some I think haven't worked, are things like backwards planning. That happens a lot in classroom-based education where you start with that end goal or big picture of what are we trying to accomplish here? And then slowly spec out details in more specific detail from there.

And what we'll do to emphasize that on our team is actually create like some of our tickets or our cards with that type of information specced out up top before we get into the nitty gritty of what actually needs to be done. So anything that lends itself to a good learning opportunity, we want to make sure that we're working from the end goal into where the nuts and bolts are that this person is going to have to go dig into to get to that final space of resolution. Other areas that we've done on our team, scaffolding is another really common classroom-based strategy where you're providing a lot of meat and bones and rails and bumpers for someone.

And then having them fill in the gaps by really isolating their learning opportunity there. In engineering, this might look like creating a pull request, a draft pull request that has a ton of the prep work already done and fleshed out and telling another engineer, okay, you take this on from here. Don't worry about all the stuff that I've already put in place, but fill in these tiny gaps. So that you can really focus just on that very narrow aspect of that learning opportunity instead of having to get overwhelmed by every other thing that needs to fall into place. If that's not what you want that person to focus on, do it for them and then hand it off when you have that focus really clearly defined for them. There's a few terms that come to mind. Yak shaving, reverse engineering. These all kind of play into some of that work backwards aspect. There's even a really well-known book out there now called Working Backwards about a lot of Amazon's practices and how they accomplish Prime and AWS and other things. And I read the Prime chapter and it's phenomenal.

If you want to read that chapter alone, how they came to Prime, they essentially did similar pull request driven development or teaching. In this case, it was press release. Like what did we release into the world? What product was it? And how do we get there essentially? That's an interesting way to get there because it's like that's common to say reverse engineer how this came to be. Reverse engineer how this would come into play and fill in the gaps

because you need those constraints and the possibility, but you kind of have to rewind to see what you got to do to get there so they wrote the press release first is that what i'm hearing i'm paraphrasing some of it i'm not giving you the it's like a sure very compressed tldr it's press release like what do we want to actually have in the world there's a lot more in it but yeah they have a practice of what is the press release for the announcement of prime for example and okay so that's the press release for the announcement of Prime, for example. And okay, so that's the press release. That lets us know what we want to deliver.

How do we do that? Because they had a very specific customer obsession. It's kind of like readme-driven development where you write the readme first. Right, exactly. Write the readme first, write the PR first, in this case that Brittany mentioned. So it's an interesting thing to say, what do we want in the world? Then how do you get there? And to pass off an opportunity like that to a new engineer or maybe a new hire

that you want to create that learning opportunity out of, I think you can provide them with that end goal. And that's what they're going to really be working towards. But as they get into the nuts and bolts, it's so important to be having consistent checkpoints with them because in light of any type of new information they come across along the way, they might not know if something is relevant or irrelevant.

They might not know they shouldn't bother going down this rabbit hole that they're about to go down or they might work really hard to get to that end goal. And when you see the work that gets delivered at the end, realize, oh, this was way harder than any of us thought it was supposed to be. We're so sorry. We didn't intend for you to have to do all this. We thought it would have been a two line code change. And then all of a sudden you realize, oh, actually it was 20, 20,000 line code change for this person. But they didn't know that. Yep. At this point, this is the delineation of like, this would not be worth it

anymore. This end goal should change now in light of these new hurdles that, that you've come across. So you have to bake these, these checkpoints in essentially with the instructor is going to do that or the lead is going to do that with the mentee in this case, potentially, if that's the terminology, they're going to have certain checkpoints to basically do that. Yeah. And I, that can look different for everybody. It could be async checkpoints, just, Hey, how's it going? Or it could be something way more formal where you're, you're doing pairing sessions and looking through the, the work as, as it goes along, but keeping in mind your beginner perspective, like it can be really hard to ask for questions or to know whether or not something is still worth it or if this is

still the end goal that I should be striving for. Or am I allowed to switch gears? Should I switch gears and tackle something different instead? So I think that's happened to all of us too. We're like, maybe it's our Friday afternoon and we pick up a ticket that looks pretty easy and simple. And then it turns into a beast and we're like, man, like didn't want to spend my Friday afternoon doing this. So now it's going to be a week and maybe we'll just drop it and put it at the bottom of the backlog again and pretend we didn't pick it up in the first place. Or dread the weekend and come back to it on Monday. Yeah, exactly. Or get the weekend and come back to it on Monday.

Yeah, exactly. Or get stuck on it and you can't even sleep because you're solving the problem in your brain over the weekend. You're like, I'm trying to disconnect. Yeah. That would be me. I'd be like working all weekend because I couldn't let it go. I love this incident analysis idea as a teaching mechanism and just institutionalizing knowledge because so many times like how you go about solving that particular problem is the domain of a senior's expertise it does only live in their brain i have a good friend who works at a fortune 500 that does credit card transactions

they're still on mainframes and these things are incredibly esoteric and there's a few people that work at that company that's like if fred dies we are in serious trouble fred's not the actual name the names have been changed to protect the innocent but you know like that his knowledge is not institutionalized like that is bus factor in a huge organization you have like a bus factor of three with thousands of employees and here you have with these incidents, you know, this analysis and this teaching through the incident, institutionalizing that knowledge, making it mineable, making it searchable, making it go backable and be like, even for Fred, how did I do this the last time? Because I could save myself two hours trying to remember how I did it the last

time if I just read this. That's really cool. That's what a lot of our review calls have started to suss out is what are these instincts that people are unaware that they have that we want to be able to teach to others. There was a talk by Katrina Owens on, I think it was called cultivating instinct. And she talks all about how novices will have an extreme amount of information that they need to process. And it's very hard to know what to pay attention to and what not to pay attention to. And experts simply know, they recognize the patterns, they recognize what they need to pay attention to and what's relevant. And when we get into that expert phase, we transition from like, oh, this was my step by step process to, oh, well, how did you not see this?

How did you not know this? Because it seemed so obvious to me. We don't recognize why things are obvious. And we're really not very good at training or instructing those more autopilot parts of our brain and our thinking. So you really have to be asking people consistently how and why did you know how to do these things? And where did you find this information to lean on? And who did you know to reach out to?

Why did you know to reach out to that person? Have you all ever seen that experiment? There's a video years ago about like a gorilla that was like walking through a basketball court where people were passing a basketball back and forth to each other. Okay. So it was all about selective attention. And there's, you both will see it now that I've told you about it. So it won't work on you if you if you go look it up okay but you're on a basketball court and there's a bunch of people passing basketball and the prompt at the beginning of the video is like count how many passes are made on this basketball court and people are so focused on counting the passes that they don't realize that a man in a gorilla suit walks through the court halfway through the

video. Then you watch it again after someone tells you, and it's like, how did I not notice that? And that's very similar to that transition of like being a novice versus being an expert, like an expert has that laser focus of what they need to pay attention to already. So they're not going to be bothered by that gorilla. It's not going to distract them at all. But a novice is going to probably see that gorilla and be like, maybe we need to stop the game. Like there's a gorilla here. It's like, should we be panicking? How come no one else is panicking? You know, it's just a very different perception of what people are paying attention to at different levels. And now that you mentioned that, I do recall seeing that. I do too. It seems like there's so many wins of just teaming

experienced expert with a novice and just having that be a team of all times because the novice just like you said the perspective is there but also just the questioning of the why the things that you don't even know why anymore like I don't really even know why I do it this way you have to start to question yourself

and that can improve yourself as an expert as well because some of the things we do are just habitual. They aren't the best way. And they get the job done. But that doesn't mean that you couldn't improve that process. And so that you'll see those things through new eyes that you don't see yourself. Absolutely. Yeah.

The novice tends to question almost everything because they need to question it. Because they're trying to hone down why they do what they do, why they do it, when they do it. And the experts like, I just know because it's been a thousand times and I haven't questioned again why that habit's a habit, but it is. And it pays off every single time because I get the job done every single day, et cetera. But the novice is going to question. That's a good idea to pair those two together because you always have that both sides of the better coin. They both benefit. Yeah. I always would tell my students or any new engineering hires, like the most valuable thing you bring to the table in that first week or that first job

is going to be your questions. Like your time to impact where you're delivering a big feature or fixing a major bug or whatever, like that might be a little bit slow to start at any new job. And that's fine. Like in the meantime, like ask all those questions that you can because people have been here for a while, forget, forget to ask or they don't know. I remember starting one engineering job I had years ago. And the first project I got put on, the guy behind me, Albert, he just stood up behind my cubicle and was like, hey, if you see anything weird in this code base, it probably is weird. And I was like, okay, like, he's like, let me know. And I was like, that was so nice and helped me so much because you don't know if it's supposed to be weird or it's intentionally weird or it's weird because of some reason that isn't relevant anymore. Or if it's weird because you don't know what you're doing and you don't have the skills for the job.

Like there's so many reasons why something would be unfamiliar to you. And for someone to explicitly say, like, hey, if you see something weird, tell me, because it probably is weird, is very reassuring. That's a really good way for people to build trust in these mentee-mentor relationships as well. It's funny, we just had that conversation on Ship It, which is our show all about putting the code

into the world with Gerhard LeZou. And we turn the lens on ourselves every 10th episode. Adam and I join the show, and we talk about the development of changelog.com and our podcasting platform and stuff. And Gerhard does a lot of the infrastructure config, our CDN configs, and I hop in there and try to help out. But he's the expert in that domain, and I'm very much the neophyte. And I was trying to fix some problems the other day, and I was just assuming he must have known

what he was doing when he did this. Like, it looked wrong, but I just didn't feel like I had the expertise to say, actually, this is incorrect. Because I just figured, it's Gerhard. He did it. He had good reason. And when I talked to him about it,

he was very flattered that I would think that. He's like, no, I just totally screwed up. I had no idea what I was doing, you know, in that particular context. But I gave him the benefit of the doubt because I was the novice and he was the expert. And if I had had that permission, if he had said, I got the FASI thing working, but I had no idea how I did it, then I would have been like, had more critical eyes. So it's interesting that communication can change the way you approach problems. Yeah, I absolutely love when our more senior engineers can be really vulnerable with other engineers and kind of demonstrate and show off like the mistakes that they've made or,

you know, the things that they didn't understand. I think that's a really good dynamic to create, especially when you're in these one-on-one scenarios. Like there's so many learning opportunities one-on-one with like pairing sessions and PR reviews, stuff like that. But there's always going to be a bit of a power dynamic there, which can hamper some of the feelings of safety that someone might have. Someone's more tenured, someone's more senior, someone's more experienced than someone else, right? And being able to create and maintain that level of safety and vulnerability within that relationship is going to be super important for learning from each other and trusting each other with what it is that you're teaching and what it is that you're learning. I think inviting people to ask you questions is super, super important.

Not just like, here's all the information that I have in my head. Go ahead and get started with this and see where you get. Like, that's okay. But like, see where you get and then come to me as soon as you have a question. Come to me when you have questions at the end of the day. Or let's schedule something for two days from now to go over any questions that you have, like assuming that they will have questions, letting them know it's expected that they will have questions and inviting them to come to you with those is super important for fostering that healthy type of relationship. This episode is brought to you by LaunchDarkly. Fundamentally change how you deliver software, innovate faster, deploy fearlessly,

and take control of your software so you can ship value to customers faster and get feedback sooner. LaunchDarkly is built for developers but empowers the entire organization. Get started for free and get a demo at LaunchDarkly.com. Again, LaunchDarkly.com. So, Brittany, you've rattled off quite a few different strategies or techniques, backwards thinking, scaffolding, incident analysis, different ways you can do these things as an organization. Is there a playbook somewhere where it's like,

okay, we want to do this well inside of our team or inside of our org. Can I just go find the playbook somewhere and say, here's six techniques for leveling up your engineers on the go or something snappy like that? Yeah, we don't have any formal playbooks on it yet, but it'll be something that we develop over time and hopefully can create resources for people around. Okay. So with any playbook, a lot of the value is what's not in the playbook, because you can waste a lot of time spinning your tires and trying things that aren't effective. And a playbook is like, here's six things that work. And we left out the 45 things that don't work. Surely you've come across both in your years doing this, things that are effective ways of teaching and things that aren't very effective. Can you help us avoid common pitfalls?

Yeah. So there've been a lot of things that we've tried to translate over in practice that I kind of don't want to give up on yet, but I just think I have to. And what one of those is like spiraling concepts. This is something that is super common in classroom-based education where you are really revisiting concepts over some interval. And in between those intervals, you're working on different stuff or you're learning different stuff. And then you revisit something that you learned maybe six weeks ago and you start building on top of that. And that works really well in the classroom or maybe in other industries. But in engineering, I think it falls short because people get so overwhelmed with context switching. And you put them on one project or one learning opportunity

where they're going to learn X, Y, and Z. But then they move off of that for maybe a couple months, depending on the workload of your dev team. And then when they come back to that, there's a lot of time spent having to re-familiarize yourself with what you worked on a month ago. And it's so quick and easy for those types of things to fall out of our heads because we do spend so much time focusing so strongly on our current task at hand that if we don't need information that we needed two weeks ago, we're going to prune that out of our minds. That's in some educational research, they'll call that cognitive offloading.

Whatever you don't need to remember, that goes away, especially when you have other focuses that you need to be paying attention to at any given time. So I've tried spiraling a little bit and it's been met with resistance and just not necessarily the best results, but not the worst results either, where people actively say like, I'm going to forget all of this if you move me off of it now and put me on different dev work. And then I don't come back to it for a long time. And I'm like, okay, let me clarify then like, what would I hope that you do remember about this experience six weeks, two months from now? And it might only be the tiniest thing.

We have like a Rails, Ruby on Rails application that my team works on. And I remember talking with one of our engineers that was like, okay, if you don't work on this again for two months and then you come back to it, all I would hope that you remember from your previous experience is like, you know, Rails console is your friend, and you have that great debugging

tool to work with. And you can go Google how to like write these different queries to get information from the database, like knowing that you had that exposure, and you can find that information. That's great. That's all you need to remember. And usually that is small enough, a small enough detail that it does stick as long as you're explicit about it. And as long as it's not too much, and then it makes them feel okay about not remembering everything that they worked on two months ago. They're like, okay, if this is just my goal to remember this, even if I have to re-familiarize myself with other information about what I worked on, I have some sort of backbone to lean on, some sort of memory that I can rely on to move a little bit faster this time. And I think for managers, it's all about making that okay and letting people know, I expect that you will need to spend some extra time ramping back up on this because it has been a long time since you've

touched it and not expecting them to be able to dive right back in the second time they look at our particular tool or system. So it's about repetition, right? Repeating, learning the same thing kind of over and over one additional layer at a time or kind of a little further into it, right? That's how I learn is repetition personally. So I can empathize with that process because if I hit the same thing or I, if I'm reading a book, for example, if they kind of recap, I like recaps in learning, it helps me. So that's similar to that nature.

Then it's kind of recapping, like you can come to the problem again, or you start the new chapter. Hey, by the way, in the last chapter, we read this part and here's how it kind of goes into this part here. If that's similar, then that style of teaching works for me. Yeah. And how I think how painful things are for you is also like a huge motivator for engineers where this problem I keep running into drives me bananas. And I can't stand it. Like, I'm going to commit the solution to this to memory so that I never have to run into it again. And that becomes a big motivator for future learning and

future reference that people can be relying on. But one thing about like how painful it is to learn or to run into problems, I think a lot of newer engineers won't know if the pain that they're feeling is worthwhile or going to be valuable for them or not. We had a phrase when I was teaching at Turing School and bullet points around effective struggle strategies. Like, how do you know when you're struggling in a way that is effective and worthwhile and worth your time versus spinning your wheels and going down a rabbit hole that you don't want to go down? And that's something that is also a little bit difficult to teach, but there are strategies around it.

Like teaching someone, having those close connections with someone who's working on something brand new and those checkpoints is super important for like helping them time box. Like, hey, I ran into this side bug that I don't know if I should pay attention to or not. Can you confirm for me if I should pay attention to or not. Can you confirm for me if I should pay attention to this? And this other engineer that they're pairing with can be like, spend one hour trying to debug that or completely ignore that or come back to me after a day of

looking into that. Because the person who knows those tools and systems will know if it's worthwhile to struggle on something. And someone who doesn't have that full picture of the system will have no idea if that's important or not or if that's worth their time or not. So being really effective with your struggle is super important. I found that was one of the things that I did often. So I did teach web development for a couple of years in classrooms. And as an instructor, I would be able to pick and choose

if I was going to remove a roadblock for somebody and get them along their way, or if I was just going to let them sit in that one. And it's like, no, you're going to figure that one out on your own, because I knew that was an effective, what do you call it, effective struggling. At that point, it was like, this is actually making you stronger if you get through this. Other times, it's like, you just can't figure out this database connection string. Like, this is not knowledge that you need to have. This is just ridiculous. Let me just fix it for you real quick and you can move along your merry way. Exactly.

Yeah. For senior engineers that are in these mentorship roles, there are definitely signs of effective struggle and ineffective struggle. Sometimes for the engineer, this might come out in emotions. They might be getting really frustrated or really short with some of their questions or how they're feeling about the particular work that they're on at that time. Sometimes it's a little bit more tangible than that, where when they're saying they're stuck, maybe they don't have the right words to express

what their question actually is or what they've already tried at this point and what didn't work or what did work and where their problem actually lies. One thing that we would see a lot with people who are struggling and spinning their wheels was like, especially for new engineers, like tons of commented out code. It was like they wanted to hold on to all of these things that they tried. And it's like, I can tell you tried 10 things and you're afraid to get rid of them because you don't know if they worked or not. And if you're at that point, that's not effective struggle anymore. You should always be able to clearly articulate like, what is my question? What is not working about my solution? What did I think? Why did I think my solution would work? And what did I try? And why didn't that work? Like always have that clear timeline of your struggle. And as soon as it starts to get difficult to explain that to someone else, that's how you know you're getting into these ineffective struggle scenarios where you're probably spinning your wheels.

The weeds. Yeah, you're in the weeds. Yeah. You're in the weeds. So before my professional days, I was a server at a restaurant and we would call that in the weeds, essentially, when you have too many tables and you can't keep up and you just cannot focus, we call that in the weeds. And that's where I learned that terminology applies many other places. Not just there, of course, but I learned what it meant to be in the weeds. Cause I'm like, I see my other people that work with me. I'm like, they're not struggling. I'm totally lost here. I don't know what I'm supposed to do right now. My tables don't have drinks. I can't get an order in the table. The food's not there. Everyone's upset and I'm getting no tips tonight. You know, like

that's deeply in the weeds and you just can't get your, your focus back. Yeah. Step away to get unstuck. Yeah. And it's also okay to be in a position where you don't even know what question to ask because you're so stuck and you've tried nothing or you don't understand the problem space. is or present it in a different way for their engineers so that they can start to come up with those questions. Because it's very possible to be so lost that you're either not sure where to even start or not sure what to ask. You're not even sure what you're not sure about, what you're confused about, right? So this is another aspect of like, you really need to build a close relationship and understanding of the background of the person that you're working with and the person that you're mentoring to see what kind of pre-existing knowledge they do have. What is their foundation?

Where is their area of expertise? So that you can start building these connections and mental models for them. We had a newer engineer join our team who had worked a lot with Git, and this was their first infrastructure position. So connecting Git for version control to Terraform was a really good link for them to be like, okay, version control for your infrastructure versus version control for your code. There's a lot of similarities there. And that helps them build these mental models on their own and use what they already know to transfer it over to what they're currently doing. But without having that experience, like it is probably a pretty obvious one that you can build off of for any type of engineer. But

if you don't know what their previous knowledge and foundation is, you can't help them build those mental models. So you really got to do a lot of research and have a lot of conversations with your mentee about what is your bread and butter and what things make sense to you and what things don't. Tell me about times that you've struggled. Tell me about times that things came really easy to you and build that relationship. Those kind of exchanges, though, does require some vulnerability, right? Because that person that's the mentee is going to have to potentially share like, you know what? They have to show the side of them that doesn't know.

And that's challenging. Yeah, absolutely. And I think that comes with the safety aspect of that comes with as a senior, like demonstrating, here are the things that I don't know anything about. These are the things that I struggle with. And these are the things that I get really confused by. And I always have to lean on this person to help me out with this because they're my expert over here and showing that no matter where you are at in your career, like you're always going to have those areas that you do and don't understand. And you're never going to have

a completely full picture of everything. So demonstrating. Essentially, it provides some safety, right? Because in vulnerability, you're like, can I be safe to share what I don't know? And that's a version of saying, hey, it's safe. Right. Because I'm vulnerable in these ways. I don't know everything And that's a version of saying, hey, it's safe. Because I'm vulnerable in these ways. I don't know everything here. In these ways so you can reciprocate and be vulnerable too. At Articulate, do you have an explicit budget for education? Do you have that at your disposal? Because I'm looking at some of these

things like lunch and learns and bringing in outside teachers and a lot of these things actually require capital expenditure, right? Yeah. So we don't have like a dedicated internal team on education right now focused on those efforts, but we have the personal professional development budgets for all of our engineers and anyone in the org really for a benefit to go expand their learning and their education. We've done hackathons and some free time for autonomous work that you can kind of focus on things that you want to level up in a little bit. So we do a lot of the standard things right now that I think a lot of orgs do in terms of benefits that way. And then these education efforts are all just

getting rolling because we've been a pretty small company so far. I think about 250 employees and we're starting to grow and absolutely feeling a lot of those pain points of becoming a way larger organization already. And that's how we're starting to recognize the need for all of these processes and touch points, learning opportunities, leveraging all of these processes and touch points, learning opportunities, leveraging all of these types of things that we can use to really level up our engineers and make it easy for them to do their jobs and learn our systems, learn our tools. I'm just thinking about somebody who wants to instill these values

and then execute on these values inside of their orgs and what are the kinds of things that they would need. That's why I asked about a playbook. It seems like you need some sort of budget or some sort of ability to spend some money, especially some time, right? Because a lot of this is slow down

to go faster kinds of things. The way you're working with some of your new hires and having them, I mean, even the scaffolding idea, it's like, it's probably just faster in a short- term sense to just let the senior do the thing, right? Versus like scaffolding it out and handing it off to somebody else. So these things, I think, require buy-in at maybe not the highest levels, but high up levels, including time and budget constraints. Yeah, absolutely.

So I definitely think budget is a concern and knowing to prioritize that upfront time cost for future gains in efficiency later is super important. And I think as managers and directors at Articulate, we have the autonomy to do that. And it is absolutely up to our discretion. If we think handing this work off to this person to help them level up here and learn this particular piece of our tech stack is going to be really beneficial down the road, like nobody's going to stop you from doing that. to make those calls and make those decisions because you don't have to have a dedicated team or person that is solely focused on implementing these educational efforts all across the org, on every team, in one-on-ones. You can integrate all of that stuff directly into the organization from a manager role, from a mentorship role, from a director role. That's very possible to work that into all of the day-to-day, as long as you have the

autonomy and the trust to do so. So you say you don't have the actual education team, but it's sort of baked in. What is that called? And how do you, if you don't have that, so speaking to listeners that don't have this and want to instill it, what would you call it if it doesn't have a name yet? And how do you pitch that as an idea? Like, how do you forecast the possibility of instilling these kinds of things, baking these kinds of things into your org levels and managers? Great question. I think you really want to define that as a core value

and core priority, either for a relationship, when you define the relationship between a senior engineer and someone who they're going to be mentoring, they can define that as a core value in their relationship. They can say, okay, we're always going to prioritize your growth and education and learning, and this is how we're going to do it. We define the relationship there. As a manager or director of a small team, you might be saying, okay, within our team, this is how we operate. We put these types of processes in place because we're going to prioritize these types of learning efforts. And you work that into the policies for your particular team. This works really well at Articulate because we do have that autonomy

to run our teams and that autonomy to run our teams and that trust to run our teams the way that we see fit. Maybe at other organizations, they're a bit more strict with that type of stuff. But at the team level, you can define that as a core value. And then at the org level, maybe it's not defined as a core value yet. But I would say that is something that organizations that want to achieve this should put in place as one of their core values, if that's going to be something that they want to be focusing on and are bought into dedicating that upfront time and effort to focusing on.

Yeah, I like that. It's like, it's incremental. You start at the smaller area where you can see the surface here and control better. And then you see the success and you use that success to layer it up. It's iteration. It's iterative, essentially. Iterative education. I don't know what to call it, but, you know, it's like, how do you take it out there?

It's like you iterate that because you want to put it in the... Ongoing, right? Ongoing education. Yeah. Is that what they call it? Yeah. Well, I mean, why I say iterative is because you, you know, you started in the smaller two-person sense or small team sense,

saw we're able to put some sort of framework in that made sense for your coding style, team, or operational, organizational, whatever it might be. And then you said, hey, everybody else, this is how we're doing it here. It would make sense if we upgraded our engineering departments in these ways by adopting what this team did very well. What can we take there and extrapolate it across these teams and what would the benefits be if we saw that and then that's how you get buy-in from the higher-ups who are disconnected from that not they not that they don't care they just literally are disconnected from different just delegation of natural organizational properties yeah so i think if you start small you're able to prove how it works show show success there,

and maybe even iterate a few times to get it better, right. And then present your, your case to the wider org. Yeah. And once you have that proof, it's so contagious, like, especially at these smaller organizations, like stealing ideas from each other is our favorite thing to do at Articulate. We're always creeping on each other's meetings and popping in to different team meetings. We're like, oh, I like this idea. Like, I see how they're doing this. Like, let's do this too. And it's just kind of unspoken. Like, you'll see things that are working elsewhere and you'll just start bringing that into. We do it here too. Yeah, into your team.

In different ways though. It's still Jared's words. He still has my words. Oh, for sure. Yeah. What does the proof look like? Is it happy engineers? Is it you end up moving faster eventually? What does that quantify? It seems like it's hard to quantify. Yeah, I think it's both of those things. I focus a lot on efficiency and really seamless resolutions to issues.

So on our team in particular, the platform team, really seamless resolutions to issues. So on our team in particular, the platform team, we're supporting lots of engineering teams internally. And we have a lot of really good data points that we can work off of. So we'll get a lot of questions from a bunch of engineering teams about how certain things work or something about our infrastructure or platform.

And we can literally see the number of requests that come into our team and the types of requests that come into our team. And we're like, okay, let's figure out how to do better education for product engineers around this topic, because this is something that keeps coming back to us as like a point of confusion or a pain point for our engineers. And after we implement either, this is either more documentation, this is lunch and learn discussion, like whatever the format is that we choose to try to talk about, maybe it's improving the system, maybe there's bugs in the system that need to be improved. All of those types of strategies, we implement that.

And then we have data to look back on to say, no one has reached out to us about this problem since we did X, Y, and Z. And we see that enablement that we're able to provide for our product engineers using actual hard data. So things like that is something that the platform team specifically looks at quite frequently, just the amount of questions and pain points that we can see engineers running into. But I think also just being able to move really efficiently and fast on a lot of our projects is another indicator. And being able to have anyone jump into anything pretty seamlessly is huge. So our team is responsible for, I think it was like 100 repos at one point. It's less than that now.

But there are so many things that we needed to know about on this team. And for a while, we had one person is an expert on this tool. One person is an expert on this tool. Oh, if this person's out, you're going to have to wait till tomorrow to get an answer to your question on it because they're our expert. And with these educational efforts that we do within the team, it's slowly becoming a scenario where anyone can hop into this and get the answer to this or bring this to resolution because we've either put really good documentation in place or we've done a really good job sharing

context at our standups or leaving each other the training and learning opportunities that we need with scaffolded PRs in order to get other people involved in an easy and safe way with these other projects. So things like that. Anything on closing, Brittany, any, I know we got some resources mentioned, we'll put in the show notes, but I'm curious if there's anything you want to call out that's like, okay, you made it this far. You must want to dig further or dig deeper. Any particular resources you care to call out or want to call out? I would definitely read up and watch the two talks that I mentioned, Camille Fournier's blog post and Katrina Owen's video on cultivating instinct. And then there's a lot of education research that I would encourage people to look into just literally about how our brains work and what the different learning styles are

that exist. And I have tons of links to these that I can send over that we can include. But this will really help us understand like why we prioritize certain things in our minds and we prune out others, like why it's important for us to know like what it is about our instincts, what that made those things instinctual for us and how we can get back to that beginner perspective. And then it might help you come up with more creative strategies for how to implement some of these classroom-based learning opportunities that we've talked about today. So lots of educational academic research I would definitely be digging into. Yeah, be curious for sure. We'll get those links from you and put them into our show notes.

So listeners, you know they're there. So head back to the notes. You'll find them. Link away. Dig deep. Be curious. Brittany, thank you so much for just walking us through this process and sharing a lot of your wisdom i know it's it's just like wow i mean to to lead and be led is a challenging thing and and to learn how to learn or even teach how to teach it's it's a challenging thing and yeah i appreciate your time today thank Thank you so much. Thank you both so much. That's it for this episode. Thanks for tuning in. What do you think about learning focused engineering?

What are some takeaways you got from this episode? Share them in the comments or on Twitter. We'd love to know what resonated most with you. Thanks again to our partners, Linode, Fastly, and LaunchDarkly. Check them out, support them. They support us. Also, thanks to Breakmaster Cylinder for making all of our awesome beats. of course thank you to you if you enjoy the show do us a favor tell a friend we'd love to have them as a listener word of mouth is by far the best way for us to grow our shows

if you're looking for more podcasts to listen to the galaxy brain move is by listening to the master feed check it out at changelog.com slash master get all our shows in a single feed that's it for this week. The show is done. We'll see you next week. Game on.