Coaching through Coding

RubyConf 2020

by Mercedes Bernard

In the video titled Coaching through Coding, Mercedes Bernard, a Principal Software Engineer and Engineering Manager, emphasizes the importance of mentorship and coaching available in everyday technical activities. Rather than viewing mentorship as limited to one-on-one conversations, she encourages a broader perspective where every coding activity offers a chance for team support and growth.

Key Points Discussed:

Diverse Roles: Mercedes discusses the distinction between individual contributors and management roles, arguing that both can be equally technical and supportive of team growth.
Metaphor of Transportation: She uses the analogy of a bus (management) versus a bike (individual contributor) to illustrate different career paths, promoting the idea of 'tandem biking' where team success is prioritized over individual speed.
Coaching vs. Mentoring: She clarifies the difference between coaching, which focuses on immediate skill development, and mentorship, which is more relationship-oriented and long-term. Both are vital for professional development.
Practical Strategies for Coaching: Several examples are provided where typical coding tasks can be turned into coaching opportunities, including:
- Pair Programming: Discusses how to effectively pair program to promote learning without overpowering the less experienced partner.
- Code Reviews: Stresses the importance of providing constructive feedback and fostering discussion about coding decisions instead of merely pointing out mistakes.
- Team Meetings: Suggests using estimation and status update meetings as opportunities to mentor by sharing knowledge about decision-making and project complexities.
- Documentation: Advocates for the collaborative creation of documentation to solidify team knowledge and promote transparency.
Encouraging a Learning Culture: Finally, Mercedes underscores the idea of sharing personal learning experiences and successes with the team to foster a culture of continuous growth and to combat feelings of imposter syndrome.

Conclusions and Takeaways:

Mentorship and coaching extend far beyond traditional boundaries; they can and should be integrated into daily technical tasks.
Through practical strategies in everyday tasks, engineers can nurture an environment where learning is a collective journey rather than an individual race.
Emphasizing joy in learning and collaboration will enhance team dynamics and overall productivity.

00:00:05.359 All right, my friends! Here we are, in the closing throes of this conference.

00:00:10.559 I’m very excited! Just before we jumped on, I was chatting with Mercedes.

00:00:16.640 A few years back, I saw her at a conference, and apparently, it was the first talk she had given.

00:00:22.400 It was very resonant for me; I really enjoyed it.

00:00:27.760 So, I can only imagine you’re going to feel the same today!

00:00:33.440 One thing I wanted to shout out, though, is that if you haven't put in your RubyConf virtual 5K or 30 minutes of exercise before the end of today,

00:00:41.760 I would love to see if we can get that number up over 40! So far, we're well into the 30s, which is pretty exciting.

00:00:46.800 The second thing I just posted that I want to put out there is that I would love to know what your 60-second Ruby story is.

00:00:53.199 What got you into Ruby? What got you into this community? If you haven't seen that in the open chat, please take a look.

00:00:58.640 There’s also a Slack channel called 'My 60-Second Ruby Story,' and I would love to hear everyone’s story.

00:01:10.960 All right, without further ado, I want to welcome Mercedes to the stage. With that, I give the floor over to you.

00:01:31.439 Lunch was good! I hope you guys got outside and were able to enjoy the nice weather. We have some rare nice weather here in Chicago, so I'm enjoying it.

00:01:37.439 Today, we're going to talk about finding opportunities for coaching and mentorship in the daily technical activities of our work.

00:01:43.920 This talk is written for senior-plus engineers—senior, principal, staff engineers, etc.

00:01:50.320 But I hope—and I'm pretty sure—that everyone who's here today will be able to find at least one new strategy,

00:01:57.119 if not a couple, to bring to their team to create a more welcoming learning environment for everyone, regardless of their level.

00:02:02.479 My name is Mercedes Bernard, my pronouns are she/her, and I'm a Principal Software Engineer and Engineering Manager with a digital consultancy in Chicago called Tandem.

00:02:08.560 If you would like to follow along, you can find my slides on my website, and I also tweeted out a link right before this talk.

