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.
