 Hi, everyone. How are y'all doing? I just said y'all. Good. Awesome. So we're really excited to be here. Thank you for having us. We're going to really build on a lot of the stuff that Erica was talking about, so we're super excited about that. Yeah. So today our talk is called Becoming Amid, and it was cool to see. We actually couldn't really see because we were sitting in the front row, so we couldn't see how many people kind of classified themselves as mid-level developers. But yeah, so we're going to talk about our two perspectives on leveling up. I'm Kinsey. I work at Go Spot Check with Kim, and I'm super into doing outdoorsy things, hanging out with my dog, fly fishing, traveling. I also get to travel around a lot and teach code to young women in developing countries, which is super cool. I work with Sarah Allen on Cambridge Foundry stuff, and I also mentor for a program called Block. Yeah. Kim? Cool. Yeah, I'm Kim Barnes. My friends, hopefully, affectionately refer to me sometimes as a salty dog because I've been doing this a while, and sometimes I'll use words or tools people haven't heard of. In fact, when Dave was talking about the 1200 Bod Modem, I brought a 300 Bod Modem and an Apple II plus to college when I went. You are old. I actually got into programming through my dad, who I'm really grateful to. He assigned programming assignments when I was a kid, and based on the difficulty of the assignment he gave me and the grade he gave me, said how many games I could play of sneakers or space invaders. That was kind of fun. I have a couple of passions, like TDD, pair programming. I raised my hand when Erica asked that. My amazing kids who are both in college right now. Horses, dog training, and there's me trying to coach my first coaching attempt to get this pony to pull my little sister. It's really cool because Kinsey and I are on the same team right now, so we're in this opportunity to have these roles right now where I'm mentoring her and she's hopefully learning from me, although apparently she thinks I'm really old. I do, but that means you have more to teach me. Like we both said, we're software engineers that go spot check, although Kim has a fancy senior title that I don't have, but I will one day. We're about 75 people downtown Denver. We're a block away from Turing. We are hiring mobile developers and product owners. We were recently voted the best place to work and we just love working at Go Spot Check, so sorry if we come off too. Gosh, you about it. At some point we just love it there. This is a picture of us at our company retreat a couple months ago, last month in Vail, which was super fun. Yeah. Yeah, when Kinsey and I were planning this talk, we really struggled with words to use and I think words are important. So we initially said we want to help juniors level up to mid and we want seniors to know how to mentor them, but then when we were talking we realized this can apply to a lot of people, whether you consider yourself junior, mid's kind of really fuzzy, so what does that mean? So we're really hoping that you find something that fits for you no matter what title you have or what word you use. Yeah, we didn't want to use the word junior, but it's hard. I wanted to use like Padawan for you, I'm not a big Star Wars fan, but... What was the one you were going to... Oh, Minyan, I heard Dave call him. Yeah, so we were trying to come up with different words, but we're just going to be, I don't know, using these ones. Right, so we kind of came up with six areas we wanted to cover. Like we said, it's going to really build an Erica's talk, which is great because we're kind of in the trenches talking about this. Technical learning, domain knowledge where you're really getting into the software you're working on, mentoring, the relationship between juniors and mentors, pairing versus soloing, and some more specific soft skills. So first we want to talk about technical learning. Yeah, and one thing I guess we want to point out is we don't, because BotChuck, we don't have a formal apprenticeship program. I know kind of very few companies do. I think it's awesome that Detroit Labs has that. So we have had to improvise and kind of do this on our own without an apprenticeship program, which I think is a case for a lot of companies. You have senior developers and now a lot of junior developers and it's important to bring the junior up to actually become more of a mid-level developer. Yeah, so we're first going to talk about technical learning. The first thing I want to say is for juniors, I think it's really important to teach. Put yourself in teaching situations. And I know a lot of people are kind of hesitant to do that because you're like, hey, I'm a junior. What can I teach someone? And you can actually teach a lot. You know, mentor someone who's been programming for two days. Try to teach your parents or your younger brother what you're doing. I found that having to teach something really forced me to learn something and showed me where I had all kinds of holes in my knowledge. So you can do that also like volunteer for a RailsBridge program and help mentor that way. So I really think this quote is awesome, the best way to learn is to teach. Also do side projects. You know, outside of work, find something that you're passionate about, whether it's building an app that you really want to build or whether it's contributing to open source. And I know there are a lot of barriers to entry around that. But you could also go to a meetup or some type of networking event or like I said, mentor other people on the side. You know, doing more things outside of work. But on the other side of that, I want to be clear that I really think it's important to take breaks and maintain your hobbies that you used to do before you started programming. A lot of times I hear Turing students say that, you know, they don't have time to work out anymore. They don't have time to go to dance class or work out class like they did before. And I think it's really important to keep doing those things. A lot of people we work with also don't take lunch breaks or take any sort of break. And I think that's a problem because you really can't step away and come at it with a fresh perspective. And also I've been doing the Pomodoro technique. I don't know, has anyone used the Pomodoro technique here? Wow, most people, that's awesome. I love that because then I get to take a break every 20 minutes and it's awesome and step away. So I really enjoy doing that. And I really enjoy doing my hobbies outside of work. Also, something that I've encountered is languages that I don't expect that I'm going to see. So my first couple days it goes spot check a couple years ago. This is one, something that I found. It was this crazy SQL function. We have a lot of these and this is only like a quarter of it. You didn't run away right away? I wanted to. I was like, oh my God, I've never seen SQL like this before. So I know that code schools aren't, online programs aren't typically teaching SQL, which I think is too bad because we use SQL so much in our day job. One-off times in the database or when we're optimizing something. Ruby just wasn't cutting it for us anymore. So for me, really digging in and having to learn SQL really helped me become more of a contributing member on my team. Also, approaching problems. Ben Horne, I think some of you guys know him. He was a Turing grad and he really helped me with this. A lot of times I would struggle and he would help me break down problems constantly into smaller bite-sized pieces and was constantly on me about that. And that really helped me get better. Also, writing pseudocode as a part of this. So in this method you can see I was writing comments of everything that I needed it to do. So, and obviously this was a red flag that I need to refactor this method because there was a bunch of stuff. I need to leave them afterwards right this time. Right? Yes, but just for the purpose of the demonstration of the pseudocode. I'll check in that comment later. Yeah, so pseudocode really helped me out too. Also, focus. This is something that Kim really helps me with. We have dogs running around constantly in our office. I have my phone on Instagram, you know, that whole thing. And Kim is constantly telling me to, you know, to focus, which is really good. Even when we were practicing for this talk, I think she confiscated my phone three times. Maybe. So yeah, really using Kim as my mentor to keep focus. And also focus on getting better. For me, I really had to set the intention. It wasn't something that I was thinking about. I was kind of just going about my day to day business writing code. And then just recently I've started being like, okay, I'm going to be a mid-level developer. What do I need to do to get there? And really working with Kim on that and setting that intention has really made a big difference. And then now I'm thinking about that every day. Also, I think time in practice is really important. I think a lot of times I had this misconception, you think that, you know, developers are really great developers because they're innately good at it. They were really good at math. They were really good at science in high school. And I definitely wasn't that person. So for me, it took realizing, hey, you really just got to put in time in practice, like every day putting one foot in front of the other and learning. I really like this quote. And Erica talked about grit a little bit too. Sandy Mets gives a really awesome talk on it. And she basically says, hey, pick up a shovel every day, go to the ditch and dig. And I think that's really inspiring to hear. Cool. Thanks, Kizzi. As far as technical learning, I wanted to talk about this idea that I got from David Madura's A Friend of Mine technical learning axes. And if you know me at all, you know I love Venkat. So I had a Venkat quote that I think applies. So as far as these technical learning axes, if you can picture this horizontal axis and this vertical one. And the horizontal one has the things you typically think of when you think of technical, like languages and frameworks. But then the horizontal are the concepts that apply across them. And they're both important. And they both need to be balanced. So I want to talk about that. First, the horizontal axis, like I said, is languages like Ruby, Rails, Backbone. And these are the important things. And these are the things. Who gets excited when they hear about a new language or a blog or a book or something? Yeah, me too. And I think that's why we do this, because we get so excited about jumping into these things. And it is important to keep up with these. You've got to stay relevant. You've got to have these languages in your resume, the job postings, say three years and JavaScript or whatever. So I don't want to minimize it, but it is kind of unwinnable. You can keep chasing the latest technology and never quite get there. And because there are so many and there's so little time to spend on them all, that the learning in each area tends to be kind of shallow. So it's important to flip this on its side occasionally. And I'm going to talk about a vertical axis, but here you'll see it's actually horizontal when I flip it. So I don't want that. The formerly vertical axis has now things like principles and like TD refactoring, design patterns. Like I said, they're transferable across all those different languages and the horizontal axis. But these are the things that can get you a job at a company in a language you've never actually learned because you have the core concepts. And it helps you go beyond simple problems with simple solutions. So like I said, they're both important and it's important to balance them, but what's really cool is that they build off each other. The more you learn about foundational concepts, the more you can apply them to different languages and analyze them with those ideas. And the more languages you pick up, the more you see how the concepts are common across them. And what I find interesting is when I sit with a developer, maybe I'm mentoring or pairing and we're having conversations about design trade-offs, I can tell where they are on the vertical axis by what language they're using. There's like a language development where you use words like cohesion and coupling properly and talk about design patterns and these trade-offs and that's really cool. So speaking of balance and we want to transition from technical learning to domain knowledge, I have, this is actually both of Erica's talk too. She was talking about asking questions. I want to encourage people to ask what they think are stupid questions. So who has a lot of trouble asking a stupid question in a meeting or something where you think everybody should know the answer and you start off and right away you're like, we're in a planning meeting and there's a phrase up there and I don't even know what it means. Well, you have to ask the questions because, and sometimes I'll preface it with, this is like a really stupid question but I don't know what that word means. But think about the reason that you're there is because people just provide value and if you don't understand it, you're not going to provide a lot of value. So you need to ask the questions but what's really cool, and Erica said this too which is I think awesome, is that when you start asking those questions people start trusting you, that you're going to speak up if you don't understand and if they don't hear from you then you're following along great. So here are some examples of what does that phrase mean what screen are we talking about if we're in planning meeting. Absolutely, so I agree with Kim that this is super important. So Echo Spa Check we work with a lot of our customers are in the alcohol bev industry and I did not know anything about the alcohol bev industry. It's totally crazy. So I've got, we've gotten to go on field trips at Echo Spa Check where we go and actually pretend to be the reps at the company and learn about all that and it's been super awesome because we get to go to liquor stores and bars all day and hang out on our field trip. That's how we do all day. So it's been really fun to put myself in the shoes of the user and the customer which is something I hadn't done before. Also I've sat in a ton of customer meetings and sales calls on a regular basis and especially when I first started. So I think it's really important you know to be proactive about engaging with customers. You know a lot of companies might not offer that like hey go try to do this be the user that sort of thing but speak up say you want to do it about learning the domain that you're working in and always remember the end user when you're writing code and I think that'll make you a much more effective developer you know moving forward rather than just technical horsepower more to offer. And now we're going to talk a little bit about what we feel makes a good mentor and you know we're going to be touching on some similar things that Erica did but my first I guess piece of advice and my number one thing is don't be an asshole. I've worked with a mentor that has you know made me cry or told me that I wasn't smart enough to do it or how do I not know the answer to that that sort of thing or oh that was a dumb question so I think avoiding any sort of language like that is really important. Also body language I can pick up on people's body language when they're mentoring me and I can tell when they're really annoyed with me and don't want to be there so I think that is also an important thing to keep in mind but also when you're mentoring I've been mentoring students recently as well and I've had to explain a concept five times six times and I find myself getting oops sorry really frustrated and I think it's important as a mentor to not let that show. If you're feeling frustrated take a break and walk away because if you're that frustrated imagine how frustrated the mentee is in that situation I don't think you've ever gotten frustrated with me. Yeah I've been frustrated. See she does see do what she does. She pretends she puts on a good show for me. She goes to the bathroom she always has to go to the bathroom I've old and I have bladder problems apparently. Exactly I get it now I get it Also I think it's huge to teach in metaphors. This is something that's really helped me so for a while I was struggling with the concept of the this keyword in JavaScript I'm like I don't get this at all so the only way that I was able to have that light bulb moment was this kicking the ball analogy and like different players and that sort of thing so as much as you can I feel like we're laid it back to a real world problem a real world metaphor because that you know really helped me as far as getting certain technical concepts Also think about the bigger picture a lot of times I feel like I was only judged based on my technical knowledge and I really think it's important to look at the whole person and the whole developer and what else they can contribute and Erika touched on this a little bit about you know being that support person Kim she's my emotional support she helps me when I have things in my personal life I kind of go to her for everything but at the same time she's a hard ass with me and when I'm not doing what I'm supposed to be doing she tells me and I know it and so I really like having that support of Kim but at the same time she pushes me constantly to be a better developer and I think it's essential to have that in I don't know one person as your mentor also remember that juniors can teach you things too don't treat them as your subordinate they can teach you cool new Ruby mind shortcuts or something like that and always just be open to learning from them as well cool yeah as Erika was saying I want to emphasize that good senior developer even a really great one isn't necessarily a good mentor right out of the bat maybe they are, maybe they have that innate skill but it does take practice part of what I think is important to remember is that it's not just and this is exactly what Erika was saying coding in advanced level and going there that's how it works you know that's no fun and that's not really teaching so you want to come down to figure out what the holes are explain things in the way that work for them like Kinsey said metaphors work really well for her but other people might like concrete examples so figure out where the holes are help fill them in and explain them in the right way also no one to step in and when to step out so how many people work in a pairing how many people who work in a pairing environment okay and how many are solo all the time okay cool so if you're in a solo environment a lot of the time then you probably want to be really focused on when to step away let them have a little time of themselves come back and check on them and if you're in a solo environment you want to make sure that you're checking on people more often so they don't get frustrated because you want to find that balance between stretching and growing and struggling with problems so they learn it better but also not being too much of a safety net so I read this article this month's Prague Prague by Peter Jang about what is teachable code I modified from his but on the on your left here is kind of a more basic way to teach the code and then on the right is maybe what you ramp up to more an OO or more advanced level but the idea here is I've heard that maybe you've got a development team that has a majority of junior developers and you want to write the code at kind of the lowest common denominator level so that anyone can come in and pick it up but I don't think that's I think that's doing a disservice to the developers of the code base so Peter introduces his idea of teachable code where you can take this advanced code base and you can extract out temporary variables giving them meaningful names maybe an inject into a simple for loop and they can see step by step it's kind of procedural they can see how it's built up but don't just stop there once they understand that turn it into the code that they're going to see in the wild, they're going to be expected to write and what's cool is you can go both ways and get down to explain or you can write it kind of in a more procedural way than ramp it up this has been huge, Kim's been doing this with me and it makes a huge difference I love this cool, that's great feedback so we're going to talk more about the relationship between juniors mentors or mentees and mentors or padawans or minions what's the padawan and master? Jedi? Jedi Jedi, okay I forgot, this is still me, right? Speaking of feedback I'm purple it's really important to give and ask for feedback no matter which role you're in so for example, I'll ask for feedback on my coaching and actually me here who I've mentored he gave me some really great feedback recently some examples I got and I don't know if me here said this or not but I got one piece of feedback that I was too nice so I think what meant to me was that I was spending too much time worrying about how I said things and hurting someone's feelings and not everyone needs that and I think it can come off as condescending if you're like Kinsey, just give it to me straight, I just want to know the meat also some feedback I got that I try to apply is to try to get you and your pair on the same page before you start a task, so that's good also it's important to stay humble as a mentor, you're still learning and teaching is a great way to learn like Kinsey was saying in fact, the first person I ever mentored she asked me a question that I'm kind of embarrassed to admit I didn't know the answer but I didn't know what the word map meant, like why the function was named map and so when she asked me this I had the opportunity to go look it up and learn the mathematical basis and don't anyone quiz me on it but it did that's common knowledge but it did really help me understand what the function did and remember it wasn't just like oh that's what it does, it was now meaningful to me so that was really cool, that inspired you know, passion in what I was doing also when someone asks you a question you don't know, it's really important to admit you don't know because you have a great opportunity to model how you figure things out and that can help with imposter syndrome too because we are not expected to know everything all the time, we have to figure things out problem solving is a key skill for us to learn you want to share on relationships? cool, yes yeah so I think it's important to have structure and priority around it like I said at Gosbatchek we don't have a formal program of anything so really for us it was establishing having one-on-one meetings and making it a priority and setting this goal between Kim and I between the mentor and the mentee and also I think it's important to find the right environment where you can have this at a company so one of our values at Gosbatchek is go to bed smarter and I really love that because I know I'm in a environment where my learning is a priority and I really really appreciate that also I would say don't tolerate bullshit be proactive about what you want I know I've been in situations before where I didn't really speak up and say anything and get the resources that I needed so I wish I had been more proactive about that in the past, a lot of times it's not handed to you go out and create that situation and say that's what you want work with someone who wants to be a coach kind of what we've been talking about this whole time also I think it's really important to set concrete goals say okay I want to be a mid-level developer figure out what that means in your organization and kind of what happens when that like do I get a pay raise or do I get to take on more responsibility and work with someone on tangible steps that you can do to actually achieve that, I think is huge and now we're going to talk a little bit about pairing versus soloing we pair most of the time looks like a lot of people here do too which is cool, a lot of hands raised so for me the biggest thing was my confidence to drive more a lot of times I was in situations like Erica described where I was just sitting there saying nothing, just trying to absorb all the information and obviously I wasn't getting that much out of that pairing situation so Kim has really helped me with that I would be in the bathroom going to the bathroom and she would be telling me hey you need to tell you need to tell McKinley that you need to drive more and it was all the time she was bugging me about it so she bugged me enough to where now I actually have the confidence to drive more and I'm really glad that she did that because now I get so much more out of the pairing situations I'm in and it's really also helped me with imposter syndrome and having more of a voice on my team and I do think it's important to have the right amount of time of soloing versus pairing before I was pairing full time after talking to Kim and realizing this I have days where I solo on my own so that I can struggle and figure out problems on my own without having a more senior developer there to hold my hand through everything also something that Pivotal has helped us with we engaged with them a couple months ago was an actual pairing retro so I would have a retro perspective on just my pairing ability and pairing relationship so nothing technical or anything like that but just how I could be a better pair which has been hugely helpful in making those relationships more productive as well Yeah Kinsey was talking about finding make sure you have some time for soloing I think a great thing to do is to pair them with code reviews because then you have a safety net to make sure you're not submitting some critical I saw those comments I don't think you took those out I don't know but it's not just for a safety net it's a great opportunity to have a discussion and if I'm coming back to Kinsey after she soloed for a while apparently from the bathroom I need to remember that I don't have all the context of what she was looking at when she went through what problems she ran into what her tests were telling her so I got to make sure that I remember that I don't have all the context and ask questions also I can suggest well you implement it this way have you thought about this way what would be the pros and cons also something that I think is kind of important to remember is that I might look at the code and it might not be the way I would have written it but if they're two equally valid ways there's no reason it has to be my way right sometime okay who has tried ping-pong pairing cool cool so if you're not familiar with it it's basically just taking turns I'm going to write a failing spec she's going to make it green we're going to talk about refactoring and then she's going to do the same for me I think this is a great way to pair people of disparate levels because it really keeps the drive time a lot more even and as a mentor you have or a senior developer you have a good opportunity to show an example of how something might be done and all those little refactoring opportunities are great too something I got to do recently with somebody at work was using a chess timer as a pairing clock which was really cool and I would use it real strict to say that you have to drive this long and it's my turn but it was kind of a quick feedback to say oh I've been driving ten minutes longer than you so let's take a turn here it's important to keep your pair engaged so I think a good way to do this is if you know Kinsey is about to write a failing spec or she's written a test and we're about to run it to say well what do we expect the failure to be and it's just great to do by yourself too to help you read the test failures and expectations and then you know if it doesn't do what you thought discuss surprises the other really cool thing is that if Kinsey's written something I don't quite understand why she's written that but I don't know how to ask her if she tells me well I expect it to do this then I have a little bit of insight into what she's thinking and how I can come down to the level of her misunderstanding to explain it I'm sorry I said it that way so don't be an asshole also what I kind of coached navigation is to say okay we finished this task where do you think we should go next and help engage them more in the navigation process so I think we're going to switch gears a little bit here talk about some more specific soft skills is our last topic for example time management is important developers are like famous infamous for being horrible at estimating how long you're going to take I'm going to be 80% done for like the next week or two more minutes and I think agile helps with this as opposed to waterfall I don't know maybe I'm the only one who knows worked in waterfall whether you broadcast the estimates or not which I don't think is always a good idea but it's really important if you can get better at estimating how long you take to do something and the Pomodoro technique Kinsey mentioned looked like a lot of you had familiarity with is great too because you can write down an estimate of how long something takes how close you were maybe you find patterns like I'm always forgetting about that one step and this one thing is always a surprise and that way you can help manage your time better by getting better at that also avoid multitasking right Kinsey one thing at a time the most important thing at a time hopefully if you have to juggle a lot of different things try to make sure you're working on at least some definition of done on something before you put it down because it's kind of a disservice to yourself if you just drop it, check something else up and then you don't know how to go back and pick that up cleanly finally go spot checks do the company wide book club on getting things done which is a great great book for managing can this label makers everywhere file folders like it's insane I kind of want to create these staples it's true emotional intelligence is like this huge broad area but what I want to focus on was we can't just be antisocial programmers talking only to the computer especially if you're doing agile there's a lot more collaboration or if you're doing pairing, a lot more communication so you have to work on these things empathy is pretty important and that's just understanding where the other person is coming from whether it's the junior you're mentoring or your pair that day or the product owner bringing you more requirements or the QA person trying to tell you there's a bug when you know it's working just the way it's supposed to be empathy is not about agreeing with them necessarily but really try to understand where they're coming from but what's interesting is that once you really try to understand where they're coming from you might find that you're questioning your opinion a little bit because you have a little bit more of an open mind more saskos can do yeah thank you so we're in Denver so I'm going to put like a hippie woo woo slide in here just as I have to, obligatory I think it's really important to maintain that work life balance and I really love how I feel like the tech community in Denver really does that well and you know meditating and doing stuff like that to take care of yourself outside of work I think is super super important also having self-awareness on kind of what works for you and I don't know if any of you have done like a Myers-Briggs test or a 16 personalities dot com you can take a short test or any a gram to learn how you work with others and how to I don't know tell your teammates to interact with you best has been super helpful for me on being more self-aware on this stuff also knowing how you learn best when I was first starting I was going through big textbooks and you know trying to retain information that way and that was a waste of time for me I didn't get anything from those so how I learned best was doing exorcism IO stuff and code war caught us and stuff like that actually getting in and writing code so that really helped me figuring that out also attitude that's the pleasure of having desi is my first mentor a while ago and she was the first person who told me that I was kind of a drama queen when I would get really frustrated with a with a problem I get pissed off and you know say the f-word and all this stuff so you know really realizing that and working on that has been huge and Kim has really helped me to turn that into more of a positive thing so seeing that challenge as an exciting opportunity not like oh this sucks like this why isn't this working this should be easy but an opportunity to solve an interesting problem and I think that's ultimately why we're all here and why we're all developers we love that every day we get to learn new things and we get to be challenged and it's awesome and I think networking is hugely important I haven't gotten a job by sending a resume anywhere and I think that it's important for leveling up even you know as a senior developer I recently had an article on LinkedIn that talked about how the key for women to break the glass ceiling in the workplace was to network more but I think that goes across the board for everyone just really being good at this and putting yourself out there and meeting new people what's really cool about Kinsey is she throws herself into anything like conference talks right away and yeah and trick me into it I did do that so I guess I'm going towards the end of our talk and we just have a couple by parting words of wisdom and basically I just want to say we have an entire influx of junior developers coming in through code schools and outreach programs which is so awesome diversity is increasing it's great but I think we need to come together as a Ruby community and work together on really training these junior developers that are entering the workforce to be mid level developers, senior level developers that will ultimately become managers or the Jedi the Jedi's plural Jedi I don't know the plural of that but yeah and I think it comes from good mentorship and just believing in yourself that you can do it yeah and I just want to say to juniors make sure you speak up, you ask for what you need because you're saying be aware of what you need and how you work and set some goals and make sure you're getting that and to seniors and mentors to ask for feedback say how is my coaching working for you because everybody's individual, there's no one right way and getting that feedback is the best way to learn also if you're pairing a lot and teaching a lot make sure you don't burn out either find somebody more your level to pair with occasionally or solo a little bit because otherwise it can get kind of frustrating and be resentful that you're in that role all the time also if you're in like an environment where maybe there isn't a structured mentoring position but you're interested in that whether you're a developer or somebody who at any level who thinks they can teach somebody else if somebody asks you for help instead of just going over there and finding the problem and showing them how to do it offer to pair with them on the problem or pair for a day and see how that goes so we wanted to thank a few people to David and me here for some feedback to Ben and Nathan for for helping us with all the stuff and then the entire I guess engineering team that goes botch again to all you guys for listening to us and also we're going to give this talk again at RubyConf so if anyone has any feedback for us it would be great if you'd come talk to us and do we have any time for questions two questions not six questions two questions do you guys think there's a good balance between senior and junior on your teams? as far as numbers like quantity or like a ratio like percentage I think it's such an individual question you know the more advanced the juniors are the less help they're going to need from seniors and the better a mentor a senior can be a mentor maybe the more we can do that I think in a pairing situation you might want to go for half and half I don't know do you have any ideas on that? yeah I think we're pretty we have a wide variety of skill ranges I go spot check and it's pretty cool I've seen juniors and seniors for sure what do you think our numbers are how many reach? we have so many engineers now I don't know I don't know like exact numbers I'm going to say exactly a third junior exactly a third mid and exactly a third junior that's perfect cut out the rest of that please so it's rare that I you know get a chance to like hear from somebody who's like my age yeah we'll talk in the bathroom later I've heard a lot of talk about bringing in juniors being kind of a new thing but when I started programming it was like actually normal for people to hire people who hadn't had a job before programming and every company that I knew did it and so I'd just be interested in your reflection on what you're seeing in the industry now what you saw in the industry I never had a mentor there was no such thing there was entry level jobs and the other thing we were talking about last night was that there's a lot of there's a difference in the code you're writing too when you first take a new job there's a lot more existing code base and you learn on bugs and debugging and now there's a lot of startups where you start writing code you learn to copy and paste you learn to google on stack overflow and you have that now because it's kind of more the wild west I would have loved to have a mentor as I came up because there were a lot of holes in my knowledge and I didn't know what they were and simple things like oh there's this book, there's this amazing book with this guy named Dave Thomas wrote that you really need to read, someone to tell me that that would have been cool but I think what's cool is that even now I can find somebody that I can consider a mentor because they have the knowledge they don't have we're going to do two things first we're going to give a clap for these ladies to say thank you for their talk three two one and second for Kim for her first ever conference three two one thank you