00:02:14.239 If it’s easier, it's also in the Slack channel. So feel free to tweet at me, live tweet the talk, or shoot me messages in Slack.

00:02:20.000 How you want to get in touch is totally cool. I'll be doing a virtual Q&A right after this talk, and I’ll catch up with all of you then.

00:02:27.520 As we progress in our careers, we're often met with a fork in our career path. Do we want to progress into people management or become a technical expert and stay on the individual contributor track?

00:02:33.840 For anyone who isn’t familiar with the term individual contributor, it's used to describe the role of a software engineer who contributes their deep technical skills and ability but doesn't have people management responsibilities.

00:02:41.760 Personally, I find the distinction between people management and individual contributor to be somewhat limiting.

00:02:47.200 I think folks who manage people can still be really technical, and I believe that people with deep technical knowledge have a responsibility to share that knowledge with others.

00:02:53.280 So what if I told you that instead of a fork in the road, the choice to pursue a management or an IC role is really like deciding whether you want to switch into the bus lane or stay in the bike lane?

00:03:02.159 Hear me out: when we go into people management, we're responsible for supporting the growth of many different people at different stages in their careers.

00:03:08.720 It's kind of like driving a bus and helping your team get to where they're going. Don’t worry; this is a safe metaphorical bus.

00:03:15.680 When team members need to work on a skill, they can get off at that stop and invest time in honing that skill.

00:03:22.080 Then, when they're ready, you pick them up on your next route through and mentor them on possible next steps they could take.

00:03:29.280 A good manager shows where you can go and helps you get there. They find opportunities for you and offer directions if you need them.

00:03:38.000 Whereas being an IC is more like commuting on your bike. During your bike commute, you can take the quickest route to get to your personal desired destination.

00:03:44.000 You can find all the shortcuts and convenient detours to avoid tricky intersections or traffic.

00:03:50.080 It might take more effort for you to bike to work than to get on the bus, but you can take a fast, straightforward route that works for you.

00:03:57.840 However, it's often not in the team's best interest for one person to get from point A to point B as quickly as possible.

00:04:05.680 As I mentioned in Brandon's awesome talk on Tuesday, 'Tales of the Autistic Developer,' you'll know exactly what I'm talking about.

00:04:12.480 Our success is often measured by the technical problems we solve, but I think our industry has taken the 'individual' part of individual contributor too far.

00:04:19.200 We assume that a top performer is someone who can do the work of ten others or do it ten times faster, rather than someone who can enable and empower the work of ten others successfully.

00:04:26.640 I take heart in the fact that the '10x developer' has become a meme at this point, but there are still too many people responsible for building teams looking for their unicorn.

00:04:33.920 Team success is marked by continuous learning and growth, and our senior ICs should support the team's success by finding ways to contribute to everyone's professional development and learning.

00:04:40.000 Sometimes, the most enjoyable commute is one that you take with someone. So I'm proposing that we start taking more tandem bike rides together.

00:04:46.720 This means slowing down just a bit to ensure that the whole team succeeds.

00:04:52.560 Throughout this talk, I’ll be using the terms mentorship and coaching. Mentorship is a fairly common concept that's tossed around a lot in our industry.

00:04:59.520 We’re starting to hear about coaching more and more; they both fall under the mentorship umbrella.

00:05:06.240 However, there is a little bit of nuance that I think is important to call out.

00:05:12.240 When we hear the term mentorship, a lot of us tend to think about one-on-one conversations over a cup of coffee or tea, where the mentor tends to do most of the talking.

00:05:19.880 This is because mentorship is very relationship-oriented; it relies on getting to know one another well in order to share goals and offer advice.

00:05:28.000 Conversations like these require a lot of trust and vulnerability, so mentorship relationships tend to be more long-term.

00:05:34.639 Coaching, on the other hand, is less about the future and is more grounded in the present.

00:05:40.639 Instead of offering advice for potential goals and career growth, coaching fosters the growth of current skills by providing feedback and guidance for the task at hand.

