This week we cover the different forms of mentorship where we have been the mentor and the mentee. There is not a one-size-fits-all solution to mentoring. What does a successful mentoring session look like? The mentoring session is not a one way flow of information and both parties should be contributing to enhance the learning.
References
Do you have feedback about the show? Want to hear more about a specific topic or say hello? Write us at [email protected] or follow us on Twitter @developfatigue
Download MP3 (42.9 MB)Transcript
Toran Billups - 00:08 - Welcome to Developing Fatigue. I'm Toran. Today I'll be joined by my cohost, Brandon Williams and Kris Van Houten. So today we'll be talking about Mentoring Juniors. Kris Mentoring Juniors, how do we get started?
Kris Van Houten - 00:20 - Alright. Alright. So I guess first question is what are we talking about when we talk about mentorship? I'm going to add a little clarification here. You know, we talking about just, you know, exclusively, you know, deciding to choose some developer out of the ether to a kind of partner up with or sync up with on a regular basis to help grow their skills or are we also talking about um, you know, those pairing sessions when you get a message over slack or a team's whatever. Say, Hey, I got a problem. Can you sync up with me for a little bit and help me debug issues to watch those two? Or are we talking about both of those scenarios
Brandon Williams - 00:59 - Yes
Kris Van Houten - 01:03 - I had a feeling just wanted to make sure
Brandon Williams - 01:05 - So I, I've been mentored by a lot of really awesome guys. And um, at first, uh, I thought mentoring was just those parent sessions that you're talking about. It's like sitting right beside each other, shoulder to shoulder, solving a problem together. That's what mentorship was. And there's no other way to do mentorship. Um, however, as I've gone through my career, I've seen other forms of mentorship and actually I'm one of the other forms of mentorship that I've, I've been a part of and been the recipient of, was very hands off actually. So I like doing the shoulder to shoulder. That's my preferred way to do it. However, I'm, one of my other mentors kind of did it from afar. He said, hey, I'm going to let you know, you figure this out on your own and I'm going to give you guidance and say, Hey, at the end of the day I want it to look like this, go make it happen
Brandon Williams - 02:00 - And that was all he would tell me. Um, does that have to go learn about those things? I'm like, I don't know any of that. And he's like, oh, okay. So you might want to start here and here and here, go figure it out. And uh, that was very different. But that's another form of mentorship. Um, I, I think, and um, he would kind of come in and check on, check on a checkup on me and say, how you doing? Can I help? What do you have questions on? So, um, yeah, I think, you know, it's been, it's been those parent sessions right next to each other and it's also been kind of that more distant like you were describing mentorship from afar
Kris Van Houten - 02:41 - Yeah, I think I actually think about it differently from, you know, as a remote developer for the company that I worked for a lot of that, those, if you want to call it mentorship happens when, you know, we use Microsoft teams for a lot of our, uh, uh, company communication and so I'll get that message saying, Hey, I'm trying to get both this issue. Can we pair up to, to touch base on it to help figure out this problem I'm having. And so, you know, as I was preparing for this episode, I was thinking like, you know, does mentorship include those sessions or is it just me trying to level up somebody who, who's looking for some advice and mentorship? Some, uh, some guidance if you will, and so and, and I guess, yeah, I think it is adequate to think of those little one off sessions with a coworker or what have you as also opportunities to mentor even though sometimes you walk away learning something which, which is totally fine and welcome. I'm now. I guess one question that I would add on top of that is, you know, in other podcasts I've listened to and articles I've read in the past, they talk a lot about, you know, having somebody that you regularly check in with you regularly and mentor that, you know, more of a, a very beginner level developer and working with them just to kind of give back to the community. Is that something either of you guys have ever experimented with because it's not something I've ever done. I'm very beginner in this area
Toran Billups - 04:04 - A couple of years ago I had a gentlemen seek me out just in the community and he was actually looking for this true mentorship, not just, Oh, well I work with you. So I guess you're my mentor. You know, he was looking for, hey, I got laid off and I don't really know what web programming is back when I was learning it, we did COBOL, so maybe you could teach me some JavaScripts and Python. And that was actually a really interesting relationship because, you know, age wise I was actually about 15 years younger than this gentleman, but, you know, web experience wise, obviously he was coming to me for a reason. I've been doing more web technology things at that time and for him he saw that was sort of the future of employment and if he wanted to continue programming he was going to have to get good at it
Toran Billups - 04:51 - Um, so I, that's actually right around the. I was reading this really old blog post I wrote a. One of the things I always tell younger people is, you know, hey, if you want to work with me and you want to learn at work, that's great. We work together obviously, but I would encourage you to find a mentor and actually seek out someone outside of work. Uh, work is so different, right? You have all these selection bias. And things that, hey, I worked with this person, this is how we code, this must be right. But I've had plenty of mentors at work that would not have been my mentor if I had chosen them outside of work. It was just happenstance, right? I happened to be at work. They happen to be older than me, so I happen to think that they're my mentor. But I think you'll find if there are people with time, which is ultimately the bottleneck when you're looking outside of work with those people who I think you would choose differently than folks that you work with
Kris Van Houten - 05:45 - Sorry, go ahead, Brandon
Brandon Williams - 05:46 - Uh, I've never done that external mentorship. I've been to. I go to a lot of user groups and I'm there. It seems like, um, there's often people who are just coming into technology, they're coming to the easier for the first time in their, kind of eager for that. But I don't see, you know, I say, Hey, you know, I, I'm willing to help. Let's, uh, let's sync up type of a thing. Um, but I kind of put the onus on them because I want to see like how interested are they in doing that? So, um, you know, I've kind of asked myself out there and said, uh, you know, hey, if you, if you have some questions, feel free to, you know, hit me up on, on, uh, whatever medium you can find me on Twitter, LinkedIn or something like that. Um, have, you know, a blog series actually. So I take that back a little bit. I guess I'm just recently I had somebody reach out to me via my blog posts. They emailed me and said, I see this blog post, we're having trouble with it, can you help us? So, um, they sent me, sent me some of the examples that they're doing and I just kind of worked with them back and forth through email, which was kind of an interesting way to mentor. Um, but that, I guess that that did happen. So that kind of remote mentorship that you were talking about
Kris Van Houten - 07:04 - Yeah, I know one thing Toran. You had mentioned to me actually that I did put into practice when you and I first started working together a couple of years ago for that brief period of time was you know it if you solve a problem that you think other people were going to run into, write a quick blog post about it. That way, you know, because as believers we know what it's like to have our time be very precious because we have a lot of things to get done and we have deadlines so on so forth and so instead of having to pair up with a developer when they come across the same situation, you have a URL, you can send it to you where you go through the the problem that you found or worked through in depth and say, hey, here's a blog post and there you go
Kris Van Houten - 07:43 - And I know like the first day that we started working together I had. I had a use case and I know Ember devs might my hate this idea, but I had a use case where I needed to write an integration tests for a partial at. I never really thought about how to do that in the past and so I just sat down on it and figured it out and I was like, well dang, like that. That took some time to kind of figure out and hack through and find the best way to do that. And that's where where you had said to go ahead and write a blog post about it and not even kidding you. I think it was before that week was over, another developer had asked me like, hey, how did you do this? And I was like, oh, here's the URL for you. And I was like, you know, saves my time. He's able to go through and read through it. If he has any questions, ping me on it later. But it's like that's your instructions right there. And, and yeah. And that's, that's an excellent way. So you can kind of do a sync mentorship
Toran Billups - 08:36 - Yeah and I want to zoom in on that because kind of coming off that comment from Brandon where he said, I put the onus on them to come at me and I think that's actually something to call out here, which is that I've had successful mentorships and I've had, I think sort of miserable failures and the successful ones ultimately were. I did put some or responsibility on that person to kind of go figure out something and come back with me. So that, that comment Brandon had earlier about like, he had room to fail. He had room to learn, uh, you know, you're, you're not handholding. That's not mentorship. And I think that was one big clarification for me years ago. In fact, that's the misconception that often leads to the failed mentorships that I've had where somebody is just like, oh, well I'll just sit down with you and then I'll be a good developer in a year
Toran Billups - 09:20 - And I was just like, well, how does that happen in a year? You've got to learn a lot of things. So I remember saying like, Hey, here's a book I read. It's actually, you know, I met with this particular person, um, in, in, uh, in the flesh I guess in real life, and so I gave this person a book and said, you know, hey, here's the physical book, please read this, let's talk about it next week. And every time we would try and get back together, he had an excuse about why he couldn't read it. And about six months into this and also six months into sort of very absent and late notice cancellations, it was pretty clear to me that this person's commitment to the mentorship wasn't even what my commitment was, which is kind of weird, right? I'm actually giving my time and this person couldn't really step up and learn it
Toran Billups - 10:02 - And ultimately that was one of the failed mentorships is this person didn't want to do it. They just wanted status or they wanted a job. And I think the people I've seen successful mentorships with, they're the ones who just kept coming at me hungry to learn, but also knew when to not take too much. Um, particular, um, this younger developer that actually Kris you and I worked with, I was so blown away by his interest in vim that like I was approaching him to just hang out and talk about vim and he was the one being like, don't you have some work to do? And I was like, ah, but them, yeah. And I just loved it that he was actually, he took an interest in something I enjoyed and so I actually was more interested to make time for him and ultimately I think he found a really good balance of when to engage with me and then when to learn on his own, which is crucial
Kris Van Houten - 10:50 - I know like one practice I tend to do is, is kind of like what you guys are saying. Well you know, let them kind of come to you. Let it be directed by, by them reaching out to you, asking for help, asking for that time. You know, it's something I try to do is if there's a, if I'm reviewing a PR and I see something that I'm just like, yeah, I think we can do better here and I'm not just gonna like drop my solution and in the comment there and be like, here's what you should do, peace out. I'm like, what I will do is like, Hey, I think we can optimize it a little bit better if you have time, uh, if you want to pursue this, just message me and we can sync up and talk for a few minutes. And that way it kind of puts it on them
Kris Van Houten - 11:29 - If they want to take my advice, they want to hear my input, cool. Otherwise, you know, I'm not going to make a big deal out of it. And I saved my time personally. So, uh, but I think those are all really good points about, you know, you are giving of yourself and so it's, it's acceptable to expect a little bit of reciprocity on there. And it's like if you give them a book, you know, if they're not going to read it, then it kind of shows you where their head's at and, and the whole situation
Toran Billups - 11:59 - Um, yeah. One question I was going to throw you guys. Sure. Because I know you guys have both done some parent. You maybe have some different opinions on pairing is the whole when you are, when you're pairing with someone who's, who's less experienced and it's sort of implied that they're learning more from you, are you, uh, the one driving or should you make sure this person is doing most of or all of the driving during that pairing session? And why or why not
Brandon Williams - 12:25 - Hm
Kris Van Houten - 12:27 - If you want to start off, Brandon, that's totally okay
Brandon Williams - 12:27 - Sure. Yeah
Kris Van Houten - 12:31 - I'm just trying to think
Brandon Williams - 12:32 - Uh, so I will, I kind of let them decide what they want to do. A lot of times I, I always feel comfortable driving and somebody very wise told me that I should be more comfortable letting them drive and letting them, giving them room to room to explore. Um, I think is his name might be Toran. But, uh, that was, that wasn't a conversation we had when he's like, hey, you know, you really, I would challenge you to do is really let them, like almost forced them to drive and force them to learn. Um, and so it was like, yeah, that's, that's probably fair because I know that's, that is how a lot of people learn is actually by doing
Kris Van Houten - 13:13 - well how many times have you gone to pair up with somebody and as they're explaining the problem, they end up finding a solution like what they call it, the rubber document that I think is what it's called. I've had that happen multiple times last month alone. So I see. I think that is a good point
Brandon Williams - 13:30 - Yeah, I think, I think it does help to just come over and just be like, oh, okay, what are you working on? And if they say, well, can you drive, be like, Oh, you know, uh, my machine, I think I rebooted it or something and give them some lame excuse. No, but I think, uh, something that Toran said that I'm really resonating with right now is kind of give them room to fail. So pairing with them and having them drive gives them the room to fail in a safe way and just be like, oh, okay, that's all right. And just and you know, nonchalantly and just like that's expected. Like errors are expected all the time. I make errors all the time. They're gonna, you know, who are your parents going to make errors
Toran Billups - 14:06 - Way, way, way you make you make a Arizona time. I wanted to drill in. I want to drill in here on the perfection complex because I think a lot of us on the call have probably have this where, you know, when I'm pairing with someone, I have this, this thing on my shoulder that's like, well, it make sure you don't make a mistake because you know, this person thinks you're, this person thinks you're perfect. You couldn't possibly make a mistake. Do you guys have any of this perfectionism complex working when you're pairing with someone and trying to show them
Kris Van Houten - 14:36 - Definitely. It's one of the things that makes me more hesitant to pair up and there's a couple other reasons why I hesitate to do that, but, but yeah, it's one thing that I've actually had multiple people I think tour and you're actually one of them in the past as well, who said like, yeah, like, like knock that off, you know, I'm one of those guys who wrestles with imposture syndrome that's typically called and uh, you know, feel like, oh, if, if someone who's, you know, less experienced than me comes to me for help and I can't solve a problem that must means that I suck and I shouldn't be here, you know? And I wrestled that constantly. Um, and I think that's something where we need to check ourselves on a regular basis to be like, I think it also comes from a place of pride quite honestly
Kris Van Houten - 15:21 - And, and, and arrogance. It's like, well, we can't be wrong or we can't not know what is that going to do to our reputation? What, what's gonna be the, uh, the optics of my position at this company. If I can't solve this, whatever don't problem. And it's something that, like I said, I, I wrestled with a lot, I had to battle a lot and it's just something that I had to check myself with constantly just asked, is this a pride thing, am I not willing to make myself look vulnerable in the situation? Um, but, but yeah, I'm totally with you. I wrestled that pretty, pretty harshly
Brandon Williams - 16:00 - Yeah, I think it really depends who I'm working with at the time. A great example today I was working with somebody and we're building up a docker file trying to build this image and I think every single line in there was wrong at one poin
Toran Billups - 16:00 - every single line
Brandon Williams - 16:20 - And here I am, I'm at work. I'm one of the more experienced people with docker and he's brand new to docker and he's watching me kind of fumble through this and it's, you know, I don't, I don't know what he thought of that, but I'm like, well, you know, oh yeah, I see. I see my air now. And so it was like, oh, well that's, you know, we're going to fix this with this, so we'll quickly fix it. His machine was running kind of slow, so we'd quickly fix that and then let it run again and I and then I go back and explain like, that failed because of this reason and we're fixing it by doing this and that's how this all works together and so like as we're working through that process, I'm explaining each step so that I feel like he understands it and so we can have that common ground there
Kris Van Houten - 17:02 - See if you can turn that around. Now, the reason I did this was to show you you can't. Yeah
Toran Billups - 17:10 - Yeah. All seriousness though, actually I think that's what we need to do better is show the real side. It'd be raw about failure and that is part of learning and I think the problem is this. Perfection is complex. I was talking about comes out of me thinking the really great programmers are perfect, you know, they never miss a semi colon or they never do every single file wrong and docker, you know, like these. We need to understand that these things are normal to feel safe in that environment. I think that's what Brandon just hit on it a couple minutes ago, which is that room to fail, but also you know some grace from your pair partner, whether you're the senior person in the junior person to be like, that's cool, we're, we're both learning this together. It's something brand new to us. Even if some of the tech is not new to you, maybe the context or maybe some piece of it that you have not yet seen is brand new and you have to look at it. Maybe you have to source dive, which we've talked about on the show as well. Source diving is is something that just exposing people to, yeah, this isn't magic. There's this thing called source code and I go read it and you can join me like that. That can be mentoring it's simplest form, s
Brandon Williams - 18:18 - in, in operations and systems and the room to fail is really important and so I don't know if. I don't know if I'm terming coining this term right now or I'm sure somebody else has already coined this term, but operations hazing, so. Oh, I like it as we've hired on some, some more junior guys. I'm actually told him after this happened, I said, you know, I was kinda waiting for you to make that, that non fatal mistake, like kind of a big air, but it was a nonfatal environment is just in our testing environment. And so after he did that, he's like, Oh man, I can't believe I did that. That was, that was really bad. I was like, yeah, but it wasn't production. And so I, I told him, I was like, I was waiting for you to make this mistake and now here's your production credentials. Now you understand the gravity of what we can do because with great power comes great responsibility like we have, we have the keys to the kingdom and you can really, you can really mess some stuff up. And so just giving like, you know, I kind of gave him this rope is like, keep going, keep going. Oh, there it is. You know, I don't worry, I've got you. You fell off the cliff, but I'm right here for you man. And I pull him back up. I'm like, that was okay, like we're goo
Toran Billups - 19:27 - and actually I like that because what you were describing is another point that I think we have to call out when you are pairing with someone in that one on one or shoulder surfing mode is trying to call out like let's get feedback sooner. Like we're not going to work on this for six hours and then go run the program. You know, like there should be some more pressure from the other person to be like, Hey, have you tried this? Have you written a test? Have you run a test, have you, you know, visually checked it out and if it CSS in the browser, like if you're going to write CSS for six hours and then go look at it, it's definitely going to be wrong. I mean for one in CSS, but you know what I mean
Kris Van Houten - 20:06 - But you can't just write css blindly and just making it look perfect the first time
Toran Billups - 20:11 - I know who I'm talking t
Kris Van Houten - 20:15 - I feel like on this topic, like I said previously, this is one area that I feel I really suck at quite honestly, and I think a lot of it is quite a bit self inflicted because I know when people like I'd probably get, especially right now because we're coming up against a pretty big deadline for the release of the product that I'm currently working on and I'm probably getting requests to pair up with people two or three times a day at this point and like, and every time just like, I don't want to do this, I don't want it to get pulled away and work on this. And in part of that, as I was thinking about in preparing for this episode, what those reasons were like why, why am I like that
Kris Van Houten - 21:00 - Why is that my initial reaction? And I think first one, probably the top one is because I'm already heads down, are neck deep in it and a problem already digging into. And so if I just switch over and go work with somebody else, like that totally pulls me out of that context. Um, but I think what's also challenging is that as soon as I start that call with that, with that individual, I noticed that I'm having a hard time focusing because my head is still in that other chunk of code that I was just looking at in my own problem. And so, you know, just how like deep work can take a while to get into it can also take a while to get out because it's just, it's on the forefront of your mind. Um, you know. So I think that was one reason why I tend to hesitate and accepting people's requests to pair up for something
Kris Van Houten - 21:47 - You know, sometimes it's also a, they're asking me to help them debug a problem in his chunk of application that I'm not familiar with or have or it's changed so much since I last looked at it that I'm not sure if I can actually give them counsel. Um, and also sometimes the person asking for help, uh, does a less than desirable job communicating the thing that they're trying to solve. You know, I've literally had people just to send me random lines from a test and saying, why is this failing? And I'm like, I don't even know what you're trying to test. Where is this final located? Where's this test located? What code is even related to a. and I know like, so I noticed like, well, it just seems like I'm getting frustrated with things that I can be a better communicator at a or I can do better communication with these individuals when these times come and, you know, I can ask the person, hey, can we pair up in an hour
Kris Van Houten - 22:39 - I'm already in something right now. Can we, can you pair up in an hour? Um, you know, ask them to summarize the problem that they're coming up against and in their own words, because sometimes like we've already mentioned, sometimes they're able to solve the problem that way. This by trying to describe it, uh, you know, and if they are asking for a pairing session, I just, sometimes it gets kind of frustrating because they start jumping around a file and you're trying to read the code that's on the screen and they're like, but then this fall, I'm like, wait, nope, go back and ask them to push up the coast so you can pull it down on your machine and you can kind of, while they're looking at one thing, you'd be looking at a nursery code to try to follow along with what's going on. Um, I think lastly, just like, like we've already alluded to is be honest, you know, you don't have to know every answer to every problem
Kris Van Houten - 23:21 - You know, I had, I've been digging into a problem the last week on, on why we're having some major performance issues in our application. And then there's other developer basically came in and solved it within a couple hours because in part because he was already pretty familiar with the code that was causing the problem. And here I was digging in a totally different part of the code base to try to solve it and he's like, nope, it's way over here. It's way over here buddy. And, and that was super helpful, but I'm just like, oh, I should have known that. But it's like, no, we can't do everything. Yeah, I think we need to constantly be checking our pride, check our humility and understand it. No one knows everything. Um
Toran Billups - 24:00 - that's where I wanted to actually wrap up, which is a, let's say from this episode. Of course you take the great advice of the panel here and you become an excellent mentor and be prepared for what you were describing Chris a minute ago, which I call lovingly The Curse of the Great Mentor, which is that when you're a great teacher educator, you're very kind. People are going to come to you more often and that's good actually, that I would consider it like a first world problem that you have. You have become very good at it. Maybe someone even call it the human side of programming. And the second you unlock that, you've got to find ways, like you mentioned, to sort of mitigate your time getting sucked away. One of those is the blog posts, like you called out, so you helped someone once. Great, I'm the second person asks you think I need to probably blog this or find a way to get this in a guest at least
Toran Billups - 24:52 - Um, and then other other ways to eventually just be really kind to people like you were calling out, which is give them a little more time rubber duck themselves because you can't, you're not going to drop everything in a moment's notice and go help them. And I think that's one thing I would caution here is with people who want a mentor either outside of work, sort of the long game mentoring that we talked about, or even people that want the short, you know, quick help me out, Chris, at work, both of those really have to be on your timetable and people have to respect that. And ultimately if they don't, guess what, you didn't have time to mentor them anyway. And if they do, they respect it. They read the books or they come to you in an hour or two when you have time that, that shows that they have some respect for what you bring and in, you know, as a result you can give them some of that time and hopefully the real win of the great mentor is that you're actually growing other great mentors. The problem is the amount of time that takes as you know, the return on investment issue. So
Kris Van Houten - 25:48 - Yeah. Really fast. I think that's actually really powerful that yeah, you mentioned that because you know, there, there are some developers who come to me more often than others and there are some developers. Were they, when they ask for me personally to pair up, I was like, oh, I don't have time for this. I wouldn't want a pair. But I think that just speaks to like, it's gotten to a point in our relationship as coworkers, as you know, partners in code that they trust me, they trust my input, they respect my input. And I was like, oh, that's actually really cool to think about in that light and think that, you know, and, and that way they respect me and so, um, or at least value my input. So I think that's something I can definitely take to heart and just what you were saying there. So thanks
Toran Billups - 26:29 - Cool. Um, do you guys have anything else before we jump into some big wins
Kris Van Houten - 26:35 - I think that's it for me, man
Brandon Williams - 26:35 - I'm good
Toran Billups - 26:38 - Cool. Uh, so I'll kick off the big win week have been back into some open source stuff that haven't touched in a bit. Uh, I mentioned a couple episodes back that I was doing a lot more rapid prototyping for work and it turns out a rapid prototyping actually involves html. Funny enough, right? If you're doing web, uh, web development prototyping. And one of the things that a product actually or a project I wrote back in like 2016 for myself but really did not use much is this a hot reloader for Ember. And so as obviously I work in ember during the day and I'm doing these prototypes in Ember, I sort of revived to some degree this hot reloader, um, as a tool to just literally helped me build apps faster, helped me build prototypes faster. And I was kind of cool actually, I did a demo for my entire team, a bunch of Ember dose, um, because one of the things I noticed is that, you know, ultimately we need this feedback loop optimized for experimentation and learning
Toran Billups - 27:42 - I always talk about that. Like I want to get faster feedback even faster. I want subsecond rebuilds, I want subsecond refreshes and hot reloading is just an extension of that where I want the second I'm saving this file in vim for it to be instantly visible on the right in, in chrome. And that was the experience I had. It was actually kind of cool and I shared it and I'm sort of revived. I have this new energy to make the hot reload are great. In fact, I've got to working in the latest, like Ember 3.2 Beta. And I've also got it working with reducers as well, so I plan to do some kind of cool demos where I show the developer experience because I actually don't think, at least in this particular niche, like the Ember community, that people are really aware of the hot reloading workflow where you're actually maybe in a really deep nested part of the ui that would, that would incur a full page refresh if you're just using traditional live reload and hot reload is just such a different experience and I would love to show that off. So I'm reenergized as you guys can tell. So Brandon, Brandon, what's your big wins
Brandon Williams - 28:39 - I started learning a new tool. It's been a long time since I've actually, uh, just on the side, um, for fun, but also a little bit for work. Just learning something new again, like a new, a new tool or a new programming language or whatever it is. But I'm just learning the tool Terraform from HashiCorp. And so I'm just seeing what that, what that can do for me and the stuff that I work on
Toran Billups - 28:39 - Very cool
Kris Van Houten - 29:09 - Um, my big one is, is something noncoding elated because my life has been consumed with a current release that we're working on and also moving across the country. So my big one is that you made it into our new house finally in Waxhaw, North Carolina. Yeah. So Joe from Durango to Austin, which is not on the way to Charlotte by the way. And I had to do that and this isn't a 26 foot moving truck, mind you so that I'm not comfortable driving and had to park that at a hotel so I can go to two of mandatory agile training for my employer saw unlike like agile certified or whatever that means. And so from there I drove from Austin to Charlotte which was like an 18 or a 20 hour drive with only like four or five hours of sleep in between. So I was pretty tired when I got here, like at 3:30 in the morning. But we're finding in our house, it's awesome. It's pretty cool being here. It's really pretty and beautiful and green. Uh, so yeah, we're loving it so far. Just trying to get moved into the house and uh, I guess that's, that's my big one right now. Hopefully next time I'll have something more keyboard coder they did
Toran Billups - 30:18 - So that's a huge wind man. Well, thanks so much guys for joining me today and, uh, I guess we'll catch you all in a few week
Brandon Williams - 30:18 - later guys
Kris Van Houten - 30:18 - Thank you
Toran Billups - 30:18 - See you