Podcasts about codenewbies

I invited on 3 graduates to share their experience with Treehouse's Front End Web Development Techdegree. In my opinion, Treehouse was always great at teaching the fundamentals. We dove into this in great detail. An important question came up though - does it do a good job at teaching more than just the basics and prepare graduates for professional developer positions? We talked about this as well. Enjoy!Host/Guests:Don Hansen - https://www.linkedin.com/in/donthedeveloperClinton Hays - https://www.linkedin.com/in/clintonhaysSilvia Ramos Expósito - https://www.linkedin.com/in/silvia-ramos-expositoWhitley Bone - https://www.linkedin.com/in/whitleybone-----------------Support me on Patreon ❤️ and get exclusive mentorship from me:https://www.patreon.com/donthedeveloper

In this episode, I’ll teach you the difference between synchronous and asynchronous. Quite some Codenewbies and junior developer find these terms very confusing. So check this episode if you want to learn about it!

A lot of Codenewbies tend to do a lot of usemy courses, tutorials but are wo dering why they can’t connect the dots at some time. Well that is because a lot of you are doing the course and not building websites or applications. If you start doing that, that will help you grow a lot harder then you can imagine

Guest: Saron Yitbarek: @saronyitbarek | bloggytoons | CodeNewbie | @CodeNewbies In this episode, Charles and Sam talk to Saron Yitbarek about her idea of mentorship, ideas for distributed learning for businesses to promote individual and company growth, and why it's important to take "digital sabbaths" on the regular. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: SAM: Hey, everyone. Welcome to Episode 110 of The Frontside Podcast. My name is Sam Keathley. I'm a developer here at the Frontside and I will be your episode host. Today, we're here with Saron Yitbarek, discussing mentoring. She is the founder of CodeNewbie and the host of the CodeNewbie Podcast. Also with me as a co-host is Charles Lowell, who is also a developer at Frontside. Welcome Saron and welcome Charles. How are you guys doing? SARON: Thanks for having me. I'm doing pretty well. CHARLES: Hello. SAM: Today is going to be an interesting take on the mentoring talk. I mostly want to know first off, Saron, how do you feel about mentoring? What are your opinions on the mentor-mentee relationship or the value there? SARON: Yeah. I have lots of opinions on this topic. I think that the traditional structure of mentorship was usually looks like someone with less experience going to someone who has a lot more experience and say, "Will you be my mentor?" kind of like the children's book, 'Are You My Mother?' like 'Are you my mentor?' and then that person, that mother figure, that mentor looks after them and checks in on them and they have regular coffees and lunches and kind of steers them in the right, usually career-related direction. I don't think that's very realistic, to be honest. I think about why that might be. There's many different reasons. I think the fact that we're so, so, so networked and there's just so many different ways to get in contact with people and build relationships is a big reason but I think that that traditional mentorship model, that kind of one directional way of doing things is just not really needed and kind of overrated. I think that mentorship nowadays looks more like a mutually beneficial relationship, where I might reach out to someone who has more experience than me, for example in drawing, in art, not something I want to get to do but I know a crap-ton about podcasting, so I help you, you're my mentor in this specific area, in this specific topic but then, I get to be a mentor in this other thing that I'm really good at. I think it's those types of very focused topic-oriented, ideally two-way relationships that are more accurate and frankly, a more effective way of doing mentorship. SAM: Yeah, I actually agree with that. I am pretty new myself to development, only really been in this career for about a year now and I always kind of consider that mentoring relationship as a regression back to school days, where you have these -- SARON: Yeah, yeah. SAM: -- considered superior over you in some way, well, that's really not true in this community of developers and no matter where you are in development, it's all about working together and pairing. Working here has really showed me that value in paring, rather than like I have to look up to someone and regress back to feeling like a teenager in high school, like this person so good at this thing and they're the only one who can teach me. I definitely share that view of mentoring. I went to a boot camp one day when they were telling you like, "Oh, you got to find a mentor. You got to find a mentor," and I was like, "Well, but why? Why do [inaudible] together?" SARON: It's also a huge responsibility, a huge burden on the mentor too. Having to be, in a lot of ways, responsible for someone's career and trajectory and direction, that's a big responsibility. We don't have time for that, you know? On both ends, whether it's feeling like you're back in school or feeling like you have this huge responsibility, I think the traditional model isn't really the best model for either party. I think this idea of let's all learn together, let's be really focused on topics and problems that are very particular to what I'm doing, what I'm learning, what I'm trying to do. I think that works out. It feels healthier for both people. SAM: Absolutely. CHARLES: I wonder also too, it seems like it might be a little bit of a throwback to the days when people would spend 30 years in a single company or 30, 35 years in a single career where you have these people who are really these reservoirs of this intense tribal knowledge. It seems like people move around a lot more in their careers, not only in the company that they work for but also in the things that they're literally doing. I might be podcasting one day and producing a bunch of content and then, I might move into music or writing or other things like that. The careers seem to be broken apart a little bit more is one of the reasons why older models of advancement in those careers might not be as good a fit as they once were. SARON: Yes, absolutely. I'm obviously very biased because I'm in tech but when you think about the different roles that people have in tech, I feel like we're always wearing so many different hats. We have to, obviously code and be technical in that sense but we have to be really good communicators, a lot of us are speakers, we host podcasts, we organize conferences, we go to meetups, we're bloggers, we do so many other things, that this idea of, "I'm going to have a mentor who can help me in my role of being a developer," is just too big. You kind of meet people who are good at those individual pieces and those individual skills to get me to where I want to go. SAM: The whole idea of mentoring to me always reminded me of that whole Mr Miyagi relationship where you have this master of something and you're trying to learn from them. But in software development, I've learned that really no one is a master of anything because it's just changing so much and everything is so different. SARON: Yup, absolutely. CHARLES: The question is obviously, it seems like the idea that you're going to find one person who's going to represent the ideal confluence of every single skill set that you could hope to want, to be at some point in your career. That's looking more and more ludicrous. Is there a model where you can try and distribute those things, where you single out a large range of individuals? I guess the kind of what you were hinting at the beginning is that it is a lot more broken up, a lot more distributed but how do you pursue that, even if it is in a distributed manner? SARON: Yeah, that's a great question. One of the moments where I realize that the distributed model is really the only way that makes sense is, I think it was three years ago maybe. We thought about doing some kind of mentorship program in CodeNewbies, some type of way for people to link up and find people who can be there and guide in a way and we had people fill out this survey that basically said what do you want out of a mentor, what do you look for, what do you hope for to achieve but also asked how do you see yourself. Do you see yourself as a mentor, a mentee or both? It was really surprising that most people checked off both, which I thought was so interesting. It was so interesting to me that the same people who said, "I need help," with the same people who also said, "I also have help to give," and to me, that was such an amazing moment because I said, "Wow, it really isn't about this idea of I am the guide and I'm going to guide you." It's really about, "I have information expertise in one area and not in others." What I realize is there really isn't a mentor model. I think it's more of a culture of being helpful, which probably sounds really cheesy but it's true. I really think it's about saying, "I know how to do a thing. I'm going to go on Stack Overflow and answer questions. I'm going to go on Twitter and answer questions. I'm going to write blog post and share with the world." I think the real model, the real distributed mentoring model is us as individuals saying, "I just learned how to do a thing," or, "I just figured out how to do a thing well. Let me capture that. Let me capture it in a response, in an answer, in a forum, in a post and let me share that," and the more we do that as individuals, the more we have this huge amazing aggregate of knowledge that can serve as mentorship for all of us. SAM: I like the touch on that. That's kind of the idea behind Codeland Conference, where everybody thought they might be new to development and everyone is just sharing their knowledge. You might feel you really knew about it but you know a lot more than you think you do and you could still help. SARON: Yup, exactly and that's the whole idea, even the Twitter chats. When we first started, I don't have all the answers, I don't claim to, I don't really want that responsibility but I know there are a lot of people who do and I know a lot of people who have resources and opinions and who can help out. One thing that people do is they'll DM us and say, "I'm having a hard time with this." Sometimes, it's a very technical problems. Sometimes, it's a general 'I'm having a hard time getting a job,' which I do like high level question and I never answer them. I always say, "Tweet us and we'll retweet it and we'll get the whole community involved and we can have a rich conversation around it," and that's really been our motto, our philosophy. I see what they do with mentorship. If you have a mentor, you're not obligated, I guess to listen to them but the idea is kind of that you should. There is one person and you should listen to them because they know more than you. I think that's just not really fair and instead, I like to think that there are lots of different ways to do things and it's up to you to decide what's best for you and in order for you to decide, you have to have a lot of options. With Codeland, with the Twitter chats, no matter what skill level you're at, no matter how confident you feel in your coding abilities, you do have something to offer. Let's pull that out. Let's put it on the table and let's see who you can help today. SAM: That's a perfect way of introducing someone to the idea of helping or getting help from a community, rather than an individual because you never want to take one person's word as gospel on something you just know nothing about. SARON: Yeah, exactly. SAM: You can sound confident talking about something and it can be the total wrong answer but if you're seen as someone superior or someone who knows what they're doing -- SARON: And you can sell it. SAM: Yeah. You can be the best snake oil salesman in the world. SARON: Absolutely. For the CodeNewbie podcast, we do short questions at the end of each episode and one of the questions -- my favorite question -- is what's the worst advice you've ever received. I love that question because I started by saying, I think that people love giving advice. I think people love asking for advice and the assumption again is if I give you advice, then I probably know more and you should probably listen to me but that's not always true. I want people to be comfortable making their own decisions and deciding for themselves. "This may sound like it could work and this may sound like a good idea, generally speaking, but for me, it's probably not a good fit. It's probably not what's best for me," and to be comfortable rejecting advice and that was kind of the reason why I started that question, it's my favorite question and it's so interesting how much advice is good. It's kind of generic but it's a good advice. It's an advice like, "Don't quit. Keep going," which maybe a good idea and maybe you do need to quit, so being open to rejecting advice, I think is really important and that one of my favorite questions. SAM: In your experience, what is the best way to reject advice? Because when you're a new developer, when you're new at anything and you're seeking advice from a community or from a person, you don't want to come off as rude or maybe you're feeling... I don't know, not very confident but you think the advice that you were given is just bad advice. What would your advice be? I guess, what would your advice be on this advice? For your perspective, what would be a good advice to reject advice that you think is just wrong? SARON: Number one is when I ask people for advice, I try to think about and try to know upfront, do they have the same values that I do? Do they have the same worldview? Do they have the same goals? Because that's the thing too. Oh, my God, I got so much unsolicited advice. It's amazing. I've actually stopped just saying to people my ideas or what's on my mind because I know as soon as I say, "I'm thinking about this," I'll get a whole slew of unsolicited advice and I'm like, "I didn't ask for that." What I've learned is first to kind of figure out are we even on the same page because if my goal is to be a developer, if your goal is to be -- the only thing I could think of is a juggler, I don't know why -- a juggler and I ask you for a career advice, I'm going to go ahead and safely assume that what you have to say is probably not as applicable to me and so, number one is kind of identifying that. But number two is if they say something that just I know is not going to work or I've already tried, I'll just nod and say, "Thank you very much," and kind of go about my day. I don't think you have to declare whether or not you going to take it. I think just acknowledging and I think the people that give advice, I think they're trying to be helpful, they have good intentions, usually. Usually it's, "I'm trying to save you from making mistakes that I made and I'm trying to help you get to learn a little faster." I always appreciate it but knowing that I can say, "Thank you. Thank you for your time. Thank you for your perspective," but know that I don't have to go off [inaudible]. SAM: That's actually very similar to my tactic. Just not like, "Thank you. Thank you so much. Don't talk to me ever again." No. SARON: And disappear, yeah. SAM: I'm like the wind. With this pressure that either new developers or seasoned veterans are feeling about the mentor relationship, because I feel like a lot of senior developers that I've spoken with or people who've been in the business for a long time, feel like they should be mentoring or they need to take on that responsibility but there's always that hint of dread in their voice when they say about like, "Oh, I should be doing this." I always feel like it's okay to not do that. I never really understood why it was so high value to have this one-on-one relationship with an individual when you're not in school because it just feels so like... Not childish but childish. SARON: Yeah, that's one of things, frankly that I love about the tech community and also do not understand about the tech community. It's such a giving knowledge sharing community, whether you do it in a tactful way or not in a tactful way but the idea of giving back and paying it forward is just so deep. It's so, so deep that even when I've been coding for only a couple of months, I still felt this, I don't want to call pressure because pressure kind of sounds a little negative but I definitely felt this expectation that I was supposed to be blogging, supposed to be sharing and shouting and helping and doing these pay it forward type things. I don't really know where that comes from. Maybe that comes from the culture of open source, maybe that's where it kind of penetrate. I'm not sure but there's this huge need, desire, idea that we're supposed to be giving back and for that, I am very, very, very grateful. But I think that acknowledging that if you're someone who wants to be a mentor that you can do it simply by being available, literally being available, the going to be hashtag is super, super active even when we're not doing our Twitter chats and people use it to ask for help, they used it to ask questions. If you're feeling particularly giving or extra helpful that day, go on Twitter and check the hashtag and see what questions people are asking. Things like that or just super helpful and don't require a huge amount of time and effort. There's a lot of small ways to help out. That may not seem like a big deal to you but for the person who's asking for help, who has been banging their head against the wall, it's hugely valuable. SAM: Yeah, absolutely. Up until I went to my first conference this year, I didn't realize how supportive and important Twitter is. You know I always kind of considered it to be like another social media platform that I don't understand because I'm 84 years old and I just don't get it. It's been so uniquely helpful and in ways like Stack Overflow or even issues in GitHub, it just aren't. You can get so many more perspectives, so many different perspectives from people. SARON: Yeah, absolutely. Twitter has been amazing exactly for that. It's just an efficient way to crowdsource opinions and crowdsource perspectives and when you get your question answered and someone else answers it, it doesn't only benefit you the way it would if you email someone but it benefits anyone else who comes across that page, so yeah, it's hugely valuable. CHARLES: I remember the first moment I had kind of like that, a light bulb went off in my head where I was working on some really weird project that was using some strange wiki for its content storage and I was getting frustrated and I just tweeted about it and then the CTO of that company just immediately answered my question and I was like, "What?" You know, it was years ago and definitely, I was like, sound of explosion, that is where my mind exploded. I was not seeking help. I was just literally being kind of a jerk and venting frustration and lo and behold, the answer for my problem descended from the Twitter clouds. It was incredible. SARON: The Twitter clouds are the best clouds, usually CHARLES: Twitter is very... What's the word? It's very split down in the middle. SARON: Noodie? Yeah, there you go. SAM: There's this live feedback, so there's no buffer of emotion there, you know? SARON: Yeah. SAM: It's like, "Oh, this thing that you said, it made me mad. I'm going to tell you about it right now." Charles, I know that you had mentioned before that you think mentoring would be a good idea for Frontside and then, after all this discussion, have your views stayed the same? What are you feeling about that? CHARLES: As kind of the person who's like the grizzled veteran in the software world, it's definitely something that I've kind of whipped myself over the back. It's like feeling like it's something that we should do but I think it comes from the idea that people come here and we want to make sure that they're getting access to the learning that they need and the ways, in which they can level themselves up that they need, that's the kind of the prime motivator there. I always perceived mentorship as some vehicle through which to achieve that. It's something that I've heard. Obviously, we don't have a mentorship program at our company. It's something I felt that we should always be investigating. I've always felt maybe a little bit bad that we didn't have it but it's also something that I really struggled with in my career because I can't really say that I've ever had a mentor, so I don't really know what that relationship would look like but I do have a lot of people that I learned a lot of critical things from. I can look at it as kind of these seminal moments in my career, where like light bulbs went off and a lot of the time, they're associated with an individual and that individual and the thing that they taught me or multiple things that they taught me, are still with me. I have those experiences, which have been phenomenal and critical to my development as a software developer, so I guess it's just part and parcel of that impulse that you're describing to pay it forward, to realize that when you walked into the building, the lights were on and the walls were standing and the air was at a comfortable climate temperature. As you live there, you realize that there are people involved in actually, doing that maintenance and providing the building for you and the space for you to become aware of your world and then, when new people walk into the building, you want to provide them the same experience that you had. I guess that's my take on. That's the kind of thing that I would want to provide, so the question is like what does mentoring or mentoring 3.0, as we're maybe talking about in this conversation, how does that fit into that? How would you implement something like this, some sort of distributed learning in a company? I don't know. Maybe, it's not worthwhile. Maybe it is. SAM: I think it focuses more on that pair programming because when you're thinking back and you have all these people, like you have names of people that taught you something, it's multiple names. It's not just this one guy taught me all of these things. Actually, within a company, that mentoring just comes from pairing with your coworkers, seeing what different hats everybody wears and then, trying them on every now and again but not necessarily taking that individual's word as gospel, you know? CHARLES: Right and hopefully, that's not something that we've advocated for. Maybe, it's how do you introduce structure around that, to make sure that the proper ferment is happening, so that you have novel pairings and make sure the ideas that are flowing are flowing around the entire company and not just through certain set channels. SARON: Yeah. The other part of that is if you create structure around what it looks like to share outside. You know, pair programming is interesting because it's kind of one-on-one and it's hopefully, I have something important or bright to say in our pairing session. Maybe, I don't. Maybe I'm having a dull day. Maybe, I'm having a bad day but this really give you the same opportunity to take a moment and say, "What do I know? What do I want to share? What do I want to put together?" It does really give you a chance to prepare and gather yourself. It's kind of in the moment. I think having another opportunity where you can gather yourself is important and so, that might look like brown bag lunches, where everyone takes a turn and has to do a little lightning talk. That's usually the opportunity to say, "I have five minutes. I'm going to share something." Everyone has a turn, which means that the company's literally saying everyone has something to say. It's only five minutes, only a few minutes, so hopefully it won't be too terrifying if you're not big on public speaking and it's your co-worker so hopefully, it won't be terrifying because it's people you know and not total strangers. You know, a format like that, where there's structure but the company is saying, "We're going to give you time to think about what you're good at and what you know and to share that is good." I think another way to do that is by setting time aside for blogging. If your company can say, "Thirty minutes out of the week, we're going to take some time to write down five things I learned, to write down one cool thing I learned, post it publicly, post it internally about this expectation that everyone should be writing, everyone should be sharing, which also says everyone has something to share." I think those are two ideas and two ways that we can create a culture of sharing and a culture of distributed mentorship, where everyone has an opportunity to find the thing that they're excited about and specific ways to share it. SAM: Yeah, that's excellent. CHARLES: I hope you're grinning as much as I am, Sam because at least in the first half, you basically described our Lunch and Learn process. It's a little bit more than five minutes but I think another thing that clicked for me there is making sure that having a variation of expectations of quality or something like that because I feel like where we do really well is in the Lunch and Learn thing. We have a process very similar to what you describe but where we're not so good is maybe with blogging. I wonder if part of that is we just hold ourselves to such a high standard of what it is. The idea that we could throw together a blog post in 30 minutes, I love that idea but it means you really have to be willing to just say, "You know what? We're going to get it out there and we're going to make it bite-sized and the expectation is that we're not going to be writing some gigantic essay that's going to shake the industry to its core every Friday at three o'clock." There are things and if we can, I shouldn't say a reduction in quality but maybe a reduction in scope so that you can say like, "We're going to carve out 30 minutes or an hour and we're going to pick a topic that scope-appropriately for that." SARON: Absolutely and I think that knowing that you only have 30 minutes or maybe it's an hour -- an hour is probably a little bit more realistic -- but knowing that you only have an hour also forces scope. You can't write a book about JavaScript in an hour. You just can't, so the fact that by the end of that hour, you have to have something to turn in is a great way to force people to focus and do something really small and really bite-sized. The other thing is I don't think that after the hour, you need to publish it publicly. It could be, you need to turn it into someone else, to edit and look over for you and give you feedback. It's not quite ready yet but it's a solid first draft and the ideas that after that first person edits it, then it's on its way to being published. I think there's different ways to manage a scope without also making this scary thing where I have to say something for the Earth to shake. There's different things that we can do around that. CHARLES: I'm wondering what other forms of sharing that we can fit into our workday. I guess, the other baseline is just making sure that you're always... What is it? ABT -- always be tweeting. It's so easy to be write-only, not even engaging conversations but just throwing ideas out into the void. SAM: I think holding a discussion with your coworkers like if you're in an environment where you can work face to face or are constantly online, if you're more of a remote worker, I think just having a conversation with anybody, rather than just putting your idea out there, putting it out there with someone who can actually provide real time feedback in a more friendly way, then I think some people on Twitter could be. Because they're your coworkers and they're not going to call you rude names, you know? CHARLES: Right and you're also going to know, hopefully the whole trust and intent and 'are we on the same page?' that question is answered even before the text is written. SAM: Right. SARON: Yeah, absolutely and with those conversations, this actually mean [inaudible] that we do. We do like a show and tell every week and the idea is that we're both always learning random things, usually related things but sometimes, totally random but still very interesting and it will take 30 minutes to just share what we've learned. Sometimes, they'll also turn it into a blog post. Sometimes, it's just a knowledge sharing opportunity. I'm not really sure but it's a good window of opportunity to say, "We are learning and we're sharing and we have something of value to bring." The great thing about something like a show and tell is that it doesn't necessarily have to come from my brain. It doesn't have to be like, "I have a great idea that I'm going to share." It could be, "I read about this cool idea." It can be, "I heard about this cool thing that we can try and we can apply," but I still kind of credit, you know? Like I get credit for being the value bringer but the burden isn't on me every week to come up with the idea. That's a nice balance, to kind of create space to share and to promote this knowledge share and if it comes from you, it's great but if not, you're still helping other people. CHARLES: I have a question that may or may not be related in here. This has just kind of occurred to me because this is definitely something that I experienced, where I get into a mode where I become overwhelmed by the ideas that people are sharing and so, what's the balance? Because usually, we're out there searching for ideas and we're searching for novel things so that we can include them in our work, in the things that we want to do and accomplish, whether be that in tech or elsewhere. What's the balance of being heads down and being like, "You know what? I'm going to be closed to new ideas right now." Because they can be distracting, right? The [inaudible], that's actually a phenomenon and so, how do you protect yourself from sharing? What's the balance? SARON: My solution was to move to San Diego. That was my solution to that. I actually moved from New Jersey and I worked in New York City... How long has it been? Was it only been a year? Oh, my goodness, and now, I'm in San Diego and it was so interesting because that ended up being a really nice side effect. I didn't move specifically for that reason but when you are commuting in New York City every single day, there's so much going on all the time. There's just so many ideas and events and meet ups and companies and people. It's just so much. I think that it was a great place to be in my early 20s when I really just wanted to soak up everyone else's ideas and I didn't really have opinions of my own at that point and it's a great way to just kind of absorb and be this awesome sponge in the big city but after a while, I kind of realized, maybe I have my own ideas and my own thoughts, so moving to San Diego, which is a much, much, much quieter place, has been a really great way to reflect and sit with my own thoughts and feelings and opinions and just kind of focus on that. I understand that everyone can move to San Diego, although I highly recommend it but I think in that way of carving out like... What do they call it? Do they call it a tech sabbath? A digital sabbath? Am I saying that right? CHARLES: Yeah. Maybe. It sounds about right. SARON: Yeah. I came across that term recently but this idea of one day out of the week, I'm not going to be on the interweb. I'll just not going to do it. Maybe, even the whole weekend, oh, my goodness and saying, "I'm just going to stay away from things. I'm just going to create a little space for me to think and reflect." I think when I don't have the whole day and what I need is just like a moment, I find that writing things down is a great way -- a really, really good way of doing it -- even if I'm taking notes or from doing a strategy session or if I'm trying to make a decision. Usually, I'll start typing and what I've started to do recently is to say, "I'm not going to type. I'm going to plot in a notebook and I'm just going to write things down," and because writing is slower than typing, it forces you to just think. It forces you to be alone with your thoughts, for better or worse and it forces you to really just to think about what you're doing or what you're saying and reflect. It's a really, really great meditative exercise that I found. You know, finding little ways to build in an escape from the noise, ideally on a regular basis, I think is a really healthy thing to do. SAM: Yeah, I definitely agree with that. My normal method of sort of closing everybody off is I just sketch out ideas because I'm an artist. I come from that sort of perspective as I can make a drawing out of feelings more so than I can write them out. If I'm feeling really overwhelmed or if I'm trying to make sense of some information that people have given me, I just sketch it out and I think that's something that doesn't really get talked about a lot in the whole community because sometimes it's always about eat, breathe, live, code, you know? We have different skills. You have other things that you're good at that's not just code. When I was at React Rally, a lot of people were in the music and then finding a way to separate yourself from the entirety of it is definitely one of the better ways to make sense of your situation. SARON: Yup, absolutely. CHARLES: Yeah. Sleep? It's a great way to take a break. SARON: Sleep is so good. SAM: On my top three things: sleep. CHARLES: Yeah. SARON: Yeah. As a kid, I never ever thought I would look forward to my bedtime ever. You know, it's my favorite part of the day. CHARLES: Yeah but like sleep, writing, drawing, I always forget. Like when I'm caught up in a problem, I always forget that engaging in some other activity -- I like to walk in the place next to my house. I like to play my ukulele. Engaging in those activities is almost on the critical path to solving the problem and I always forget it. I think we always forget it but sometimes, you can be so frustrated and you can just shut it off, be completely alone and there is some magical process that's probably going on in your brain. I don't know exactly what it is but you come back and the answer is just sitting there, waiting practically on your desk. SARON: Absolutely. One thing, we recently moved a couple of weeks ago to a new place and it's a little bit bigger and so, I had the opportunity to unpack boxes and buy furniture that we didn't really need before or just trying to make it more of a home. I've been using it as a really great opportunity to be productive and to feel productive but not be in front of a screen. Sometimes, I even like save tasks for myself like, "I'm going to wait till the evening to put together this shelf because I'm going to need a moment to just be away from my computer." I have a plan around it so it ended up being such that, I think about every day, there's one little home activity thing that I can do, whether it's cleaning or cooking or assembly or movie or something with the home, that allows me to, because I'm not really a hobby person. I don't really do hobbies because it just feels, like no judgment on people who do. I know people get really into their hobbies but it just feels like, "Why?" You know, like, "Why?" like, "For what?" But when I put a shelf together, it's like, "I'm going to use this for books." You know what I mean? Like you're very purposeful, so home activities has been my way of carving out that space away from the screen but also feeling like I'm doing something productive, I'm getting things done. SAM: Something that I would recommend to anybody who doesn't really have that, I'm going to step away from the computer and do this thing. Something that's kind of helping me was the Pomodoro Technique, which if you're not familiar with that, it's basically a time management thing where you set your timer for work like for 25 minutes, 30 minutes or whatever and then, when the timer goes off, you take an allotted break for five minutes, 10 minutes, just so you're not doing the thing that you've been doing for the last 30 minutes. SARON: Yes, absolutely. That's a great one. SAM: My advice is to implement that if you don't have a thing, that you use for your cleaner, I guess. SARON: Oh, you want to hear some really terrible but effective advice? SAM: Yes. SARON: And this is what I found out very accidentally is if you have a really, really crappy office chair that hurts -- CHARLES: Oh, man. I'm sitting in one right now. It's literally a rocking chair from the 1800s. SARON: That sounds awesome. CHARLES: Yeah, it does sounds awesome. SARON: But if you have a crappy office chair, that can be a really great way to get away from your screen because after about an hour, your thighs will hurt and your back will hurt and you will be forced to get up and walk around. It's so funny because I have a pretty crappy office chair and my back has been hurting for so long and I just thought, "That's life." That's like my [inaudible] for myself. I'm like, "That's just how life is, my backs hurt," and then it got to a point where I was like, "I need to go and talk to someone," and as soon after that, I spoke to a conference and I was basically up and down away from any type of chair for like four or five days straight and magically, my back pain went away and I was, "Oh, my God. It's that freaking chair," and ever since I realized it, I started noticing it. I would sit down and I would go, "I'm nearing the one- Oh, there are my thighs. There they go. They're in pain." There's another great cheap life hack: get a crappy chair, after about an hour, everything will hurt. You will be forced to go do some jumping jacks for about five, 10 minutes and there's your additional sabbath. There you go. SAM: In Charles' case, probably a haunted office chair. Yeah, that's an excellent advice. I never really noticed that. Now, I'm going to. CHARLES: You know what funny is, I actually didn't even notice it but I do. I never used to get up and go on walks before or spend as much of the day standing as I do and I'm actually completely and totally oblivious to it but I think, I realize like I can attribute a lot of that to the terribly, uncomfortable chair, in which I sit on every day. SARON: I have this awesome habit of sitting cross-legged, which apparently is a very, very bad idea, my physical therapist told me, so I make it worse for myself. If you don't feel like you have enough screen time, just sit cross-legged and that will accelerate the pain process. SAM: As you said that, I am currently sitting cross-legged in my desk chair. SARON: Yeah! SAM: That's just how I sit in chairs. My legs are too short to reach the floor. SARON: Me too. I just find it so comfortable. I don't know and I'm so happy to hear that you also do this because I'm like, "Am I just weird?" because I love sitting cross-legged. It's so comfortable. It makes me really happy. SAM: No, I verified 100%, that's how I sit in all chairs. SARON: Yeah, the same. CHARLES: I can do one leg. SARON: Only one? Man, you need to work on that. SAM: -- [inaudible]. That's going to be the end of our podcast. Again, thank you Saron for coming on and having this awesome conversation about mentoring. Definitely check out the website CodeNewbie.org. We are the Frontside. We build software that you can stick a future on. Hit us up if you're looking for help building your next big thing and also, hit us up on Twitter. Hit Charles, myself, Frontside and Saron on Twitter. SARON: Thank you so much for having me. This is awesome. This is fun. SAM: Also, I want to give another thanks to Mandy, our producer for producing this lovely episode and all of our episodes. If you have any questions for us, hit us up on Twitter. Any ideas for future topics, any thoughts you have on this great conversation, let us know and we'll talk to you all later.