00:05:48.320 Because coaching is more skills-focused, it doesn't require as much of a long-term commitment for that relationship-building piece.

00:05:56.119 This makes coaching an incredibly powerful tool that can be used in many different interactions.

00:06:03.840 While managers support the career growth of their team through mentorship, everyone has the opportunity to support their team's technical skill growth with coaching.

00:06:09.920 As a senior-plus developer, we write a lot of code, but we also have a whole variety of other technical responsibilities.

00:06:15.759 Every single one of those is an opportunity to coach someone and help level up their skills.

00:06:21.600 So, I’m going to walk through examples, starting with the very code-heavy activities and moving to the less code-heavy activities as we go.

00:06:28.159 First up is pair programming. Pair programming is a wonderful coaching tool when approached correctly.

00:06:36.239 Collaborating on a piece of code with a less experienced team member provides a safe learning environment.

00:06:43.440 You can provide suggestions and feedback without going into full teacher mode, which keeps the session comfortable and incredibly valuable.

00:06:49.440 As a senior-plus engineer, you should spend a lot of your pairing time navigating.

00:06:56.480 How do you decide if you should be navigating on a specific task? Tasks that may be too challenging for your pair to implement solo or that may solicit a lot of code review feedback are good candidates for navigating to help them level up their ability.

00:07:05.600 I tend to think about complex stories as those that touch many layers of your system, but it could also be ones that require a lot of domain context or use tricky design patterns, or some other scenario specific to your project.

00:07:13.680 In the navigator role, you have the opportunity to coach about code architecture and organization.

00:07:19.680 You also leave your pair in control of the session as the driver.

00:07:27.519 Power dynamics during pairing are real, whether they’re based on gender, race, organizational hierarchy, personality differences, or other factors.

00:07:35.040 Given the reality of our industry, the power differential usually skews to privilege the more senior engineer.

00:07:42.560 By having your pair drive, you can create a safe pairing space by setting expectations that they control the pace.

00:07:49.679 They can stop the session to ask questions or get clarity anytime they want.

00:07:56.479 When you're navigating, stay focused on the big picture thinking.

00:08:05.920 Let the driver decide on naming and syntax, but be ready to help where needed while letting them focus on the details.

00:08:12.000 This approach can be especially helpful for someone early in their career to get comfortable making decisions between two similar implementations.

00:08:18.080 For example, deciding whether to use a map or an each to get the muscle memory that we tend to take for granted, like creating Rails migrations or spec files.

00:08:25.440 As they make decisions, you can provide feedback and context to model thinking through the trade-offs and choices.

00:08:32.480 Where you take a more active role in the pair session is deciding how the individual pieces of code that your driver is writing will fit together.

00:08:39.680 You can coach them on deciding when to create an abstraction or when to make a service object for easier readability and maintenance.

00:08:46.560 Hearing how you make your architecture decisions and how you put the pieces together will strengthen their own architecture skills.

00:08:53.200 This might be counterintuitive, but as a senior-plus engineer, I think you should try to spend 50% of your time driving during pair sessions.

00:09:01.440 When should you be driving? Tasks that would be a stretch for your pair to implement solo are good candidates.

00:09:08.640 When I say 'stretch,' I mean something within their scope of skills but that would challenge them with a new pattern they haven’t used before.

00:09:16.080 Or a problem they haven’t solved before but is similar to something else they’ve done.

00:09:23.840 Driving on these types of tasks is a good way to foster your pair’s technical thinking and communication by providing support in that stretch space.

00:09:30.560 Other good candidates for driving are areas of the code that your pair is more familiar with than you are.

00:09:38.160 As senior-plus engineers, we need to be comfortable recognizing the expertise of our team members and celebrating it.

00:09:44.080 This does wonders for combating imposter syndrome and leveling the playing field, so that everyone on the team feels safe and comfortable sharing opinions and lending their expertise.

00:09:50.240 However, when I'm talking about driving, I mean the very traditional pair programming definition of driving, where you are concerned with the smaller issues at hand, like syntax and naming.

00:09:58.240 This makes space for your pair to practice their technical communication skills.

00:10:04.720 Vocabulary is really hard in software engineering, and we all need to practice explaining our technical ideas to become skilled at this type of communication.

00:10:11.840 We also need practice to be able to identify what we don’t know and how to ask questions to help us find solutions.

00:10:18.640 When you're driving, resist the urge to fill silences or give them the answer. Use questions to understand what the navigator wants to do next.

00:10:25.920 Mirror their statements to check for your understanding, and provide them with the vocabulary if they get stuck.

00:10:32.560 Use pseudocode liberally to capture your navigator's ideas; sometimes, seeing code can help people articulate what they are thinking.

00:10:39.440 As you're driving, explain why you're naming things the way you are or how you're making decisions about which lines of code you're writing.

00:10:46.240 This is an opportunity for you to coach on readability and simplicity, helping the next developer understand your code.

00:10:52.080 If you find yourself taking too much control of the pairing session and your pair is just watching you code, you should pause.

00:10:58.640 Ask yourself: are you navigating so much because the task is too complex and not a good stretch opportunity? If so, talk to your pair and ask them to switch to navigate.

00:11:05.680 If you're navigating because it's too hard to let go of control, take a break, grab a drink of water, and when you start pairing again, acknowledge that you are navigating too much.

00:11:12.000 Apologize and be more aware as you continue. It takes practice, and no one's perfect.

00:11:18.560 But recognizing when you’re falling into this pattern will help you break the habit.

00:11:26.719 Debugging sessions tend to blur the line between driver and navigator a bit more than stories, since neither of you may know what's happening or what's causing the issue.

00:11:34.000 If you're in the navigator role during a pairing or debugging session, you can explain how you're interpreting the symptoms you're seeing.

00:11:40.480 This can include error messages, odd behavior, steps to reproduce, or data discrepancies.

00:11:47.360 You can lend your expertise by pointing the driver where to look and then describing why you think something is or isn't important to continue investigating.

00:11:54.080 When you're driving, your pair can practice critical thinking and problem-solving skills since they’ll be reading error messages, interpreting their meaning, and directing you where to look for the cause of the issue.

00:12:02.080 This is incredibly valuable because these aren’t the kinds of skills that are typically taught in most educational programs.

00:12:09.680 Having your pair make decisions about what to investigate next makes it easier for them to remember, next time, that it might be a data issue.

00:12:17.280 Or they should isolate whether the bug is happening on the client or server by checking the network tab.

00:12:23.440 My personal preference during a debugging session is to have my pair navigate while I’m in the driver’s seat.

00:12:30.560 I was recently pairing with an apprentice, and they were driving while we were debugging an interesting React bug.

00:12:37.600 They were so interested in fixing the problem that they were making changes faster than the hot reloading could keep up.

00:12:43.040 Within a couple of minutes, I had no idea which change we were testing because Webpack was still rebuilding.

00:12:49.279 In that moment, I asked them to pause and explain why they made the last change they did.

00:12:56.000 We laughed because they were using a 'throw it at the wall and see what sticks' approach, but it wasn’t super helpful.

00:13:02.719 We couldn’t keep track of what they had tried or why they were trying it.

00:13:09.840 We swapped roles in the pairing session, and I was able to have them navigate and explain what changes they wanted to make.

00:13:17.680 This allowed us to be more systematic and isolate the bug.

00:13:24.000 In my experience, early career developers try to move through debugging steps quickly because they feel pressure to find the answer.

00:13:31.760 As the driver in a debugging session, you can slow them down a bit and make sure that you are methodical as you check your assumptions and try to reproduce the issue.

00:13:46.880 Code reviews can be intimidating. Going into GitHub or your source control tool of choice and seeing that big red 'Changes Requested' can be discouraging if not treated with care.

00:13:53.520 Without proper consideration, the feedback given lacks context and can be less than helpful.

00:14:00.000 When prioritized as a coaching tool, code reviews provide some unique opportunities for sharing knowledge and developing technical skills.

00:14:06.080 Some of the benefits of code reviews compared to pairing are that they can be asynchronous, so you don’t have to align your calendars.