Technical Speaking With Saron Yitbarek TableXI is offering training for developers and product teams! For more info, email workshops@tablexi.com. Summary Presenting a technical talk can be an important part of a developer's career. In this episode, we're talking about how to perform a technical talk with Saron Yitbarek. Saron runs the CodeNewbie Podcast, and others, and organizes and coaches speakers for the Codeland Conference. Saron and I both have some thoughts and opinions about how to deliver a good technical talk. This episode has a lot of tips about how to prepare, what to do at the start of a talk, how to engage the audience, and why emoji are better for slides than videos? We'll give advice on how to give the talk that only you can give and how to get the best performance that you can. Guest Saron Yitbarek (https://twitter.com/saronyitbarek): Web (http://bloggytoons.com), Podcaster: CodeNewbie (https://twitter.com/CodeNewbies), Base.cs Podcast (https://www.codenewbie.org/basecs), Command Line Heroes (https://www.redhat.com/en/command-line-heroes). Notes 01:46 - Saron’s Public Speaking Experience Prior to RailsConf 2014 Reading Code Good by Saron Yitbarek (https://www.youtube.com/watch?v=mW_xKGUKLpk) 03:02 - The Performance of a Technical Talk Transitions: The easiest way to improve your tech talk (https://medium.com/@saronyitbarek/transitions-the-easiest-way-to-improve-your-tech-talk-ebe4d40a3257) OSCON Talk: Ask More Questions (https://www.oreilly.com/ideas/ask-more-questions) 06:50 - Should you memorize or wing your talk? Deckset (https://www.deckset.com/) 11:58 - Knowing Your Audience Jen Simmons: It's Never Been A Better Time to Learn Layout CSS (https://speakerdeck.com/jensimmons/its-never-been-a-better-time-to-learn-layout-css) 21:20 - Designing Slides 28:17 - Talk Beginnings and Endings 37:11 - Practicing and Delivering Your Talk 40:43 - Moving Physicality and Talking Speed 46:45 - Giving The Talk No One Else Can Give Related Episodes Organizing Technical Conferences (http://www.techdoneright.io/39) Conference Speaking and Diverse Perspectives with Carina C. Zona and Mark Yoon (http://www.techdoneright.io/9) Special Guest: Saron Yitbarek.

For people learning to code, feeling alone on their learning journey can be one of the biggest challenges. Join Saron Yitbarek, the founder of the CodeNewbies community to learn about how emerging developers are getting together to support each other on their journey. Learn more about CodeNewbies, learning to code and creating your own supportive communities.

Today we’re talking to Saron Yitbarek of Codenewbies. She’s here to talk about how she started the Codenewbies community and Codeland. We also talk about weightlifting, bootcamps, and her podcast setup on this show. So, stick around! CodeNewbie Saron I don't belong in tech Shure Microphone Codeland Conf Mattie Rogers

Descripcion del programa Inés y Rosario decidieron unir sus conocimientos para formar Adalab, con el principal objetivo de ayudar a mujeres jóvenes con dificultades laborales a introducirse en el mercado laboral dentro del sector digital. Con un intensivo de 3 meses Adalab forma a chicas sin conocimientos en programación, en Frontends para que puedan optar a un puesto laboral dentro del mundo del desarrollo web. Adalab nos parece una iniciativa social muy buena para combatir la diversidad laboral y animar a chicas a introducirse en el mundo de la programación. ¡Esperamos que os guste el episodio! Recomendaciones Preguntas rápidas: Adalab: Rosario e Inés Quién me ha inspirado: Mariana Costa Checa Recomiéndanos un recurso: Be my travel muse Recomiéndanos a una invitada: Los chicos de Laboratoria ¿Qué tema te gustaría que tratásemos?: ¿Se valora en la empresa la diversidad digital? Contacta con: Adalab: Rosario e Inés Web de Adalab Twitter de Adalab Facebook de Adalab LinkedIn de Adalab Instagram de Adalab Links del programa Women in Tech From Elon Musk to Tim Cook, tech leaders hardly follow women on Twitter Ela Conf Recomendaciones de Ignacio Naiara Abaroa Sarah Drasner Una Kravets Codenewbies Codeland Conf front girls

Saron Yitbarek: @saronyitbarek | CodeNewbie | Codeland Conference Show Notes: 00:32 - Codeland Conference and The Conference Experience 08:06 - Impostor Syndrome 15:32 - The CodeNewbie Community and Growing Junior Developers 20:06 - Dev Job Red Flags and Should-be Basic Requirements Resources: Codeland Volunteer Form The CodeNewbie Podcast Episode 60: Impostor Syndrome with Alicia Liu Alicia Liu: Overcoming Impostor Syndrome: Or How I Learned to Stop Worrying and Love Coding Alicia Liu: Impostor Syndrome Is Not Just a Confidence Problem: The dangers of becoming a buzz word CodeNewbie TwitterChat Transcript: JEFFREY: Hello everyone. This is Episode 63 of The Frontside Podcast. I'm Jeffrey Cherewaty, developer here at The Frontside. With me is Robert De Luca, also a developer at The Frontside. ROBERT: Hello, hello. JEFFREY: Our guest today is Saron Yitbarek. She's the founder of CodeNewbies and host of The CodeNewbies Podcast. Hi, Saron. SARON: Hey, how is it going? JEFFREY: Great. ROBERT: Pretty good. JEFFREY: You have a big event coming up, the Codeland Conference. Why don't you tell us a little bit about what's going on there? SARON: Yeah, I'm so excited for Codeland. It is our first CodeNewbie conference. I've done a good amount of speaking at different tech conferences all over the world for a few years now. Ever since the first one I went to, I thought, "We really need one for junior people, for folks who are just getting started," so I kept a running list of everything I hate about conferences and the things that I like about conferences. This is my chance to put it all to the test. It's a two-day conference, single-track and the idea is really to get people excited about all the things they can do with code, especially for our community. The two types of jobs we generally hear about are working in a really, really small startup or working in a really big tech company like a Microsoft or a Google. But we don't hear about working at the hospital or working at the library or the many nonprofits who need technical help. The idea is to bring in people from all different backgrounds, walks of life, solving different problems and showing how code can be a really, really great tool for that JEFFREY: What are some of the things from previous conferences that you really like that you're bringing in Codeland? SARON: I like that you started positive. That's a good start. JEFFREY: We'll go for negative later. SARON: Yeah. [Laughs] Save the best for last. The stuff that I really like about conferences is the community part. It's being able to see a bunch of Twitter avatars come to life for the first time and being able to sit and talk. I feel like conferences are the only place where I can network without feeling gross and without feeling like I'm networking. I feel like I'm genuinely having real relationships and conversations. I think it's because we are going through this experience together and I can say, "Oh, did you hear that talk on this and that? It was so cool." It's a very organic way to start a relationship. That's probably one of my favorite things about conferences. ROBERT: There's a lot of ability in there for small talk about anything because there's so much going on. You could pick anything that you want and you're all experiencing the same thing and you're all kind of vulnerable. I love conferences for that reason. SARON: Yes, exactly and a lot of times, you're in a new city for the first time, you're staying in the same hotel, you're eating the same food. There's so many created and forced points of connection there for you so you can pick anything and start a conversation. ROBERT: Yeah, I really like that. I'm looking at the website right now and I see inspiring talks and it doesn't look like they're all exactly technology specific so I like to see the city life and health. That's super interesting. I want to hear a little bit more about that. SARON: Sure. I wanted to pick topics that are generally not covered as much in tech. Also, I didn't want to start from the technology. I think that a lot of people our community are very excited about the possibilities of tech and what they can do with it. We hear a lot of stories of people who say, "You know, I see this problem in my neighborhood. I see this problem in my community. I see this problem at work and I think that code is a really great way to solve it and to put together these solutions that I have in my head." The way that we're working -- and that's another thing -- you are working very, very closely with all of our speakers and we're starting from the problem space. We're starting from the users and then we end up in a place where the technology becomes the solution. I think that when you start at that more common, human, empathetic element, I think you are much more likely to bring people in, who may not feel as comfortable with the tech because the way we've kind of organized and thought through stuff is focusing on the problems that all humans and all of us can relate to and then saying, "One way we can solve that and address that is through JavaScript or leaf letter," whatever that tool is. ROBERT: That sounds really cool. Is there going to be conference talks that are centered around like how to have proper work-life balance, for example to filling to that health or how I've configured my editor to help with... I don't know, like ergonomics for my hand because I was getting carpal tunnel on my left hand because I was using control too much, that kind of stuff. That sounds really cool. SARON: Yeah, that's actually a really good idea. That would make a really great talk but that's what Day 2 is for. The one thing that I've seen a lot in my own conference experience is I'll watch a talk, I'll listen to a talk and it'll be so inspiring and exciting. But then I go home and it's over and I'm back to my daily grind and all of that energy and positivity just kind of goes away. What we wanted to do was have that first day be focused on all these ideas and projects and the second day transition into what do we do about them. We have a block of workshops from things like crafting your portfolio, to doing really well on a technical interview so really getting your hands dirty and trying out some of those skills. Then we have handouts for people who come in and talk about how they contribute to open source. We do have one actually on work-life balance and learning to code and how you do that so making sure that we leave people with really practical advice and action items and next steps so they feel empowered to go out and be awesome developers. ROBERT: This is awesome. The conference is kind of structured almost like a workshop in a way to where like Day 1, you're going to come in and hear a bunch of things that are going to get you all riled up and inspired and then Day 2, it's like, "This is how we go and implement that." SARON: Yeah. I want to credit Duane O'Brien from PayPal who forced me to think very, very hard about the conference experience. When I first pitched him on this I said, "Hey, I want to do a conference for CodeNewbies," and I have kind of a disconnected list of topics that I wanted to talk about and do address and he said, "You really need to sit down and to think through what is the UX or the experience," like what's the user story. I go to CodeNewbie as a new developer so that I can structure it so it feels like one really cohesive experience. I sat down for many hours and really thought through, "How do I want people to feel? Where do I want them to get excited, to get to work, to be interactive and really participate?" Putting a lot of time into that has really shaped this conference. ROBERT: That is really cool. To be clear this conference is happening in April. SARON: Yep. April 21 and 22 in New York City. ROBERT: Awesome. I think this is really cool. Conferences are awesome but when it was my first conference ever, I just felt overwhelmed because you walk past the cliques of people -- I don't want to say cliques but you see the groups of people that have been there and done it and you're like, "How do I break into that?" If the conference is kind of filled with everybody like that, giving your first conference talk could be a lot easier, just like breaking into the community and talking to people could be a lot easier so I think this whole idea of running a conference for newbies is A+, honestly. SARON: Thank you. ROBERT: I wish this was around whenever I was within the very beginnings of my career. That's really cool. Is there anything, anybody on the outside can do to get involved and help like volunteer? SARON: We have a bunch of volunteer's spots to help out at the day of the conference. I'm really excited because a lot of people who've stepped up are people who aren't necessarily the right attendees. There are folks who have years of experience who just want to wait to join in and do something and help out. We have volunteer spots and I'm happy to include that in the show notes. I can send a link to that. Then we also have a section during our workshop. We have like an optional community coding session where if you don't want to do any specific workshops, you can just bring your laptop and just socialize and code and work on your own stuff. If anyone is interested in the New York City area in participating or just being like a floating, technical mentor of sorts, those are the two ways to get involve. ROBERT: That's really cool. JEFFREY: New Yorkers, get on that. ROBERT: One of the things that I hear you like to talk about and it kind of fits in perfectly with this is this Impostor Syndrome. I think this'll really help with Impostor Syndrome. One of the foundational goals for this is to help people come to grips with that and deal with it better, I guess or peel the onion back on what Impostor Syndrome is. JEFFREY: Let's start there, let's start with what is Impostor Syndrome. Why don't you give your best definition of it? SARON: Sure. I was really excited the very first time I heard about Impostor Syndrome, I think it was maybe four or five years ago and I said, "Oh, my God. That explains so much of my life," and when I really dug into it though, it was slightly different than the way that I initially understood it. The official academic definition of Impostor Syndrome is a way to describe the phenomenon where I have a lot of accomplishments, I'm ten years into my career, I have all these accolades, I'm the CTO senior or whatever of this and that, and even though I have all these very tangible, very real accomplishments and proof of how awesome I am, I have trouble internalizing that. I can't look at that and go, "Oh, I am awesome." I look at that and go, "Ah, that's cute but I'm still not quite there yet." I think that in our community, when we talk about Impostor Syndrome, that's not really what we mean. I think we are describing what happens to everyone when they're learning something for the first time where they say, "Oh, I'm not getting this as fast as I think I should. I know a little bit but I won't know nearly enough to belong." It's really the sense of belonging that we have classified as Impostor Syndrome. We actually had a guest, Alicia Liu on our podcast, I think it was about a year ago, talk about it and it was interesting because the first time that she blogged about it a few years ago, it went viral. Everyone's like, "Yeah, it's totally how I feel," and then she wrote another blog post a couple years later that said, "No, no, no, everybody. That's not what Impostor Syndrome is. You're not impostor. You're actually just a beginner, you're just new, you feel like you don't know what you're doing because you probably don't, which is fine." It's totally fine to not know what you're doing. But the definition of Impostor Syndrome for me has definitely shifted a little bit over the years. ROBERT: It's interesting that the textbook definition and what we kind of experience in the industry are at odds, in a way because the textbook words like you have this well-accomplished person that has done a lot and they don't feel like they're good enough for what they're doing. Then what we have is just like, everybody in the programming community is trying to fit in and they're always trying to learn new things and always feeling like they're not getting it fast enough. I think that's an industry-wide problem. JEFFREY: I kind of always feel like a beginner because everything's changing in our industry so fast, all the time so there's always this disconnect between, "Well, I may have done some things and I may have accomplished some things along the way but I'm still beginner whatever this new tech is," Actually, everyone else is too. It's nice to be reminded of the fact that to be around other engineers who are experiencing that too that we're all in this together and we're all new at this. Nobody is quite expert level at this particular tech stack or this particular way of thinking it. We're all figuring it out as a community. SARON: Yeah. One of my favorite talks that Scott Hanselman does is this really awesome talk about a little bit about his background in JavaScript and the evolution of JavaScript frameworks and he has this whole section where he goes through a list of this really impressive resume and all the stuff that he knows how to do and he deeply understands. But at the end of it he goes, "All of that is completely irrelevant because of Heroku." [Laughter] SARON: None of that matters. ROBERT: "Now, I need to go learn something else." SARON: Yeah, exactly. For me sitting in the audience I was like, "Yes! Heroku," because I'm thinking, "If that's how this guy feels, he's been doing it for so much longer than I have, I have a chance at this." ROBERT: I feel like I send the 'I don't know what I'm doing dog' meme to someone, at least once a week. At least. [Laughter] ROBERT: I feel this often. I think it can be interpreted to the world is changing so much. But I think it's a little different for people that are experienced in the industry versus people that feel who are brand new because, I think when you're brand new, it feels so new and I don't know... uninviting maybe for the Impostor Syndrome? Whereas you get older -- not older -- you get more experience and you become one with the Impostor Syndrome like somebody asked you to do something that you don't know and you're like, "Urgh! Yeah, sure. I'll do it. I'll figure it out somehow," and then go on your way but you still feel that feeling. But when you're a newbie, it's overwhelming almost. Do you know any tactics that kind of help that? I actually have no clue besides like pairing and trying to bring this new person into the programming world and telling them like, "This is kind of how it is." SARON: I think that community is a great way to solve that. When I first learned to code, I taught myself for a few months. I did all the free and relatively cheap online resources and it was so frustrating because it was my first time being in a world where I was in a semi-permanent state of failure until something finally worked and then I got to celebrate that for two seconds. Then we moved on to the next feature, the next bug, the next whatever. Being in this cycle, this vicious cycle of constant failure and having so little time spent, actually enjoying the wins was so different. It was really hard not to internalize that. Especially in my world where my family has no idea what coding is. They still don't really get what I do. I said, "It has something to do with computers and podcasting." My mom is actually going to come up for Codeland and I'm so excited because she can finally see what it is that I'm doing all day. ROBERT: That is awesome. SARON: Yeah. She texted me and she's like, "Yeah, let's bring your family and your friends and your dad can come," and I'm like, "Mom, that's not what this is." [Laughter] SARON: But yeah, your family doesn't really get what you're doing, your friends. If you're not coming from the tech world, if you're transitioning, they have no idea what you're doing so it's super, super lonely and it's really hard to explain. When I transitioned from that into enrolling in a boot camp and doing that for three months, all of a sudden, I had 40, 45 people who were with me every single day for eight to twelve hours at times, who knew exactly what I was going through and who understood everything that sucked about it and everything that was awesome about it. Just knowing that it wasn't me -- I was not the problem, the code was the problem and the journey is the problem -- just changed everything and that's really why I started CodeNewbie to say coding boot camps can be an awesome experience but for a lot of people, they're not accessible. It's three months at least without a job, it's between $12,000 and $17,000 and because there's not always a credit programs, you can't necessarily get like a student loan the way you can for a college. For a lot of reasons, there are really high barriers. I wanted to make it a little bit easier for people to find a support system who are going on that journey. That's what really started CodeNewbie and we did that through the CodeNewbie Twitter chats that we do every Wednesday at 9PM Eastern Time and we do that every single week for an hour, really as an excuse to say, "We're all going to hang out at this place." As long as you have an internet connection, you can join and find friends and find people who know exactly where you're going through and that's really been, for me a huge, huge help. JEFFREY: What kinds of positive experiences and stories have come out of that community? Have you seen actual great change happened through that? SARON: Yeah, definitely. We've had people get internships, we've had people get jobs, we've had people just find out that other people in their neighborhood are also learning to code. I've seen a lot of like, "I see you're in Portland. I'm in Portland too. Oh, my God." A lot of that and then they meet up in person and they pair. We've seen a lot of mentors and mentees pair up through CodeNewbie so it's just been a really great jumping off point for a lot of folks to find those connections and opportunities that run with it. JEFFREY: Through Codeland and through CodeNewbie, one of the goals is to connect junior engineers into their community. What kinds of roles and ways to connect do junior engineers have through the opportunities like this? SARON: A lot of folks are finding internships and apprenticeships and some junior roles. I think what I'm really excited for with our community is the growing number of junior positions that are popping up. If you see the list of the companies, GitHub is the one, I think of top of mine who have started creating like a hybrid coding and community roles for junior people to get their foot in the door, to start to get some real experience under their belt before going for something a little bit more coding, have a little more full time. I think at GitHub they're calling it like a... Oh, I'm going to mess it up. It's not a community manager but it's something around like a community manager position. What I really like about these hybrid roles is the fact that a lot of folks in our community who are transitioning into code have very, very valid, very awesome real world job experience. It's just not technical experience. They've done a lot of sales, they've done some design, they've done marketing, they've done a lot of community building, they've done a lot of customer service, really empathy-centric jobs and roles. With these hybrid positions, they're able to leverage that background a lot for those really awesome communication skills, while also getting a little bit more comfortable in transitioning into a more code-heavy, tech-related position. One thing that I hope happens and frankly, I think just needs to happen, given the high demand for developers is more of these hybrid roles, more of these entry-level junior developer roles. I know that there are apprenticeships and internships that have always existed for computer science degree students that are now transitioning and being a little bit more open to career transitioners as well as people who are students. I'm definitely seeing a lot of shifts in the industry and I hope to see more of that. I hope that more of these awesome people who are really just so excited and so passionate and eyes wide open and very teachable. I think it's one of the things that senior people are really excited about working with our community is knowing that we are very open to being taught, we don't have best practices, we don't have bad habits yet so we're really moldable in that way so I'm really hoping to see that trend to continue where there are more learning positions and also more full time entry-level positions in software. JEFFREY: That's excellent. I hadn't heard of many examples of the kind of hybrid role but I'm thinking back to previous job I had where there was a very large customer service department and several members of that team are like, "We want to start developing." Like they're playing around with code and there definitely could have been an opportunity for them to maybe 75% of their job is the customer service work and what they've been trained to do. Then the other part of their job is like, "Let's start leveling you up and let's start teaching you some things and giving you an opportunity to play and learn." That's an awesome opportunity. SARON: Yeah and that's the thing too is a lot of this is already happening on informal basis. I've heard definitely my fair share of stories and we've actually interviewed people in the podcast who said, "I started in customer service. I started in accounting. I started in this totally unrelated part of my company and then I raise my hand and I said, 'I want this coding stuff.' I started shadowing developers and just going to hang around the engineering team enough that they eventually let me do some documentation work or look at some bugs. Then I slowly transition into a developer position." A lot of this has been happening very organically but I think the more we can systematize it, the more we can formalize that process, the more accessible it becomes for people who just didn't know that they could raise their hand and create those opportunities for themselves. I think the more people do it and the more we can really put rules and structure around programs like that, the more we can bring more people in. ROBERT: That sounds really cool. I have a question. We know what the good situation would be for a newbie to get into. Are there any things that you could advise people that might be looking for the first dev job like anything that are red flags to avoid? SARON: There are so many red flags. That's a good one -- ROBERT: Because I wish I had this when I was starting out. SARON: Yeah. I think one of the hardest parts about being a junior person is just not knowing what it means to be a good developer. It's one of those things when senior people tweet and write blog posts and things about how incompetent they feel a lot of the times and how they feel like they just don't know enough. On the one side, it's really comforting and it's validating but on the other side, for me at least, it makes me panic a little bit because I'm thinking, "Holy crap. If you don't feel like you're good, then how would I ever be good? How would I even know what good is if I'm working towards that?" I think one of the things to look out for is a company that actually has put some thought into what it means to be a good developer? What are best practices? I know this is super subjective and a lot of times it's just based on the product of the company and the values of that space but I think for a junior developer, if you walk into a place where people are so busy running and trying to catch up or trying to keep up that they aren't able to look back and go, "Oh, you're on the right path," or "You're making progress," it's going to be, at the very least frustrating for you and worst case scenario, it'll be impossible for you to grow and really develop and progress in a way that's going to make you happy and fulfilled for your career. I think one of the red flags is -- not so much of a red flag, it's more of one of things to look out for are companies that have tech blogs, that have a podcast, that have really good documentation, that have style guides, that have a mentorship programs, that do brown bag lunches, things like that really show that the companies put a lot of thought into what they value on their engineering team and are much more likely to help you grow in your career. JEFFREY: So that it's more likely that they will have room for you to grow instead of, "Hey, we need some cheap labor." ROBERT: Yeah, exactly and that's the thing. As career transitioners, people who are not used to tech salaries, it's super easy to undervalue yourself. It's very, very easy to say, "I'm just coming from a job that paid $25,000 or $30,000 a year. Yeah, I'll take a $40,000 dev job. That's so much better than what I'm doing." It's like a 50% increase. It's really easy to sell yourself short. I think when you look at a company and see the structure and the thought they put into growth, I think they're much more likely to really invest in you, as opposed to taking advantage of the fact that you're just more than happy to be there. ROBERT: Yeah, I love that. One of the things that Brandon told me when I first started here and I was worried about failing was we didn't invest in Rob the developer, we invested in Rob the person. That was something that really stuck with me that helped like it harkens back to the Impostor Syndrome, it definitely helped with me except being that failures will happen and if I do fail, it's okay because I'm in a space that allows that. Maybe something that a newbie would look out for is software teams that have good process, not shipping broken tests to production or things like that. But also managers that are there to help you and to be there for you and take you on one-on-ones and give you good feedback. I guess, it really just boils down to having a good support structure. SARON: That's the kind of thing that can be hard to evaluate until you're actually there on the team. When you're in the interview, it's like dating. You put on your best outfit, you put on some lipstick, you get your hair done and who knows what you really look like on Wednesday night at midnight, right? [Laughter] JEFFREY: That's when I made my best. I don't know about you. [Laughter] SARON: Some questions that have really helped me out or asking how do you support more junior people. You specifically asking like, "Do you have an education stipend? Do you have a conference stipend? Do you have books? What are the perks?" A lot of times, it can be really straightforward to evaluate. How much they care about your development as a person, if you just look at the perks that they offer? I really love when there is an education thing, when there is a book thing, when they pay for you to go to conferences because that really tells me that you care, not just about getting the most out of my time with you but you really care about my development as a person, as a developer. Those are really good signs. Then I think there are things like when you brought up testing -- that was one of my basic requirements when I was interviewing a few years ago -- and was saying like, "Do you have tests? Why don't you have tests, if you don't?" I've had a lot of answers and they were like, "We didn't really see the point," or, "We just don't do that here." Those are not good reasons to not have test. ROBERT: No. Those are very bad. If you could see the faces we just made, we're like, "Ahhh! No!" Especially for a newbie jumping in, that is your safety net because you read the assertions and you can understand what the code is supposed to do. SARON: Yeah. Same thing with documentation like how much time they spend on documentation? If the answer is, "We don't do that," then the whys are what really become important. If the why is simply, "We're stretched too thin. We're trying to fix that by hiring people like you where we can now focus on documentation," that's a much better answer than, "Ahh! We just don't really need it. We don't see the point." I think when we can ask the people who are looking for jobs, when we can ask the companies more why questions and really get a sense of the way they make their decisions, I think that can be very telling in what type of environment you're getting into. JEFFREY: I add in there. One more thing for junior engineers to look for is vulnerability from future employers that they're willing to own up to their mistakes and talk about their failures. You know that you as a junior person, I also have the ability to do that. You're going to fail. It's going to happen. But if it's an accepted thing and a thing that the company knows how to deal with and talk about and embrace and turn around into successes, then that's a very good thing. All right, thanks for joining us, Saron. Everyone check out CodelandConf.com. That's coming up in April. That's all for The Frontside Podcast. Thanks for joining us.

When one man decided to crowdfund a bailout for Greece on Indiegogo (a feat that required over a billion dollars), Stella Cotton and her team found themselves in trouble. The site went down, and they had to figure out what to do. Stella takes us through the journey of getting the Indiegogo site back up, shares what she’s learned about site availability and what CodeNewbies can do to be ready for their own heavy traffic. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Apache bench REDIS Heroku Indiegogo Cache Etsy Feature Flag Latency RSpec Kaya Thomas Episode W3C Michael J. Fox Foundation Data Challenge Codeland Conf Codeland 2019

Christina started as a server administrator. But over the years, she found her way into information security, now serving as VP of Technology and Information Risk at Morgan Stanley. She talks to us about the vast world of security, why CodeNewbies should care about security even as developers, and how she’s navigated her own coding journey. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Github Server Administration General Assembly Rebecca Garcia Interview ASP.NET Visual Basic Active Directory Annyce Davis Interview Codeland Conf Codeland 2019

Una Kravets found her love of design at a young age, publishing homemade magazines complete with polls and special color editions and handing them out to her classmates. Now, she translates that love of design to code, building prototypes and design systems at IBM Design. She talks to us about her love of design and dev, how she open sourced her personal goals, and how CodeNewbies can better manage and achieve their coding goals. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Wacom tablet Action Script 2.0 Bluemix The Open Design Foundation Neopets IBM Design Open Source Personal Goals Codeland Conf Codeland 2019

When you ask Kristy Tillman about design, she doesn’t just talk about designing for a screen. She touches on space, rooms, fliers, products, both physical and digital. Her fluid, all-encompassing concept of design might be new to our CodeNewbie community, but it’s crucial for her role as Design Director for the Society of Grownups. In this episode, we talk about her design process, how she hires for design roles, and what CodeNewbies can do when designing their own products. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Society of Grown Ups IDEO Revision Path Sian Morson Digital Tools for Design Research IDEO's "Informing Our Intuition" Michael Hinricks Dribbbilisation of Everything Black Cool Codeland Conf Codeland 2019

03:08 - What’s Up with Aaron Patterson? Twitter GitHub Blog Red Hat

03:08 - What’s Up with Aaron Patterson? Twitter GitHub Blog Red Hat

03:08 - What’s Up with Aaron Patterson? Twitter GitHub Blog Red Hat