00:14:12.800 This can be especially challenging now that most of us are remote and many teams are juggling time zones.

00:14:19.600 If you're using a tool such as GitHub's pull requests, code reviews also serve as long-lived written documentation that the reviewee and others on the team can refer back to.

00:14:25.680 When you're providing feedback about something that you think should be changed, make sure that you are specific about the reasons why instead of using vague terms or talking about what’s better.

00:14:31.520 Explain what the benefit of your proposed change will be and why you prefer the proposed solution.

00:14:38.080 Explaining the benefits and potential trade-offs helps model technical decision-making skills for the reviewee.

00:14:44.800 Without ever sharing the reasoning that goes into a decision, it’s hard for someone to learn the various considerations to think about when they’re coding.

00:14:52.000 Taking this extra time to model this behavior helps them develop these skills for making their own implementation decisions next time.

00:14:58.400 It's also important to balance prescriptive requested changes with open-ended questions from both a kindness and coaching perspective.

00:15:05.200 Code is subjective, and there’s no right way to do it.

00:15:11.680 Open-ended questions allow you to make suggestions without forcing someone into your choices.

00:15:18.080 They’re also a useful coaching tool to stretch someone's skills as they progress in their career.

00:15:25.679 Rather than providing an answer for them, you can prod them to think about something they might not have considered.

00:15:32.960 For example, pointing out nested iterations and asking 'How might we reduce the nesting levels here?' gives them some guideposts to think through alternative implementations.

00:15:39.200 Open-ended questions are more process-oriented than result-oriented.

00:15:46.080 They facilitate a dialogue about the code and make space for a larger conversation, paving the way for more coaching opportunities through pairing or implementation.

00:15:55.840 Code reviews aren’t only for requesting changes and picking apart code; there is always something positive to find while doing a code review.

00:16:01.920 It can be a well-written test, a great variable name, or just evidence that someone's coding skills are leveling up.

00:16:08.160 For instance, they might have clearer and easier to understand methods.

00:16:15.040 It’s important to share positive feedback to reinforce the learning and growth that has occurred.

00:16:22.080 A small comment about how great a variable is can remind the reviewee that other people will read and use this code.

00:16:29.120 So, naming and documentation are important skills.

00:16:36.320 Finally, giving feedback in a PR isn’t the only way to use code review tools.

00:16:44.000 You can also use them proactively to add comments to code that you've written to guide and coach your team.

00:16:51.520 First, make sure your PR description is helpful. It should explain not only the high-level change you made but why you made it.

00:16:58.080 What is the use case or added benefit that this change will give the user? What bug behavior does this resolve?

00:17:05.360 Provide context, so your reviewers can review more than just the lines of code present, but also think about possible enhancements.

00:17:10.960 If you used Stack Overflow answers to find a solution, link to them.

00:17:18.560 If you found yourself digging deep into documentation to find an answer, link to it.

00:17:25.440 If you know you're using a specific design pattern, explain it and maybe link to a helpful blog post in case someone wants to learn more.

00:17:32.120 As you do this, closed PRs become treasure troves of knowledge for the present team to expand their skills or for future team members to understand legacy code changes.

00:17:40.560 By proactively sharing documentation, you're showing that everyone has to look things up, and it’s okay not to have an answer.

00:17:48.240 Success is measured by finding answers, not by having them—something anyone who attended Emily's talk yesterday about the memory compaction bug will understand.

00:17:54.000 Linking to relevant documentation can help your team become more comfortable reading docs and more skilled at determining what is and isn’t helpful documentation.

00:18:01.920 This will ultimately increase their efficiency.

00:18:09.040 If your PRs are still especially needy, don’t be afraid to go through and conduct self-code review.

00:18:17.360 Leave comments on tricky bits of code or configuration explaining what they do.

00:18:24.240 I recently had a PR focused on improving performance for one of our key use cases.

00:18:32.000 It was especially complex because our client’s on-prem database is Oracle, which is a non-standard choice for Rails.

00:18:39.440 Some of our go-to Active Record strategies weren't available in the Oracle adapter, which means we couldn’t add extra indexes.

00:18:46.080 So I had to get creative! I went through and explained my choices in the comments and what each part was doing.

00:18:53.120 This made it easier for reviewers to follow the diff and understand what they were looking at.

00:19:01.760 When someone just skims your code and gives a 'looks good to me' approval, no one benefits.

00:19:08.320 The more questions you can prompt about your code, the more opportunities you have to ensure that everyone on the team understands the implementation.

00:19:16.480 Everyone wins with more questions, so find ways to encourage your team to dig into the code you write.

00:19:23.760 When we aren't writing code, that doesn't mean we're not still engaging in technical work.

00:19:30.800 The tasks we do every day are filled with opportunities for learning and sharing.

00:19:37.840 Estimating is a really hard skill to learn!

00:19:45.680 During an estimation meeting, when someone estimates low and you estimate high, have them explain why they think the task is low effort.

00:19:53.040 Understand where they’re coming from, and then explain why you estimated high.

00:20:00.560 This is a good opportunity to explain non-obvious considerations or remind the team about all the different layers of the application that the new functionality will touch.

00:20:07.440 Sometimes, when we're early in our careers, we tend to oversimplify tasks in our heads, forgetting that we need to migrate data or that there's no API for this new design yet.

00:20:13.840 Or we might remember that stakeholders always wait until the last minute to change their minds, so we should anticipate this pattern.

00:20:20.200 Sharing all of your estimation considerations can help your team broaden their thinking and consider things they haven’t thought of before.

00:20:28.480 Opening up the estimation process for conversation also makes space for your team to share their expertise.

00:20:34.560 Sometimes, you’ll learn about a part of the codebase they are more familiar with when they practice pushing back on your assumptions.

00:20:40.960 They can explain why your estimate is too high because you’re not considering code reuse or other patterns already in place.

00:20:47.680 They are flexing those muscles in a safe space and growing for when they might need to use them with stakeholders later.

00:20:54.720 Status updates in stand-ups or other meetings are great places to share with the team what you’ve tried and what did or didn’t work.

00:21:02.160 Sharing things that didn’t work is just as important as sharing what did, because it shows how you approach problems.

00:21:08.880 Learning how to problem-solve and developing new strategies are key to success in our work.

00:21:15.440 You can also coach your team on timeboxing by explaining when you knew it was time to change tactics and try something different.

00:21:21.920 This will help them learn to manage their own time and lead to a more productive team.

00:21:30.160 Sharing your status updates creates space for people to express interest in work they aren’t involved in, and gives you the opportunity to include them.

00:21:35.040 This helps ensure that everyone on the team has a chance to develop a variety of skills and helps build your awareness of each team member's specific interests.

00:21:41.360 As developers, we hate documentation, and I don't know many people who enjoy taking the time to write it well.

00:21:48.320 Documentation often gets deprioritized in favor of more code, but creating architecture diagrams and functional documentation is a valuable opportunity for pairing.

00:21:55.440 It can help your team see the big picture of the entire project and encourage everybody to remember your users.

00:22:01.680 This increases our empathy when we’re building it.

00:22:08.000 Creating documentation helps solidify what the team knows about the system and creates opportunities to ask questions about things they don't.

00:22:15.520 Increased confidence in their knowledge of the system increases comfort and safety for them to ask more open-ended questions about why parts of the system were built the way they were.

00:22:23.440 Documentation doesn’t just come at the end of a project or feature.

00:22:29.760 If you are creating diagrams at the start of a project to think through different system configurations or potential strategies, you have an opportunity to discuss the pros and cons of each.

00:22:37.200 You can help your team understand why we might choose one approach over another.

00:22:44.480 On my team, we've been talking a lot about the constraints of our current project.

00:22:52.160 We've discussed when those constraints make it appropriate for us to use microservices and when they may increase our maintenance effort without any added benefit.

00:22:59.120 For example, our current client has a large legacy system made up of many different databases, with multiple database management systems underneath.

00:23:06.320 They’ve been known in the past to change which database they want us to query for critical data with little to no warning.

00:23:13.520 So rather than configuring Rails to handle multiple databases and figuring out how to manage multiple Active Record adapters,

00:23:20.240 we chose to use some selective microservices to manage database connections.

00:23:27.840 Being able to talk through these constraints and how they led us to the microservice decision has been really productive.

00:23:35.360 It led to additional architecture talks that will help on future projects.

00:23:43.040 Engaging in conversations about architecture and infrastructure considerations will deepen your team's understanding.

00:23:50.480 They will be able to bring this knowledge with them to their next project.

00:23:56.720 Finally, pair with someone on the team when you're doing research or investigating a spike.

00:24:05.920 I've said it before, but it's worth emphasizing, sharing how you research and how you make decisions is beneficial.

00:24:13.120 We rarely learn these skills in any coding school or college program; we have to learn by doing.

00:24:19.440 Sharing your tips and what you've learned over the years by researching with them will help them develop these skills faster.

00:24:25.760 Think about the last time you went googling for an answer to a tricky technical question.

00:24:33.200 How were you able to glance at the first three Stack Overflow questions and know they weren't helpful to your specific case?

00:24:38.640 When you look at documentation, how long do you spend digging before you realize that the feature you're looking for either doesn't exist or is undocumented?

00:24:44.320 How do you know when it's worth cracking open the source code of an open-source library to find that method parameter you're looking for?

00:24:53.200 All of these questions are things that come with experience, and we can save our team time and provide guidance for them to learn this kind of intuition.

00:25:01.440 One of my favorite tricks when I'm stuck trying to figure out how to use a new library is to check out their test suite.

00:25:08.800 Tests can be a quick source of documentation to see a variety of ways to invoke the library, helping find your use case faster.

00:25:15.360 Pairing while researching and looking for questions also helps create a level environment where you and your pair can be confused and learn together.

00:25:22.679 This is great for trust and relationship building and boosting resilience, so that imposter syndrome doesn’t kick in the next time your team member doesn’t have an answer.

00:25:29.920 Create a welcoming space for people to say, 'I don't know; let me go find out!'

00:25:36.160 At the end of the day, I think the most important coaching tool is to share joy in learning with your team.

00:25:43.040 To be successful in tech, we need to be continuously learning, so no matter how small something you learned is, tell your team about it.

00:25:50.640 Get excited when you hook up a radio button in a framework you've never used before.

00:25:58.160 Share that feeling of accomplishment when you finally identify that ridiculous edge case in the legacy system you're integrating with.

00:26:05.840 Show off a silly side project you're making or wow your team with a new hobby you picked up.

00:26:12.240 We don’t have to be experts all the time. Our jobs are fun because we get to learn and solve problems all day long.

00:26:19.520 Share that with your teams! Your commute becomes more enjoyable when you share it with someone.

00:26:27.520 The same goes for learning and growing. We don’t all want to be bus drivers, responsible for helping our team members get to the next stop in their careers.

00:26:36.080 But that doesn’t mean we can’t travel with them for a little while and still find opportunities to support their career growth from our own bike seats.

00:26:43.360 We should think of our technical work like riding a tandem bike and look for people to share a ride with.

00:26:49.760 I hope you all enjoyed this. As I said, I’ll be hanging out in Slack if you have questions or want to talk about this further.

00:27:00.560 But thank you so much!

00:27:05.760 Well, all right, thank you so much, Mercedes!

00:27:10.640 Thank you, thank you, thank you! That was a really fantastic talk! Huge applause!

00:27:17.440 As she said, friends, head on over to the corresponding Slack channel for this talk.

00:27:22.080 If you have more questions, she’ll be available there to answer those.

00:27:28.200 And, of course, commute amongst yourselves.

00:27:35.200 Shortly, we're going to be diving into a talk with Nick Means, so look forward to that.

00:27:44.000 Again, thank you, Mercedes! We really do appreciate it. Thank you to all of you, and we’ll see you next time.