Author

About the Author
Michaela is passionate about making the life of developers and engineers better. She hosts the SE Unlocked podcasts and also researches and helps to make software engineering processes and tools better. She writes about her work on https://www.michaelagreiler.com.

Episode 36: from Bootcamp straight into a full-time dev role

In this episode, I talk to Natalie Davis. Natalie is a recent Bootcamp graduate that managed to get hired quickly after graduating. She is vividly sharing her knowledge on Twitter and started to make real waves in the dev community within just one and a half years in tech.

We talk about:

  • her experience at a developer Bootcamp, 
  • how she managed to quickly get hired after graduating,
  • how she keeps up with all the stuff she has to learn,
  • how she decides to adopt best practices,
  • and how to overcome rejections by staying positive and focusing on growth. 

Today’s episode is sponsored by ConfigCat – your favorite feature flag management tool to release more frequently with fewer risks!

Links:

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: How I got into FAANG companies without CS degree.

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Michaela: [00:00:00] Hello and welcome to the software engineering unlocked podcast. I’m your host, Dr. McKayla and today I have the pleasure to talk to Natalie Davis. Natalie just landed her first job as a software developer after recently graduating from a Bootcamp.

But before I start, I want to tell you more about ConfigCat – who is sponsoring today’s episode. ConfigCat is a feature flag management tool, and last week I integrated it with my code review analytics tool. Now, with the help of ConfigCat, I can seamlessly and effortlessly switch features on and off in my application. They provide an intuitive user interface that allows me to set rules that enable or disable the feature for example based on where the user is located, or other characteristics that I know about the user, like the company that they work for, or the date of their sign-up. The promise of ConfigCat is that everyone independent of their tech skills is up and running within 10 minutes of training and that now everyone can tap into the sheer possibilities of powerful feature flag management and A and B testing. Their tool is also GDPR compliant and they offer a super-rich free plan, so, please check them out at configcat.com.

But now, back to Natalie. Natalie is a recent bootcamp graduate that managed to get hired really quickly after her graduation. She’s vividly sharing her knowledge on Twitter and started to make real waves in the deaf community within just one and a half years in tech, I’m really excited to have her on the show and learn how she experienced being in tech, our community and what she thinks about certain technologies, software engineering practices, and especially how she organizes herself to learn everything that she has to know to position herself as a developer in 2021. So Natalie, I’m really happy that you’re here today. Welcome to my

Natalie: [00:00:54] show. Thank you for having me. I’m excited to

Michaela: [00:00:57] be here. Yeah. I’m really, really excited. So actually I saw you tweeting that, you know, I just got a job and you were really happy about it and everybody was congratulating you. And so I really wanted to know, like, how did you do it? You know, how was your job search and everything? And I know that you were a little bit hesitant to share it because you thought, well, it was so easy. Right or so quickly, uh, so quick going and that it’s maybe not typical, but over my experience, like talking with a lot of developers, there are not really typical job search. There are hard ones and long ones, and you know, some that are dragged for several months or even years. But there’s not really a typical one. And so I think it’s really interesting still to, to learn about, you know, how was that for you? Um, and also from your whole journey with intact, because I looked at your guitar in like 2019, the beginning, it was empty. And then suddenly I see like one green dot and then I see more green dots and now it’s filled with green dots all over. Right. So you’re really, really active and yeah. And now you are one, the one, one and a half months, right? Yeah. Front end developer. Right. So you have your first real job. As a developer, you’re coding for money. And so, yeah, I would really love to hear how you experienced that journey and yeah. What you learned along the way, and maybe also what you can share with others so that they can get their foot into

Natalie: [00:02:25] the door. Yeah, you’re right. When you first reached out, I was hesitant because we have to be careful with what we put out there in the world and how that impacts others. And I didn’t want anyone to see my journey and be like, Oh wow. It is super easy. Let me walk away from everything I have in life without giving it further thought. But I really appreciate that you follow back up on that conversation that we had and throughout some really good points and that there’s still some value and sharing. What helped to make me so successful. And I really have to, I know people are going to want some kind of like magical technical prep situation that I did, but I have to go back to my retail days and say that that’s really what did it for me, the skills I learned about creating relationships and networking in a natural kind of organic way. So yes, my job search itself. Like the period where I was actively sending out resumes was a very short period. But when I think about it, it started with, when I created this Twitter account that was focused on my texture. It started with, I was building along the way. And in the very early days, I definitely wasn’t sure to network for a job. I was just trying to share the fact that I was learning and my thought process was. I can share with the world when I’m learning, Hey, someone else might learn from it, but B I can make connections with people who can see the work that I’m putting in during this time period. So that when I am ready to kind of put myself out there and try to get a job, the people within my community will feel competent in saying no, I’ve seen this woman working really hard. I know the things she’s been doing. I’m willing to put myself out there and said, give her a shot.

Michaela: [00:04:13] Yeah. And actually that’s one of the success recipes that I hear over and over and over. I mean, if you go back and listen a little bit to the shows that I put out and I asked a lot of people, like, how did you get that job? How did you land that position? Right? How did you get your foot into one of the Fang companies? Right. And what it comes down to is, well, I worked, you know, to build relationships, I work to build trust that people know. You know, that person actually is doing great work. Right? And so the question is what can I do to increase my chances also? And I think having a profile, right, being reachable, being authentic, being, you know, like a public with who you are, what, you know, I think that can really help a lot. And, and you put in the work, right? So you’re there like one and a half years. And I see, I mean, you get to have, and it’s just one, it doesn’t, I mean, GitHub commits doesn’t really mean anything, but it means something, it means that, you know, you put in the work to get these green dots on one platform, at least. Right. And, and it means that you have, like, I looked at it and it was like 100 over 100 followers. Right. So people are connecting with you on the platform on a real developer platform, and they’re connecting with you on Twitter and you’re sharing and you’re, you’re in connection. Right. And so I think this is really. Yeah, really, really valuable. And what I like on your Twitter as well is that you’re, you’re sharing your journey, right? So you’re sharing while I’m looking for jobs. Now I found a job I’m graduating now, but you also sharing some of the issues. For example, I recently saw that you were saying, well, I paid off my students loans, right? So. You show people somehow also degraded you’re going and the struggles that you have with that. Can you tell me a little bit about the student loans and where they’re coming from and why you are so happy to have them, you know, Like gone now.

Natalie: [00:06:05] Sure. So about 20 years ago, I had zero interest in tech, but I was all about fashion and I enrolled in a for-profit school to study fashion design and. Unfortunately, a series of life events prevented me from completing that process. I was about maybe six months out from getting that degree when I had to kind of just leave everything in my life and move across the country. So preventing me from continuing that education. And honestly, over the years, I started to, I had my put in, in retail. I moved up there school wasn’t really on my mind until. I was no longer happy with that career path. And I decided to go back to school. So I actually, it was kind of a blessing in disguise because if this private student loan hadn’t popped up, I would have been enrolled in a university to study public policy and would have had nothing to do with tech. But I found out about this private student loan. And then I wasn’t even aware that it doesn’t show up like. I regular government backed student loan would, it was just floating out there in the Netherlands. And it actually prevented me from getting my transcripts from that for-profit school. They told me that they wouldn’t release my transcripts unless I paid that $15,000 in full. And I definitely didn’t have $15,000 in full. So at that time, I just kind of put that aside and started looking for other options to. Do a career switch. And that’s when I found out about boot camps and things like that, and wound up on this path. So I’m grateful. But once I went ahead and found my first job, I was thinking that perhaps education wasn’t over for me that maybe I’d like to learn a few more things. So I, I called up that particular private student moments in a collection agency. So I called them and asked them, would they be willing to settle? And they settled for about 90% of that student loan. So I was able to pay it off and now I can, re-enroll in a traditional educational path.

Michaela: [00:08:17] Yeah, that’s really, really cool. So I’m really happy for you to, you know, I think this is something that you are having on the back of your mind as well. Right? So it’s like something that makes you happy and you cannot, you know, you cannot go about life freely or as lightly probably. And so I can imagine that this now really feels amazing, but how, how did you come from, you know, political. Studies right to the tech bootcamp. So how did that happen? How did that transition go? And you know, like, yeah. What made the switch that you said, well, I’m going to do that. Now I’m a program. I’m a software engineer.

Natalie: [00:08:52] It started with something that I saw on Twitter. It was a few years ago and they were talking about. Baked in by us as an algorithm and how that was affecting the black community as well as other marginalized identities. And that for me, was a place where I can step in. I can be loud, I can shake tables, I can kick down doors and make room for others while still doing work that I felt was challenging and could have an impact on the lives. So that’s what really started me getting interested in tech and in general. And honestly, I intended to begin my career as a data scientist, but then I saw the pre-course work for data science, and I thought that maybe web development would be a better place for me to start not going to lie. I got a little intimidated by some of that coursework.

Michaela: [00:09:48] Yeah. Okay. I can see. And so how does that work for bootcamp now? And I think you attended London school, right? So how does that work? How do you, like, do you have like to do a test that you can actually start that? Are you tested before? Or can anybody started? What’s your commitment there? Like how long does it normally take? Is it always like fixed? I really don’t know a lot about longer school. Obviously. I read a little bit about it, but I would like to. Yeah. Yeah. From you your experience, how that was for you and yeah. And what you can, you recommend it, would you do it again?

Natalie: [00:10:21] So full disclaimer, the process for entry to him to, well, it’s different. And I don’t know exactly what it looks like now, but when I attended, there was some pre-course work that was free and available to the public. And it included things like JavaScript on the mental, so functions and variables, those kinds of things. I really like. High level overview, just to see if you have the propensity for this. And then once you completed that self-paced pre-course work. You took a kind of a coding challenge to see if you could attend Lambda school. If you were able to pass the coding challenge and you were able to enroll into lamps. So that was my pathway in, it was challenging not going to lie, but I had bought a new computer. So because I bought that new computer, that was the pressure on me. Like, you can’t give up, you can’t, you can’t have wasted this Mac book pro money. So that was my motivation to really keep going. And honestly, I just fell in love with what it meant to solve. A co to solve the challenge of going from, like, I don’t know what any of this is to, well, I get it and I can do something with this. So that’s what you got me there. In terms of the experience of going through Lambda school. I had an absolutely wonderful experience and I know that that’s not. A one-to-one mirror for everybody who’s attended, even for everybody who attended. When I attended, when the program was structured in a way that everyone had a team lead and I have to admit my team lead is what made my Lambda school experience particularly phenomenal. His name is CJ he’s on Twitter. Also find him and follow him. And he was amazing. CJ was really. He, he put in the work. So he understood the assignments. We were giving the concepts that we were supposed to have, but he also cared about us as students. So there was never a time where I couldn’t come to CJ and get help. And because he cared about people, he was also intuitive enough to know that oftentimes all I needed to hear was slow down your movement. Your mind is moving quicker than you are, and that’s your problem. So I’m particularly thankful to him.

Michaela: [00:12:35] Yeah. Yeah. I think even, yeah, different companies, it’s the people often that, you know, make or break your experience there. Right. So you can be at a large corporation like Microsoft and you can have like a blessing and like a wonderful experience. And then you can have like a horrible experience if you’re in another team. Right. And I think this is true. For most companies, unfortunately. Right. But it’s always good to also have like people that really, you know, make your day and make your year and maybe help you progress in life. So I definitely going to link him in the show notes and then everybody can go and follow and also follow you. Of course. And yeah. So th that’s really good to hear. So how does that work? You have to know a little bit about programming before. It seems like two to pass a test at coding challenge. How. How much preparation do you need? Like, do you need a month to get, you know, to that point to be able to do such a coding challenge or do you need more, how freaky is that? And

Natalie: [00:13:33] yeah. Yeah. I think the, the kind of entry test that. I took what it did. It took about a month, month and a half to prepare for it. Now I don’t believe I could be wrong. I could be misspeaking, but I don’t believe that they had that same entry test. I think what they’ve done is they’ve taken some of those basic concepts that were included in that pre-chorus work and integrated it into. The regular coursework, but that being said, I would say anyone who is considering going to a bootcamp or studying anything anywhere to immediately, once they’ve decided that they’re going to do it, start going to work, get on free code camp. Grabbing you then me start. I mean, what’s the worst that’s going to happen. You’re going to be ahead of pace to where you need to be. I think that’s a good thing because it moves so quickly. So I went through the program as a student, but I also acted as a team lead and a section leader. So I went through the core curriculum about four times. I went through at once as a student, twice as a team lead and then once as a section leader. And so when I went through it as a student, Everything was moving so quickly and everything was brand new. So. There were, I was just trying to keep my head above the water. I was just trying to keep swimming and get the next assignment done and study on my own when I could to strengthen what I needed to start. But when I went through as a team, because I had already gone through that, trying to keep my head above the water, I was able to catch so much nuance and. The small things that didn’t seem like they mattered to me when I was going through as a student that I could absolutely see the value in as a team, not to mention, I had 12 students who were turning to me to help them understand the concept, which means I had to explain them 12 different ways, often 12 different times until it clicked in their head. And I honestly think that that’s what gave me the real foundation of what was able to, what made me able to succeed.

Michaela: [00:15:29] Yeah, I can totally see that. And I think it’s similar to what people say about blogging, right? Why it’s so important and so great if you’re blogging, because you have to explain the concepts that you think, you know, again, I didn’t write them down or teaching somebody like, so when I went through university, I also work very closely with one person. And so we had this arrangement that I was helping, you know, that person always prepare for the tests. But he was really beneficial for me as well, because I had to explain very detailed and really understand, you know, what I was when I was just reading all my life like, Oh, I know it, but then I have to explain it. Right. You’re like, Oh, maybe I didn’t understand that particular thing here is that. A normal way of doing those boot camps. I can’t imagine it’s not. Right. So only a small percentage of the students are actually working as team leads and helping others again. Do you say like, is it voluntarily, do you say, like, I want to do that and then you can become a

Natalie: [00:16:24] team lead. Well at the time it was a paid position at Atlanta. Now, unfortunately, they’ve done away with TLS and I think they’ve done themselves a great disservice by removing that vital piece of the puzzle, but it was a paid position. It wasn’t paying much. It, it was definitely. So again, I talked about how I bought the Mac book pro, so now I have to, well, I walked away from a retail job that was paying me $65,000 a year, which. That’s not rich money, but combined with my husband’s income, we were comfortable. I walked away from that to take the $13 an hour teeny business. I also had to really pour myself in it because now. I gave up my career for this at this point, like I have to make this work. So yeah. So yeah, unfortunately not around any longer though.

Michaela: [00:17:12] Okay. Yeah, that’s true. I think that’s really unfortunate and I think it can help, as you said, right. It can help your students. They learn more and if they even paid, even if it’s a little bit of money, right. So when I was in university, I was also like in the first year, I wasn’t as. I wasn’t fit enough to, you know, work in it, to be honest. Right. So I did other stuff, like whatever I could do. Right. But after a year, I really transitioned from what I have been doing outside to do what I’m also learning at school, because that really helped me get a better foundation and really advanced my skills. Right. So when you’re still working, you know, like I came from an art school and if you’re still working in the art section, which is interesting, but yeah. It didn’t really help. You know, I felt like every hour that I’m spending, I’m really spending just for the money because I’m interested in something else. Right. And so allowing students to actually do something that, um, helps them not only gain a little bit of money, but also, you know, strengthens their skills and give them some, some experience. I think that’s really, really powerful.

Natalie: [00:18:14] Yeah. Yeah. So obviously my team lead had a huge impact on me. And then some of the students who ITL four had told me that. And like you hate because no one likes to toot their own horn. And like, I, I think. Anyway, they tell me that at least a few of them have told me that they would have left Lambda long ago. If I hadn’t been there TL and the students who I did TL for, particularly when I was still in school, like I was often acting as their TL, especially when they lost it. 30 hours because they needed someone to turn to them. Someone’s help them understand. And I really enjoyed that role. It was something that I would probably volunteer time to do even now.

Michaela: [00:18:59] Yeah, I can imagine. So, so now you are graduating Lander school. How do you, how do you start your job search? Right. What kind of roles do you feel like prepared for? Do you feel like prepared for a normal developer role? Or do you go like for juniors? Do you want to do an internship? What’s your way of thinking at that point? And yeah. How did you, how did you go about that?

Natalie: [00:19:23] It’s challenging, right? Because in this industry, there’s always a bit of imposter syndrome. So it’s challenging to put you out the South out there and say, Hey. I can do these things now. I felt definitely prepared for a front end role. Any junior role I felt I could honestly compete with. There was some back and forth with myself with, are you really just a junior? You’ve put in a lot of work, perhaps you shouldn’t be limiting yourself to such junior roles. And I did have conversations with a couple of companies that the role wasn’t. Necessarily a junior role. And I really appreciate that those companies were completely willing to invest in me. They were using tech stacks that I had never touched, but they could see something in me that assured them that I would be able to jump in and. Kind of get my hands dirty and do what was necessary in order to take those roles. Now I did ultimately decide on a junior role. I think that it was a good decision as much as I may conceptually or theoretically understand certain things, doing them in practice is not the same thing. So I’m glad that I didn’t put myself in a position as to where, like there would be a bunch of unnecessary and undue pressure to perform. At a level when this is my first tech job, I did consider apprenticeships. I was really interested in the Twitter apprenticeship, and I thought that I had a really good chance. I had a recommendation from a former Twitter apprentice who was now a software engineer there. I scored perfectly on the coding assessment. I couldn’t find out that there were hundreds of people who scored perfectly on the coding assessment. And unfortunately, Twitter just didn’t see it for me. And that’s fine because ultimately what that meant is. I just shouldn’t have been going after apprenticeships. I should be going after my first role, which is the way I took it. It hurt a little bit feeling hurt because that was the dream role of women. Right? I mean, Twitter, Twitter, community tech community has carried me through this journey when I lost my team leads. I plucked team leads from Twitter. Mark has been, I’m going to have to find his, I can’t remember his last name right now, which is horrible, but I will find it and make sure you have it because that man extended himself jumped on video calls. When I was going through computer science and trying to figure out what a binary search tree was. And. All of these things that I had never understand, he really carried me through that program as well as just the general Twitter timeline. So with all those things combined, that just meant Twitter for me was the dream job. But I don’t believe in like staying rooted in disappointment. I don’t believe that one, no means anything in the grand scale of life. I think that a really, uh, kind of a benefit of coming to. Tech as a second career, a little bit later in life, like I’ve had enough life experience that one, no, especially from Twitter. Cause like who starts their career at a place like Twitter, that’s not reasonable to have that expectation. And it was truly amazing. So I got that news that I didn’t get the Twitter apprenticeship on a Friday on Sunday. I put a tweet out that, you know, Was it wasn’t even at helped me find a job tweet. It was a, I just updated my get hub, reading me about to really launch this job search kind of sweet and shout out to the Twitter community. It got reshared so much before I knew it by Monday. I think I had three interviews set up for that week, three really strong possibilities. And I finally wound up getting the offer from Fox chalk company where I’m at now, maybe a week and a half later.

Michaela: [00:23:16] Wow. Yeah, that’s really cool. And so what, what is expected, like what did the company ask you to do? How many hoops did you have to jump through? Was that something like very often you hear those really horrible stories and honestly, I experienced those over and over again. Like, it doesn’t matter how, how long you’re in the industry. They still like, Oh, can you do this and that? And can you improve that? And, you know, over here, And how was that for you? Was that actually the same? Did you feel like it’s really like you’re tested?

Natalie: [00:23:48] So for, to, so of the three roles that I feel like were really strong possibilities, one was you just had to build something using flatter and include a text. The second was a take-home test. And in fact, that take-home test, I, because I was doing like three at the same time, I wound up emailing them because they were using like.net and see, and some other things that I had no idea about. So I emailed them like, Hey, just so you know, this is where I’m at. I’m probably gonna need a little more time considering that to dig into these languages and find out what’s going on. They immediately responded to me. Hey, we just, I want to give you a chance to shine. You go ahead and use whatever with your framework you’re comfortable with to complete it. So that was wonderful. And then the place where I wound up accepting was just, here’s a Figma file. Make it happen. Like I was fully expecting to be white boarding. I had done months of preparing for it. My poor husband. I had him here at my board, like explaining to him algorithm, shout out to that man. Cause he sat there and really pretended to be interested in the thing. So yeah. Again, another aspect of my particular journey that I feel is atypical, but I’m really thankful to have no one sent me through. Anything ridiculous at all.

Michaela: [00:25:17] And I think really it’s important to share that. I think it’s so important to share this good stuff, right. To also show that there are companies out there where you don’t have to jump through hundreds of hoops. Right. And prove yourself. I mean, I totally understand that, you know, people want to know what your abilities are because it’s a, it’s a big investment for them. And especially if the company is smaller, right. The bigger the investment is, but yeah. I sometimes feel like this human aspect is really forgotten like that we are all humans and that nobody wants to be like tested and dissected and whatnot. Right. So, and I like that as well, as you said, well, we want you to shine. So I was interviewing quite a few people recently in the last year. Two month four positions at the startup that I’m currently consulting with. And so I tried to help them, you know, get their, their first engineers and their engineering team settled. And this is really what I wanted to do as well. I wanted to put people in the position that they can shine. So I’m not interested in what you don’t know or find out if, you know, Like from these 20 questions that I have, how many can I is core that you don’t know? Right. This is exactly the opposite. What I want to do. I want to have give people the possibility to shine with their personality, but also with their skillset and with their passion and what they’re interested in. Right. And so, yeah. When I designed the questions and the whole interview process, I was always thinking on how can I make it less gatekeeping? And so I think it’s really important that people also share their really good experiences. And maybe that also encouraged us to people that are in a privileged position. To walk away. Right. Not everybody can do that, but sometimes you can just Kuwait and say, no, not with me, not today, you know, not you and tried somewhere else. Right. Not everybody can do it. I totally understand. But if you can, and if we know, and we hear the stories, you know, of good experiences, I think this is a very. Powerful. Very strong message as well. There are others out there, you know, that that value you and your experience and your time and your skillset. Right. So, yeah. So I think it’s really good that, that this is how it worked for you.

Natalie: [00:27:32] Yeah. Yeah. I was certainly relieved and I think you’re right. I think that there are a lot of people out there who understand that. The interview process is kind of broken and are really working hard to make sure that no one has to prove themselves by doing things that they will likely never do in their day-to-day role on a whiteboard in front of a panel of people judging them.

Michaela: [00:27:57] I also think that it has to do a little bit, like with this there’s like this victim cycle, like you went through a such a hard time. Process and had to prove yourself. And now you feel like you’re superior because you know, you manage to get through it. And so now you want to expose the other people to the same scrutiny.

Natalie: [00:28:16] Yeah. Mapping play out a lot in society. I mean the whole canceling student loan debt. Oh, yeah. Lots of things. And yeah, don’t be that hurt. And if you’ve gone through something horrible, you should never want anyone else to unnecessarily experience

Michaela: [00:28:31] that. Exactly. Yeah. That’s that’s exactly. And these are like the two T mindset and I sometimes believe people, people don’t even know that there’s the other possibility that you could just, you know, Try to prevent people to go through the same pain that you had. Right. And you could learn from it, and this could actually be really your superpower. You went through this shitty, whatever. Right. And now you help people not to experience that. I think that would be really a cool thing. And yeah, you’re right with the student loan. It’s the same. Right. And sometimes for me, it’s really mind blowing. How can you wish for others that they will pay forever and only because you paid forever and like, Well, you should actually know that it’s not good.

Natalie: [00:29:12] Absolutely thing to put in there in terms of, if you’re hiring, hiring for a front engine and engineer, and you’re giving them like graph problems to solve on a whiteboard, are you really filtering for the best candidate to do the work that needs to be done? You’re not you’re. So you’ve now made this front end engineer spent all of these months prepping for these kind of algorithm questions, which means they’re probably not touching the front end things that they do nearly as much. So you’re just. Putting yourself at a disadvantage.

Michaela: [00:29:46] Yes. True. Yeah, totally agree. So one of the things that’s really interesting to me and they asked quite a few of my guests are engineering practices. So testing code reviews, how you write code, maybe some agile methodologies. Do you do stand ups and especially seasoned engineers like that have been in industry for a long time or have seen different. Places and work at different places. I asked them what they think about best practices, but I am super curious about, you know, how do you see that? Like, how do you decide something is a best practice? Do you read it on free code camp that people say this is a best practice? And then you think it is a best practice? Or, I mean, I, I imagine that if you’re studying at a company. That everything seems like a best practice. Everything that everybody is doing is like, Oh, this is how things are supposed to be done. And so, yeah, I really would love to hear your thoughts on that. And how do you, you know, get these nuances of, you know, what’s the right way for you to do it for a team to do it. And how do you prepare yourself to also be knowledgeable in that

Natalie: [00:30:56] area? That’s really challenging, especially when you’re just entering it because you made a good point. Like, I don’t have any basis of comparison for anything that’s being done at my particular job, but I will say one of the instructors, Atlanta school is not with them any longer, but his name was Louis Hernandez. I never had him as my instructor, but as a team lead, I worked with him. And so he would do these development hours for the team leads and kind of give us. Just some tips and best practices. And one of the things that he taught me that really struck with me is a best practice is just someone’s opinion. And that doesn’t mean that you discount it. It doesn’t mean that there isn’t some validity to it, but it is at the end of the day and opinion and understanding that. Made it a little bit easier to kind of suss through, is this really a best practice? But again, I will ask Twitter, like, Hey, I saw this thing done. Didn’t feel right to me. What do you guys think? Like ask other people, talk to other people who had been working in the industry longer than you. You’re going to get a variety of responses. And most of them won’t line up one to one, but you should be able to get a picture almost I’ve been diabetic. I’m like, where are they all. On the same page yet. And that’s kind of where you’re at now in terms of, at my job, how do I determine the best practice? I asked my senior engineer if he says to do it that way. And I don’t want to say just if he says to do it that way, then that’s how it’s done. Because there was an instance where we were doing something away. I presented a. Solution. That was completely different than what we were doing, but it made our experience easier. It got us to what we were actually trying to achieve, and he was open to that. So if something’s obviously has room for improvement, then sure. Bring that up. But if it’s about a file structure or something like that, and he says, that’s how it’s done, then that’s the best practice. Because at the end of the day, you got to satisfy your boss, right?

Michaela: [00:33:00] Yeah. And I think it also has married to learn from others. They have been maybe lower than you in this industry have seen maybe something else. So I think we should always be open to learn from each other. Right. So even as a senior or a very, very senior presenter, you can learn from somebody that just starting in tech, because they might have seen something else or even, you know, the, the experience that you made in retail. They could shape your understanding and maybe something wonderful comes out of it. Right then. So maybe you are coming up with a new design patterns. There haven’t been like many introduced lately, right? So I think it’s really important to be really open and learn from each other. But also, as you said, be critical and reflective of this is actually work for me. And there are definitely best practices that are not working for everybody. And I think. One of the things that I hear very often, and I’m just thinking, well, this wouldn’t be working for me on a day to day basis. As for example, mop programming or assembled programming. Like we’re, there’s a whole team of people working at the same time and I’m like this wouldn’t for my personality. I would just be totally overwhelmed with all these people around all the time. I’m not saying it’s not, it’s probably good, right? Yeah. To do it. And for the code and for the quality and for Tinbergen. Perfect. But for me personally, I would be burned like after a week. I’m like, I have to quit. I can’t do that anymore. Right. Are you really like, if I’m, if I have my quiet time and I can think about, and it’s just like, it charges my batteries again. And so I think this is some of those practices that we hear and people read off them. Some people really love them. And then I think some others, like me included, I cannot envision to do that. Like. I can do it like once a week, right. No problems, but I have to prepare myself like this is not a time that my energy goes not only to the programming and thinking about the productivity thing, but really to just be surrounded by people all the time. So, yeah.

Natalie: [00:35:03] Because I thought about it. And I’m thinking about like how it may sound. When I say I just listened to my senior dad, I want to point out that I also ask why, and it’s not a petulance kind of like, well, why are you doing it like that? Or me waiting to prove that that’s wrong. But it’s to understand, because you made a really good point, especially when someone’s been doing this longer, they run into things that you been seen on your five component app that you’ve been building. So make sure to understand the why and not just blindly accept that the best practices are a, B and C. Yeah,

Michaela: [00:35:40] exactly. I mean, understanding the reasons I think is so important because otherwise you’re also best practices are very often extremely intertwined with the environment. You know, what kind of software are you building under? Which circumstances are you building them? What business goals do you have? Right. All of that actually influences the, the practices that you should. Plays into your development process, right. And how you should structure that thing. And if you don’t understand the why you will just take it like a black box and apply it to every situation, you know, and in many situation it will be the wrong choice to do it, right. It doesn’t matter if it’s test driven development or code reviews. There are a lot of ruins is how to do them. And there is also the right and the wrong time to do them in a certain type. And it has, you know, it’s really, it’s interconnected with the development team, all already constraints that you have at your company and everything. Right? So the why is super important as you say. So there are two questions that I really want to ask you. One is about the tech stack. So how did you choose it? I imagine that maybe it has to do with lameness. Cool. And because they are teaching that this is how you ended up having that tech stack or, you know, it’s JavaScript, no dried react and so on. But did you choose the London school because it had the right tech stack or was it really you choose Lumberg Cook’s tool because you felt like this is the right school for you and they had the tech stack. So which, which way

Natalie: [00:37:09] did it go? So I chose Lambda school because. It came well recommended to me from a mentor I had made contact with through Twitter. And she was hearing that Lambda was putting out kind of the best bootcamp graduates. So it was definitely my tech stack came because I chose Lambda. I do think that there’s going to be value in learning other tech stacks, but I want to make sure that I have a deep enough understanding of. JavaScript, which is the entire basis of everything that I do before I start, like, I’d rather have really deep knowledge there than broad knowledge everywhere and not know anything really well. So I absolutely intend to kind of reach out and explore other things. But right now my priority is just getting really good at what I already know.

Michaela: [00:37:58] Yeah, I think that’s a good strategy. I think it’s the same good strategy as starting with a junior position because you can advance really quickly. So if you, if you’re in that junior position and you learn and you grow, then you can quickly go from junior to not a junior position anymore and further, right. But if you skip one step and then you’re struggling and then you have to put fires out here and there all the time, because you just have to make sure that you’re up to date with what you have to do. I think then you cannot strive that much. Right. So I think even that could be as slower. Culverts progression, but it also depends on your team and obviously the company and everything, right? So this is, this is not universally true, but I think in, in many cases it’s a good staff, especially if you are really new to the industry, right. I’m definitely not the person that says don’t shoot, you know, a little bit higher and try, because especially later on people, sometimes, especially women. Don’t dare right. To shoot one higher, which I also think at that point, you should do it like go for the next role. I think skip one and then just try it out. But I think, especially at the beginning to get this foundation, I think it’s a good step to, you know, get it ready and then grow quickly. Yeah.

Natalie: [00:39:11] I think you bring up a really good point. And that’s why I was initially considering an apprenticeship in the first place, because I thought an apprenticeship would be perfect in that I would feel more comfortable making mistakes, which might allow me to be a little bit more bold than I would as a junior. Now it didn’t work out that way and I’m glad about it. And I’m glad I’ve landed in a place where I feel comfortable that I can make a mistake and it’s not going to be held against me. But I think you make a really good point. It can be very tempting. To, especially in the beginning go to super as high as you can. But I think, and this is something that I’ve learned, not just in tech, but in life, in general, for some of us, I’m one of those people. There’s a tendency to Excel and get the next promotion really quickly. And that’s what happened to me in retail. About every six months I got a promotion and I worked through it and it was fine, but I can tell you as a store manager who had only been in retail a couple of years, there were definitely times where I had to really rely on the people working under me, who had been in retail for 10 or 15 years and had seen these things that I’d never seen. So I’m also, I’m trying to be ambitious without being too ambitious. I don’t want to move too quickly. So, yeah, I think you made a really good point about that

Michaela: [00:40:32] maybe to also wrap our interview up. What would you say, especially for people that are noticed one to go or get into tag or get their first job or making these decisions? Right. Very early on, like. What technology stack, what school, you know, what, where should I apply? What was your, you know, and you said it a little bit, bit fitter, right? Like building those relationships was really important. Is there something else that you think people should do that sets them up for success?

Natalie: [00:41:03] You’re going to have to study hard. You’re going to have to be willing to be knocked completely on your back in tears, in a puddle on the floor, because you don’t understand anything you’re going to have to be able to get up from that, understand that that’s normal and. Keep going in terms of which school, which bootcamp, which texts that I have no opinions on that because it’s going to look different for each person. You have to make the decisions that are right for you, but no matter where you choose to go, you are going to have to put in more than you expect to put in. You. Won’t be able to just show up during your scheduled class time and then move on with your day. And. Think that you have done enough in order to be successful, but you also have to find balance because many of us, myself included, went through periods where we completely lost ourselves in the studying and the attempting to reach the next milestone. You don’t want to find yourself in burnout and that’s where you will lay in there. So you’re going to have to work hard, but you’re going to have to know when to listen to your body and your mind when it’s telling you it needs a break. And that will often be the thing that gets you past the block or so.

Michaela: [00:42:23] Yeah, I think that’s absolute fantastic advice. And do you know what, what was really interesting for me during my studies? I’m also a person that, you know, if I, I, first of all, I love studying, I really love learning. I love like I’m a little bit addicted to it. Like

Natalie: [00:42:38] it’s why I’m trying to enroll in college again.

Michaela: [00:42:41] Yeah, exactly. Right. Yeah. And that’s why I have been at school so long, but. What I also saw is that I performed the best, really the best grades and, you know, the best ideas, creativity flew when I was studying a little bit less and having more fun, you know, I mean, I was never like the over party person, like never studying and always partying. I was more the other person. Right. But it was studying all the time and they were partying, but. But I added like a little bit partying to the mix, like meeting other people, socializing and maybe not doing, you know, some of the homeworks and not studying or not, or night or something. I actually performed better at my tests, which I found pretty interesting. And there was like, no good explanation at that time, but obviously it has to do that. You’re rested that you’re balanced, right? That you’re getting other input that your mental models and your perception and your perspective are enhanced. And you’re not just like this, you know, book smart person. And so, yeah, I think you’re totally right work and study. Part, but also don’t forget like everything around, which is really valuable. Like your relationships, your family, your friends, you should really cherish them and make sure we spend enough time.

Natalie: [00:43:57] Yeah. Yeah.

Michaela: [00:43:59] Yeah. Okay. So Natalie, thank you so much for being on my show. It was really a pleasure to talk to you today. I learned a lot. It was really nice and the thing is so much. Well,

Natalie: [00:44:09] thank you for having me. I really appreciate being invited onto the podcast. Yeah.

Michaela: [00:44:14] Thank you so much. Okay, bye bye. Bye. Bye.

Natalie: [00:44:19] I’m a waver.

Michaela: [00:44:21] I, me too. I bet you’ve actually, I think every episode I’m leaving, so that was good.

Episode 35: How Programmers Think and Learn

In this episode, I talk to Felienne Hermans, who is an associate professor at the University of Leiden and researches how developers think and learn.

We talk about:

  • why it is so hard to read and understand code,
  • her book “The programmer’s brain”,
  • how we can learn easier to program,
  • techniques to understand complex code quicker,
  • how a shared vocabulary can help teams, not only during code reviews
  • and her process to write a book developers will love.

Today’s episode is sponsored by ConfigCat – your favorite feature flag management tool to release more frequently with fewer risks!

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: How programmers think and learn

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Michaela: [00:00:00] Hello, and welcome to the soft engineering unlocked podcast. I’m your host, Dr. McKayla. And today I have the pleasure to talk to Felienne Hermans about how we can learn to program faster, better, and more easily. But before I start, I want to tell you a bit more about ConfigCat – today’s sponsor of this episode. ConfigCat is a feature flag management tool that allows you to seamless and effortless switch features on and off in your application through an intuitive user interface. Everyone on the team, independent of the tech skills, is ready to go within 10 minutes of training to configure the feature set that your user sees based on rules. You can even start to do sophisticated A/B testing, hassle-free and intuitively within a few minutes.

Super interesting for my listeners doing business within Europe, ConfigCat allows you to have your data distributed in the European Union only so you can easily stay GDPR compliant. So if you want to tap into the sheer possibilities of feature flag management, go have a look at https://configcat.com/

I tried it and I promise you’re up and running within few minutes. Feature flags mean faster deploys with less risks. Less risks is also the generous free plan of ConfigCat. You can start for free today. And with each paid plan, they plant a tree. Cool. Right?

But now back to Felienne. Felienne is an associate professor at the university of Leiden and investigate how we can best learn how to program Felina is also active in the developer community and organize several developer, meetups, and conferences. She’s a big fan of legal and served for many years as a legal judge at local competitions for kids, her passionate for bringing young kids into TAFE also leads her to being a teacher at the high school in the Netherlands. Currently feeling also writes a book called programmer’s brain explaining what happens in our brain when we learn to code, but also when we read and drive and try to understand code. So I’m super thrilled to have Nina here with me, the unit, what? Come to

Felienne: [00:01:57] Michelle. Thanks for having me.

Michaela: [00:01:59] Yeah, I’m really, really happy. It took quite some time, but now you’re here. And I’m so I’m so curious to learn more about the program is brain, because this is an area that I’m super interested. I mean, we both have been doing the PhD together right. In the same research group, but we were sitting in the same office and I was researching program comprehension. So how are people understanding code. And so this is so close to what really interests me, what really fascinates me. So I’m super thrilled to learn more about that. So can you tell me a little bit about the book, but also your research? Because I think the book is very close to your research that you are doing at university of Leiden,

Felienne: [00:02:38] right? Yeah. That’s correct. And maybe we have to go once. So Beko about what lead me to write this book and what lead me to, to do this research because initially what exactly we were doing your PhD at the same time. And then I wasn’t so interested in program comprehension. I was more interested in developer tools at that time, but then what happened is I started to teach. And then when I started to teach, I realized that. Programming is so hard. I think I sort of forgot because I was already programming for such a long time for myself, that all these parts of programming, like there is so much you have to get, right. If you’re making a program, you have to make a plan in your head. Like this is where I’m going, which requires you to understand the domain, the problem that you’re solving. But at the same time, you also have to be like ridiculously precise. You have to get. Periods and semi-colons and brackets and everything has to fit at so many different levels that when I started to teach kids, it’s like, Oh my God, this is so hard. Why is this so hard? Why is it so hard, for example, for children to remember syntax? Why is it so hard for kids to remember what I was working on there? Sometimes I saw kids was very engaged in a problem, and then I explained something to them. And then a few days later it was like, Oh, I have no recollection of this. And I was like, but I explained this to you, like just a few days ago, how do you not remember? Or I saw them very determined of, Oh, I’m making a game and a cat has to catch fish or something. This is what I’m doing. And then they sorta got sidetracked. And then you, you walk past five minutes later and it was like, Why aren’t you making a game with a cat and it goes like, Oh yeah, that’s true. I totally forgot. He goes, I fell into some hole of a variable or a loop. So that just got me really, really excited to understand more about how do people think, how do people remember things? And of course there was so much research already that wasn’t so connected to programming. This is relatively easy to read all sorts of introduction, books into cognition and cognitive science. But then I realized there wasn’t really a book that explains. Beginner, cognitive science in the context of programming. So then I was like, I could write that book because now I know a lot.

Michaela: [00:04:51] Oh, yeah, very good. And so I actually watched one of your talks. I forgot where it was, but it was really good to talk about programming and understanding program. And you were also talking about kids and when I watched that, and also when I heard you talk right now, I’m wondering, but can we actually generalized from kids to adults? Right. So do we struggled the same way as kids. I struggle. And I definitely do see like this abstraction levels. Right. You have to be very detailed as you said, with the center rugs and semi-colons, or even like tabs and so on. And then you have like this, this larger vision that you have to keep in mind, but do we struggle in the same way or do adults have different problems also compared to

Felienne: [00:05:31] kids? That’s a great question. So in general, adults and kids do learn and struggle at the same level, but that is the case for Morphis adults. So if, if a 10 year old is learning to program and let’s say your next door neighbor is also learning to program, and they’re not a programmer, right. Then they will very much struggle with the same thing. However, if you, if your question is about expert programmers, then they don’t, then they also struggle, but they struggle in different ways. So you already know Java and now you want to learn R then your circle will be different than someone that doesn’t know Java that is learning. Whether that’s a kid or an adult. Okay. Yeah,

Michaela: [00:06:09] I see. And so something else that, that I also thought when, when I heard you talk about all different concepts and you were saying, well, next word known something different than like a novice or, or struggles differently. Like for example, I’m trying to learn new programming languages. Right. And so I, I know Java, I know C-sharp, I know Hiten and a little bit of JavaScript, but. You know, the further it goes away from the languages that I initially learned with her Java and object oriented programming, the more I’m struggling. Right. So I’m struggling, I think, because I have all these preconceived ideas, mental models notions off, you know, what’s right. And what’s wrong, how to do that. And then sometimes I feel like. Oh, this doesn’t work so well now in PI 10, right there, maybe this is not that I’m not meant to do it that way. Right. And so how can, how can people that already know language? How can they overcome those things are some techniques that we can employ, right. To get better at learning new languages. Yeah,

Felienne: [00:07:08] definitely. So one of the things that I talk about in my book is the concept of transfer. So transfer is you already know something about domain a and that helps you to learn domain B. So if you have two languages that are very close together, let’s say she’s sharp in Java. Then you probably experienced lots of positive trends. Like, Oh, I already know this. Oh, it’s exactly the same in Jaffa. That’s no issue. So that’s positive transfer, but then you also have. Negative transfer where you assume that something works a certain way and then it doesn’t. And for example, if you do, Oh, object oriented programming in Java, and then you go to Python, then there’s also object oriented programming. There’s also classes and methods. So maybe you’re like. I know this stuff. I understand what a method is. And then suddenly stuff, of course in Python happens as real time. And then you’re like, Whoa, everything I knew was wrong. So there you have negative transfer where you might assume that you know something and especially if you’re an expert and also you think this cannot be hard. I am already an expert programmer, so probably Python. Isn’t very hard. And then it’s harder than you think. And then of course you also run into issues of motivation where you’re like. I will never learn this because it’s so hard. So actually, if you want to improve on transfer, there are two techniques that people typically use and the techniques are called hugging and bridging. So hugging is where you try to get the concepts to be really close together. An example of hugging is if you already know Java. Then it might be easier for you to solve a problem in Java. So first you solve the problem in Java and then you simply, it’s not always simple, but simply translate your solution into, let’s say Python, if you’re learning that. So that makes it easier than the are. You’re trying to get the languages closer together. And with bridging you’re deliberately looking for concepts that are the same. So you, you really set out like, eh, like you’re walking in a forest and you’re like, Oh, I know that. So I know that tree. So with bridging your reading, you tried to walk around in Python and you’re like, Oh, a function. I know a function. What is, what is it that I already know about functions? Well, they have parameters and they might have output parameters. So are you really getting your prior knowledge? That’s already in your longterm memory? You’re, you’re fetching all the knowledge you have and with the knowledge. Close. You’re trying to bridge the gap between the old and the new programming language. So those are concrete techniques that we know that can help. Make it more likely that positive transfer will happen so that you will benefit from existing knowledge. But of course, this is not a magic trick. So learning a new programming language, learning something new will always remain hard. So my book doesn’t really talk about motivation. That much, it’s really more about the, the coconut, the theoretical cognitive side, but yeah, you also have to be prepared to be a beginner. Again, you have to accept that it, even though you might have been doing Java for, for 30 years by then will still be hard probably, and will still trip you up in unexpected way. So I don’t have better news. Like these techniques I described in my book, definitely help, but they’re not a magic pill. It will always be hard to learn a new programming language.

Michaela: [00:10:24] I think also for me, for example, when I’m thinking about Peyton and Java, cause this is a very concrete example that I’m experiencing things years now is that, you know, there are also not so many resources specifically for. People that, you know, have Java knowledge and want to learn pattern, right. As you said, because if I’m aware of that, I could actually transfer some of the concepts and help people. So for me, it would have mean, so when I started Python, right, well, the first thing was I actually started in the jungle. So I went to the jungle. Google’s a website, which is wonderful. I have to look that up and put them right link down there in the show notes, but. And so they, they walk you through a complete application and that was wonderful to get me started and, you know, to give me some tools. And I was also getting a lot of really quick. Positive experience. Right? So I was learning a lot, but I was also making progress. But then from there it was really good, hard for me because when you go through a normal Peyton court, it was really boring. And I couldn’t, I couldn’t drag myself through it because it’s like, Oh, this is a data type. And this is a very able and see how we assign something to a very relevant. Read, this is not a good use of my time. Right. And so I think it has also a little bit to do with being more aware that there should be resources for people that have already some preconceived notions or somewhat models and help them to, you know, hop on to a different language. What do you think about it?

Felienne: [00:11:50] Yeah, I think that’s very true. I think there’s lots of materials that are aimed at. Absolute beginners. And you never know who might take your core. So maybe let’s just explain the variable just in case. And let’s just explain the new, and of course it would be like a combinatorial explosion. If you had to have courses for like five of them, for Java programmers and see by the programmers. So I guess it’s hard to develop these things. And actually I just finished a research study where we interviewed. High school teachers, high school, computer science teachers. And we asked them specifically about this and we asked them, Hey, do you take into account a programming language that students already know when they come into class? And it is very, very hard and it’s unlikely for various reasons. So sometimes teachers say we don’t have time to specifically spend effort on this, or we don’t really know what programming language knowledge they already have. So it’s very hard to connect to prior knowledge because one kid might’ve done scratching in elementary school and another might’ve already done a bit of Python. So it’s definitely a recognizable problem with sadly, it’s also a hard to fix problem for professional resources for professional programmers. And also for kids that are learning programming in school. I have

Michaela: [00:13:04] one. I mean, you’re definitely right at the high school. There’s also one teacher, you know, and let’s say 30 students or 50 students and so on. But I think it’s K in, on the internet, I think it’s a similar one with, with all the niches. Right. So niches are now think about like, The, I mean, even though there are only a few, but let’s think about how many people there are that know Java didn’t want to learn by 10. And I think if you think about the internet and if you have a big distribution, like it could be really relevant. I mean, there’s programming resources. They’re like, they’re really. Coming out like weed everywhere. Right? So many people that are jumping on this train to teach others to program it. I think it’s maybe some niche that is unexplored from an entrepreneurial perspective to actually make

Felienne: [00:13:53] that work. I think you’re definitely right. That as your own struggle is a very recognizable struggle for many people where I began to resources are too slow and boring, but then you also not quite, and ready enough to just start to build something after an intro, like Django girls, something like that. Hasn’t prepared you enough to be a professional Python programmer. So yeah, I think it might be right that there’s a, like a market gap there and it’s someone could feel.

Michaela: [00:14:19] So in your book, you also talk about reading and understanding code. So not only learning and reading, I mean, reading is one of the things like 60% are a couple of studies that showed it almost 60% over 60% of our daily work is on greeting and understanding code. So how can we get better at that? What are some of the concepts that are things that we have to learn to get better at reading and understanding code?

Felienne: [00:14:44] Yeah, but I describing my book is three different types of reading code, because I think that as programmers, we don’t really read code that much. And that also means we don’t have good strategies for reading codes. Like if you have to start a project and you probably know a bunch of strategies, like how am I starting a project? Maybe I’m starting with tests or I’m really doing a small, minimal viable project. You have some strategies for reading code sometimes. I want to use a certain library and I go to the GitHub page of the library and I sort of skimmed their code to see what they do because of course I don’t have repeat me or it’s outdated, or it’s an understandable to me. So you skim the codes and like, how do I do that? Why start at the talk? Like it’s a book or do I start somewhere and looking for a main methods and then. Then look, what it refers to these are of course, both things that people do, but we don’t really have good strategies. And very quickly people are like, Oh, code reading is hard and other people are bad at writing codes. It will be just easier for me if I write this library from scratch, because it’s so hard to understand codes. So the book offers a number of different strategies that you can use to read golden. And as I said, I had distinguished three different types of code reading that are associated with three different cognitive processes. So firstly, you have your long-term memory that has all your memories and also programming related memories and also syntax of programs. So sometimes you’re reading a specific goals. And the example I give in the book is an ape programming APL. This is sort of an oblique programming language and no body knows. And if I give you an APL problem, your problem will be a long-term memory problem, because you don’t know the keywords of APL because the keywords of APL are Omega and Tata. And even they have a keyword that looks like an angry face. It’s very weird. So your problem is a long-term memory problem, which you can also sometimes have in Java sometimes in Java, that can be a Java built in methods that you don’t recognize. So that’s a specific long-term memory problem. And if you’re aware that, Oh, this code is confusing because I just don’t have enough knowledge, you can specifically go look for that note. Another issue that you can have is a short term memory issue. So your short-term memory as people might be aware of is very, very, very small. So you can only remember for like, let’s say around five things at the same time. So if code forces you to remember more than five things, then. Your brain gets full and then you’re just lost. So if you, for example, have a methods with many parameters or a function, you have to remember the function name, and then you have to look up in the code search. Oh, where’s the function defines. Oh. And then you have to remember the actual parameters and then, then define parameters. And now your brain just gets full and you cannot remember everything. You cannot. Get it in your short-term memory then of course, it’s also very hard to understand the goals. So that’s a different type of problem. That’s also has a different type of solution. If you don’t know what keywords you have to Google the keywords, but if you cannot remember everything, you’d maybe have to get a sheet of paper and write down the information that you’re lacking. So that’s really a problem of information. And then there’s a third type of confusion and that’s confusion that’s related to the working memory. So if you think of my example in the book is a basic program. If you think of a program that’s a heavily imperative program, then maybe there are just three or four variables. So you can remember them and maybe it’s just multiplying and dividing and looping. So you do know what’s going on, but still the code is hard. And that might be because you have a working memory problem because. And this happens. I often say this is when you have to use the strategy of the fingers. So once you take your finger on the screen and you started to reading like, Oh, Oh, this is this variable, this is this variable. Then it’s very likely that you’re, you have a working memory problem. You have the information, you have the knowledge, but it’s still puzzling to get, or what is going, going wrong. So I think once we understand these three different memory processes and the three different types of confusion that you can experience while reading code, you also see that there are three different solutions. And then, you know, as, as we’re learning a new programming language, it will always be hard to read code that’s made by someone else or made by you a long time ago. It will never be very easy, but once you recognize. What type of confusion you’re experiencing, at least you might be a little bit closer to the solution.

Michaela: [00:19:20] Yeah. W what would be one solution? Let’s say, for example, if I have the processing problem, right? So that my processing power is not high enough. What can I do?

Felienne: [00:19:32] Yeah, that’s a great question. So some of the techniques I described in the book is for example, making a state stable. So I know this sounds really silly and a bit like you’re back in school, but it really works. If you make a table on paper or you can also do it in a spreadsheet, doesn’t really matter. You make a list of all the variables that are in the program, and then you write them, let’s say you’re doing a loop. So on the first iteration of the loop, what are all the values of the variables? And then on the next iteration of the loop, what are all the values of the variables? And that can give you so many information. For example, that might be something that acts as a counter that’s that goes up. And sometimes these things are so disguised that there’s no for I in range five, it’s very hard to see which is going up and which is going down and. Which of the variables are doing list axes. And sometimes before you can make such a state table, it’s going to be really nice to visualize the dependencies in the codes. And for that, I really like to make a screenshot of codes and print it out as a PDF. Or you can also put it on your iPad. And I just link, I circle all the variables and I draw links between all the variables. Okay. This variable. Where does it go? This variable, where does it go? And then once you have sort of a mental model of what is connected to once you can step through the coast and really make a table of what are the values, and that can be really helpful in understanding what is going on. For me, it

Michaela: [00:20:50] sounds very much like debugging, like how I debug code. Right. And there was actually, I forgot how it was called years ago. But when I was working at the university of Victoria with Margaret and story there, they had like a tool that helped you explore different programs. Right. And so the idea was that, well, if I want to understand how this program works, Then I think it was driver or something like this. This was the research tool that they developed. And so this driver was helping you step-by-step goes through to code, right? So you were actually running the code in order to understand the code and a little bit like debugging, but that it had more output. Right. And you went under, you’re looking for problem or dining, the, the bag that you’re have right now, but really understanding the culture you were executing. It. Something else that came to my mind is like, Uh, tests, I think tests very often help with that, right? So you have like a test method and it tells you a little bit how, you know, it tells you because it testing something in a small unit of how it works and then you could actually run the task and you can also do step-by-step Deepak. That has, so this is what I’m doing. For example, quite often, if I’m not understanding something or want to get familiar again with them, Code part of the system or code base that I’m not familiar anymore. What do you think about this instead of, you know, having your finger in some paper, really using the tools that we have in our ID, for example, debuggers and

Felienne: [00:22:14] so on. Yeah. So those are definitely great tools that you can use and often they can be used in combination with each other. So a debugger can also gift. The most recent value of a variable, but often case the burgers don’t show all the previous value. So you don’t get this nice table of relationships. So if you have the burger, you can definitely use it to, to make all the effort, to understand all of our values of one iteration. And then you do another iteration and you still write it down. So I think these, these. To asks the audience tools, nicely compliment each other and also for our tests. Yeah. You might be curious, Oh, what happens if this list is empty, you can do this mentally. But if there is a test that allows you to run the code with, let’s say no customers or something, no one is locked in what happens then? Yeah. Then the tests can really help you also build the mental model. So the reason that my book mainly describes matters that you can do on paper rather than on the computer is because I thought, okay, Debuggers and testing. This is what people already know. These are tools. Am I book aimed at professional programmers, they will use desk. They will use a developer. So these are tools that they’re familiar with. So here and there, of course, in the book we refer to that, but the book was really mainly meant to give people new strategies that they haven’t tried out. And, and of course, like, If you have a actual toolbox with tools, sometimes a hammer and a nail is better. And sometimes a screw and a screwdriver is better. If you, if you have large vocabulary of tools, then as a professional, you can decide which tool makes sense and watch which context. And so

Michaela: [00:23:45] one of the topics, my favorite topic is code reviews. And so here, we also have to understand, read code, right? And give suggestions also really understand not only what the code does, but also is the code correct on so many different levels. Again, we are assessing the code and definitely in a good understanding of what’s going on here is the first step. And. I find that a lot of people are struggling with that. Right. And so there are several, several issues to dad. One is that very often code review tools that we have nowadays. Yeah. Tooling that allows you to do the code reviews, do not show you the whole code. Right. So do you touch, so you snippets for example, this is really a difficult thing, right. But then also it’s code, maybe that you are unfamiliar with, maybe you don’t know the code base. What are your ideas about code reviews and how can we make them. You know, better, how can we decrease the cognitive load and how can we get the most out of it?

Felienne: [00:24:40] Yeah. So I do think that the three different forms of confusion that I described in my book can also be helpful in code reviews. So what I really hope is that people won’t just read the book individually, but also like you can buy one copy and read it with your whole team, because I think the different forms of confusion give vocabulary. If you are in a cogent view, I’ve of course, often people will say, Hey, I find this code confusing, and that’s sort of fair. If you find the goat confusing, then, then that’s what you think that that is not an unfair Coleman, but there’s not as helpful for the person that has written the code. Okay. You find it confusing. Why? And then in my experience, people find it really hard to vocalize. Why code is confusion. And if you have these three different modes and at least you can say, Oh, this code is confusing because I don’t know this keywords. And that’s mostly the author’s fault that you don’t know a certain keyword or certain language guns construct in fight. And for example, list comprehensions, you might just not be aware of lists, list comprehension for job if you’re coming from Java. So that’s not really a. Problem of the author does that’s more a problem of the reader that the reader can fix by just learning a content. So once they can vocalize this goes and confusing because, Hey, I don’t understand what that, that list thing is doing. Then the solution can be. I explained that to my teammates and then the code is no longer confusing without a change to the code. Whereas if a certain. Piece of code requires lots of processing power that maybe as an author, you can change it. And we have some, some techniques in the book book as well, but people might already be familiar with techniques like giving stuff, better names, refactoring, a large piece of code into different steps. So if the issue is processing power, then there might be something that the author could do or. Once to do that is going to make the code better. So I think these different modes of confusion and just the notion of cognitive load that sometimes your brain takes lots of processing power because it lacks certain understanding. I think that might also smooth go tree fuse. It it’s really, the book is not, man’s only to be. Help for the individual programmer, but also very much meant to set a common vocabulary. Like if more programmers would know the difference between working memory short-term memory and long-term memory, then I guess they could also understand their own confusion, better proposal, understand why other people find their code, which they think is so beautifully documented. And so well-structured. It might still be very confusing. If you bring me a fantastic poem in German, then I will never see the beauty. I know some words. It’s not that I don’t understand any German. I can like order a coffee or something and you might be totally crazy about this. look how fantastic it is. And I will never join you. And that’s most of the Bowen’s problem. That’s just because I don’t know enough words and grammatical structures to really see what’s there. So I think that that difference might help people also have more smoother code reviews.

Michaela: [00:27:43] Yeah, I think a common vocabulary, not only about, you know, the processing power, but in general, like also shared engineering values are really, really important. Right? And this brings me to readable code because maybe I’m a junior or maybe I’m unfamiliar with this framework or with this API writer, as you said, I’m having some. Lack of knowledge here, and this is why it’s confusing, but it could also be that the code itself is, as you said it a little bit unreadable and so on. And I think it’s really important that teams develop their own or as a team, right. Get coherent engineering value. What is readable code for us? What is, what are we valuing like high quality means for us? Isn’t that right? So, and I’m working with this startup right now. Can be building their engineering team. And so one of the first thing that we worked on is our engineering value. So whenever we are hiring and when we are getting new team members that we are all on board and this is a living document, right? So we change it. And you know, when somebody is coming in, we can reflect on those engineering’s values again, and things like what is high quality code? What means that our code is good, tested or testable, you know, maintainable and so on. And I think this is really important for contribution as well. And, and, and also for understanding the code of others, because it helps us to see, and this is something I read the first two parts of your book that are already available on the website. And so what I really found interesting was

Felienne: [00:29:09] that. Have a cold

Michaela: [00:29:10] is cold, for example, that has design patterns or follows design patterns. And it has to do, and not, I have to explain it. I will explain it. And you can then, correct?

Felienne: [00:29:19] Yeah. It’s really great to hear what other people take away if you’re writing.

Michaela: [00:29:23] So please go. Yes, it’s hard because it’s had one readable code, right. Or code it’s easier process is code. It follows the same patterns if, and only if. The person that reads this knows design patterns, because then they’re taking those patterns, these parts of the code from their long-term memory. So this frees up short-term memory and frees up processing power. So they can actually understand the code quicker. But what I also took away from them that it does that well, the sign patterns, okay. December, everything that we know right. So that we can recognize whenever we have as it. Is it team, if you have a good structure and we know this is where, you know, those piles are right or VR structuring our classes in that way, all of that is very similar concept. I think we can transfer in generalized that from the design patterns and go away and say, well, if we know where to put those artifacts, And, uh, people can expect something. They will also overtime, you know, be better in understanding and processing our code. So this is what I took away and I thought this is really great. I will put that into my cultural workshops because I think it’s really helpful. And this is also where I think. Coherence there, the power of a coherent code base comes from, right. So there’ll be half coherent coding practices, coding style, because this really frees our memory, our yeah. Freeze, our processing power so that we can re try to understand, okay, what is this or isn’t doing and not, you know, we’re going to find different methods and variables and so on.

Felienne: [00:30:54] Yeah, I think that’s a great takeaway. And if you like that, part of it will be lots of more in the book and the rest of the book that we can talk about now already a little bit. So the process that you’re describing here in these schools chunking, and that means that if you group similar information together, then rather than remembering it as similar information, then you can remember it. As one go. For example, if I re if I asked you to remember cats, dog donkey, that’s a lot easier to remember than salt roof microphone, because those words have nothing to do with each other. Only they’re in my view right now, as are easier to remember three things that are similar and three things that have nothing to do with each other. Because with the first one you think, Oh, Oh, these are all animals. You might already anticipate if I say get it. And the next thing could be dog. The same Mister we need for code. So if you look at code that has, let’s say the Singleton pattern and look at the code and you can just say, Oh, this has a Singleton pattern and you can remember, Oh, and the Singleton is this one thing, like a token, for example, that can only be given out once. Whereas if the code is. Sort of all over the place and it doesn’t specifically use a design pattern, then you cannot add one goal memory. You have to remember individual lines or variables or class names. And remember your short term memory is really limited. So if two or three or four things are in there, then it’s full. And as you exactly said, it frees up some mental space. If you can just. Say shingles and pattern token, and you have two things in your brain. Whereas if you have to remember, Oh, one variable is creative. Oh, if you try to instantiate it again, you get an error. Then you have to remember many different things at the same time. And, and you’re right. That, that, that really goes beyond design patterns. Some other examples that we have later in the book are for example, about variable names. There’s, there’s a really nice new paper that came out that talks about the concept of name molds. Like how do you form a name? Let’s say you have to make a name for the maximum value. What do you use? Do you say maximum value or max value? Or value max or value maximum or maximum or values. There are so many different ways in which you can do this. And this paper that I described in my book describes an experiment in which they asked people to just came up with names for such a situation. And you see, indeed developers are. All over the place, but if you teach them to use a specific tree step technique, then they get a lot better at making the same type of names. And then your code gets easier because if you’re looking for a valid variable, then you know what to look for. If it’s always maximum and then the entity, you know, there’s all the maximums will be in the beginning. You have to look for the entities in the end or the other way around. It seems like there’s not a big difference between different molds, but quote gets really confusing if different people use different molds. So again, also variable molds are not naming name. Molds are another example of, if you make it easy for people to protest code, then they will process it with ease. But if you make it hard by having max value, but then interest maximum. It just gets harder and it’s, it’s unnecessary complexity. We also talk about that in the book, you just said cognitive load. You have the difference between intrinsic cognitive load and extraneous cognitive load. So intrinsic cognitive load is this problem is hard. It’s really hard to do this and this SSL algorithm or something, but extra cognitive load is like having maximum interest and. Value maximum just for no good reason, mixing up different name malls is going to add to your cognitive load, but it’s not gonna help you in any way. It’s just like extra low, extra fluff that you have to protests. So I think that’s also another concept in which chunking that we described in the poop. Okay. Or at, at many different level at a quite high level of design pattern, but also it’s a really low level of choosing a variable name.

Michaela: [00:34:56] Yeah. And I think what’s really valuable here is that we have some way where we take that a little bit out of this. Oh, this is objective. I can do whatever I want. Right. So readability, I mean the whole readability, um, area sometimes gets very, very loaded because there are some people that. Understand that it matters. And then there are a lot of people that hold against it and say, well, it doesn’t matter because it’s objective. Right. Whatever I want, I can do. It’s the same for the

Felienne: [00:35:26] compiler. Yeah. Or even that they might argue that my method is better because whereas it doesn’t really matter even. Yeah, exactly. Right.

Michaela: [00:35:36] And so I think having more research in that area and really understanding, give us a better understanding of, you know, Where is some merit to making it more coherent and making it more, you know, easier and where there’s really, it doesn’t matter. Right. So I think that that’s really, that’s really, that’s

Felienne: [00:35:53] really good. And, and the happy news is that other research also shows, which I think is really nice is once you choose a specific way of doing stuff, then people tend to stick with it. So people aren’t as, and you know, Oh, I know better than, than you might think. So if your team has. A way of choosing variable name, for example, it’s likely that people new to the code base without you really saying, Oh, welcome to our code page. This is how we do names that people will just pick it up. Like automatically if you’re, if you are deliberate about it. But of course, if you are all over the place and people don’t have any methods to click to, so then yeah. Then they will just do whatever, whatever they feel is better. So a little investments. Mine actually results in a more consistent code base that keeps going without any efforts. Yeah. And I think,

Michaela: [00:36:42] I mean, everybody will be happy because choosing name is hard and annoying and I hate it. Like every time, like I love programming, but then choosing my names from my variables, my methods it’s like, Oh, what should I pick?

Felienne: [00:36:59] it’s just low effort for you while, right.

Michaela: [00:37:01] Exactly. It’s like a pattern. It’s like an algorithm that you can take and you can just generate your methods and your names out of it. And I think that would be that’s great.

Felienne: [00:37:10] Yeah. That’s really cool. Yeah. So that’s chapter a chapter nine of the Pooka probably comes out. So you have to wait a little bits before that comes out. You know, what, what

Michaela: [00:37:20] I’m waiting for for the chapter about complex code. Can you explain what is complex code and how can we better get better in maybe not writing complex

Felienne: [00:37:30] reading complex code? Yeah. So the, the chapter about school flex goes, it has a number of techniques that come from natural language reading because often of course we say, Oh, programming is like math, or I like mathematics, but new research last year, a paper was. But published in nature, which is like one of the top journals for researchers that says that’s actually how well you can program is very much correlated with how well you can do natural language and less so correlated with your mathematical ability. Which of course, if you think about it, it makes all the sense in the world. It’s a programming language and. And 70% or something of tokens in a program will be natural language because you have key words are variable. So there are some sense students. So that led me to the idea that’s expressed most, most of my research that, Hey, maybe we can learn from how natural language, thus stuff. So maybe you remember that if you were in, when you were in high school, you had to look at non-fiction texts. Very often for, for German or English or Dutch. And they ask you a question like, Hey, here’s a newspaper article. What are the five biggest, most important lines? Or, Hey, here’s a newspaper article first. Don’t read it. Just look at the paper, look at the images, or just look at the structure. Look at the headlines now, or look at it for three minutes and, and see what you still remember or write the summary. These are all well established ways to deal with moon fiction texts and all these strategies can also be applied to code. So these strategies, these are, these are the exercises we have in the book where we ask you to look at codes for two seconds or a minute or something, just look at the code glance at it. And what is the first thing you see? What have you learned from just glancing at the codes? So that is a way that you can deal with, with complex codes. Look at the code for five minutes and try your best to write a summary. And of course what you take away says a lot about your prior knowledge. Hey, if I have to, I don’t really know art. So if I had to look as an art program, probably I will take away something different than if I look at the Python program. So it tells you something about your own level of ability, but clearly it also tells you something about the code. So these are all techniques that you can try. As I said, it’s just filling a toolbox that you can try to help you read more complex codes and it will always be hard. But if you, if your only strategy is. Read the goats. Oh, I don’t understand. Oh, read it again. Then, then you’re not really going to advance. So all these techniques we know that really support nonfiction, reading of texts are probably also likely in different friend’s situation to help you with reading cope.

Michaela: [00:40:14] Wow. I’m so looking forward to that, like I was reading your book by using a screen reader,

Felienne: [00:40:22] so cool.

Michaela: [00:40:24] And it was really cool. Like I was reading like the screen reader, wasn’t reading the book and I was reading at the same time and I actually. Experimented a little bit with two different screen readers. Like one was really highlighting the, the sentences and the words, which was very different for me to process the, the book because I was reading at the same time, the same thing that she said. And so it somehow hit my brain, like in two ways and then the other, but this was a very annoying screen reader, which also read a lot of other things. So then I switched. And here I really had to find it. So what I did and was like just glancing over the parts and was listening to it and could also take notes and everything, but I felt that he was very my attention and what I could take out of it was really enhanced. So I will, I will continue doing that anyway. So I’m really looking forward to, to read more of your book. One thing that I wanted to. Ask you maybe as the last question is a little bit about the process of writing your book, but I’m also writing a book and I probably have a very different process that you have, but how are you doing it? How do you come up with the chapters? How do you come up with these different exercises? How do you know what the readers really want to know?

Felienne: [00:41:35] Yeah, I think I sorta cheated advance because I was already giving a monster scores, had light and cold cycles. You have programming. And I’ve been, I gave this course already four times to different groups of students and the book is sort of my lecture notes. So the exercises are things I have tried out. I was in class with. Students and the storyline is more or less the storyline that I use in the course. So clearly that helps a lot because I already had this storyline and I had already read all those papers because I discussed them in class with students. So, so that was like the beginning of the process was I had a plan, of course. The book turned out really different from the lecture notes for various reasons. Because once you start writing stuff on paper, you also have to be precise in a really different way. So in lecture, I can just say, Oh, it’s more or less this, and you can read the paper. That’s your homework by. I know for you, you have to be really pretty. You have to really understand as a diff if you’re coughing a paper in a book, You have to understand as a different level, like what exactly was the experiment in class? You can say, Oh, for example, I have this part of how’s camel cage, a snake cage. You can just say, Oh, gamble case is better for comprehension, but snake gaze is quicker. That’s the result of the paper. That’s, that’s exactly what it says. Well, of course in this book, you have to say, Oh, how many people participated in this study and exactly what was there. So, and then you start diving in deeper and then it makes you reflect at a different level. So clearly many changes were made, but my, my biggest process was cheating by giving a course of activity, the same topics for a bunch of years, and then writing everything down in detail.

Michaela: [00:43:11] And so really last question now, not a last question, but one more. Why did you choose to go with a publisher and not self publish your book? Like nowadays everybody’s self-publishers books, right?

Felienne: [00:43:26] So, yeah, I think there’s a variety of reasons. Firstly, it just looks, I think, better on your resume to have a published book. I think by promotion committee will be more impressed by me having a privileged book on my name, especially by like an established author in your field. That’s going to be stronger than. Hey, I put a PDF on the internet. Uh, so, so that, that’s definitely one reason. And another reason is also that, of course I pay most of what I make through the publisher and that is load left for me, but it is worth it, I think, in terms of making the poop better. So I go to editors, both the development editor and also a technical editor does that, that was representing. And the goal audience and it’s technical, the first development at a service like, Oh, this is I, I wrote a scientific lecture notes, right. It’s yourself. Oh, this is way too theoretical. And you have to really dress up the theory with this sugar code layer because it’s for professionals. And of course, first I was like, yeah, And of course a professional can read a little bit about science, but yeah, you have to make it relevant for, for the daily practice practitioner or they won’t read it. So those two editors just really make the book a little better, even though the process was less fun because just writing a PDF, I’m putting it on lymphoma. It is easy. So I was as well. And a few times of course, this like this, I’m sure it’s like this for your book as well. Sometimes you’re like, Oh, this is going well. And then you’re like, Oh, I will never finish this. So the process was harder because I had to really rethink, okay, well, why is it valuable for people to know this? And of course, it’s really different if students, they enter your lecture hall at Piccolo. Now of course they will move, leave in the middle of lecture. That’s very unlikely. So you can. First builds up all the theory. And then the last 10 minutes, talk about why this is relevant because they aren’t, they are in your, in your power. They’re not leaving. Whereas of course, in the book I realized after I failed a few chapters that you get I’ll do 17 pages of theory, and then explain why it’s relevant. That just that structure of those aren’t work for practitioners. And I don’t think I would have really made that realization myself. Without the development editor are really used to selling books to practitioners. And then finally, also in terms of marketing, of course, then it really, it really helps. Of course I track my sales and I have a link, like my own link and a link from the publisher. And you do see that. They are reaching an audience that I’m not reaching and they are bringing sales, which is not only nice because you know, it would be nice if I make a bit of money out of the book. But also of course, what I want is that people know this little bit of cognitive science because I really truly believe that it’s just going to make them better and happier programmers. So that’s another reason that I, even though I have quite a following on social media, You do see that, that the publisher is better able to sell books through, to my target audience and then I will be myself. So, so those were, those were my reasons.

Michaela: [00:46:28] Yeah, I think there are valid reasons or things that are also going through my head. I haven’t made the decision yet. I’m also writing the book together with our better fertility. So it’s a collaborative decision and you’re always like, Oh, let’s do it this way. Oh, let’s do it the other way. But I think we still have some time to decide what you’re

Felienne: [00:46:45] going to do and it’s hard. And in any case, I would definitely recommend to, to, to ask for feedback. Very early. If I, if I can give you you and other people in the audience, maybe that are considering writing a book. And my first reader was the technical development editor of the, of the publisher, which was helpful because she slayed everything. As I said, because I had much too much theory in the beginning, but. In retrospect that they didn’t have to be the case. Right. You know, most of my friends are programmers, so I couldn’t have asked other people for a little bit of feedback that I, that I trust and like loads on the entire group, of course, but just some examples. And do they make sense? And what do you think of this order? I definitely made the mistake. That’s maybe common to people that are experts in something. I was like, I wrote a PhD thesis. I know how to write a book. It wasn’t, it wasn’t the same. So I thought I knew how to do it then, then I didn’t. So if you go with self publishing or with a publisher, doesn’t matter, but definitely reach out to all your friends and followers on Twitter for some dress reading, then it will be nicer than waiting until the ends and then having to overhaul everything.

Michaela: [00:47:53] Yeah. Yeah. I think that are great. Last words for this episode. I I’m so happy that you have been on my show. Filene talking, talking with me about all these ideas on how to learn program, how to understand code. I would love to talk again. Maybe I’m inviting you again to deep dive into some other areas and yeah. Um, maybe something, maybe one last thing that you want to tell my listeners. And

Felienne: [00:48:16] then there you go. Yeah. I think I said it a bunch of times, but I’ll say it again, like learning something new is really, really hard. So cut yourself a bit of Slack. Like even if you know. Everything about Java Python will still be hard. And even if you’re an expert by some programmer reading a Python program that you’ve never seen before by someone else, it will always be hard. So remember that you are an expert in one thing, but you’re still a beginner in something else. So take time and patience and use the tools you have and specifically reach out for tools because don’t make the mistake. Maybe like I did with my book, thinking on this will be easy because I did it once. Every new beginning is still hard and that’s okay. That’s like the way it is, you will get smarter than you already are. The only thing you can still learn is new knowledge in a different field.

Michaela: [00:49:10] Yeah. Thank you so much. So thank you for Dean for being on my show. Thank you so much.

Felienne: [00:49:14] Yeah, it was really nice to be on the show. Thanks for inviting me. Bye bye. Bye.

Michaela: [00:49:20] Before you go, let me tell you that my code review workshops are starting again. So if you want to transform your code review practices from bottleneck to superpower, check out my training at https://www.awesomecodereviews.com So, thank you for listening to another episode of the software engineering unlocked podcast. Don’t forget to subscribe and I talk to you again in two weeks. Bye.

 

Episode 34: Vulnerability disclosure with Katie Moussouris

In this episode, I talk with Katie Moussouris, founder and CEO of Luta Security.  Luta Security specializes in helping businesses and governments work with hackers and security researchers to better defend themselves from digital attacks. Katie is also an expert when it comes to bug bounty programs and how to successfully prepare organizations to implement a vulnerability disclosure program.

We talk about:

  • vulnerability disclosure,
  • the security challenges faced by military and government organizations,
  • her entrepreneurial path,
  • how to establish yourself as a hacker or security expert,
  • and how to build security in your software development process. 

Today’s episode is sponsored by ConfigCat – your favorite feature flag management tool to release more frequently with less risks!

Continue reading

Episode 33: From intern to CEO with agile testing expert Alex Schladebeck

In this episode, I talk to Alex Schladebeck, a testing expert, and a powerful voice in the tech community. Alex is the CEO of Bredex, a dev shop that offers tailor-made IT solutions but also specializes in quality assurance and testing.

A decade ago, Alex graduated in linguistic and came into tech by accident. So, I obviously have to ask her about her career transition, and testing.

What we talk about:

  • transitioning into tech from a non-traditional background
  • what it takes to get from an intern position to becoming the CEO 
  • which role testing plays at Bredex
  • how mob or ensemble programming is used to facilitate learning
  • how to lead remote software teams
Continue reading

Episode 32: Serverless is your competitive advantage

In this episode, I talk to Nader Dabit. Nader is a web and mobile developer, who specializes in building cross-platform and cloud-enabled applications. Right now, he works at Amazon Web Services, where he develops features in the client team and improves developer experience. Before, he founded his own training company, specializing in React Native, and trained engineers from organizations such as Microsoft, Amazon, the US Army, and many more.

We talk about:

  • how he managed to build a following on almost every popular social platform,
  • how he got started with his own training company focusing on React Native
  • what serverless means, and why you should care about it,
  • how to build an MVP using a serverless-first mindset,
  • and how frontend developers can leverage serverless technologies to become a full-stack developer.
Continue reading

Episode 31: Combatting tech debt in war rooms

In this episode, I talk to Tomasz Łakomy, a senior frontend engineer at OLX Group. Tomasz is fascinated about teaching everything he knows and has over 170 video tutorials.  

We talk about:

  • how they develop, test, and reviews software at OLX group,  
  • what war rooms are and how they help to combat technical debt,
  • how he managed to create over 170 video tutorials about software engineering,
  • why he is AWS certified as a front-end engineer, and
  • how skydiving helped him to be a better software developer.
Continue reading

Episode 30: How I got into FAANG companies without a CS degree

In this episode, I talk to Ben Lesh. Ben is a Senior Software engineer at Citadel Securities. Before that, Ben worked amongst other companies, at Google and Netflix. Ben is also the Project Lead for RxJS. RxJS is a library for composing asynchronous and event-based programs by using observable sequences.

We talk about:

  • how he got into several FAANG companies without a CS degree, 
  • the importance of building relationships, and an online brand,
  • the benefits of being helpful and kind to others,
  • the differences in engineering practices at Google, Netflix, and Citadel Securities, and
  • what RX.js is and why you might need it. 
Continue reading

Episode 29: No mocks allowed – A testing discussion with Kent C. Dodds

In this episode, I talk to Kent C. Dodds, a software engineer, and teacher. Before starting his entrepreneurial journey, Kent has been working for PayPal. He is a major open source contributor and also the creator and maintainer of the widely used open-source testing-library.

Code that he writes is used by millions of people around the world, and he also teaches thousands of engineers how to test their JavaScript systems, and how to work with React.

We talk about:

  • Why you should not mock your software system during testing,
  • how “testing library” helps create more meaningful and maintainable tests,
  • if and how manual testing is still needed to increase your confidence in the software system.
Continue reading

Episode 28: How design systems help create an inclusive user experience at Github

In this episode, I talk to Diana Mounter, the Director of Design Infrastructure at GitHub. Diana traveled the world and lived in many different countries – even continents. She started as a print designer and spent some time in government before she got into web and design. Now, she leads the design systems at GitHub.

We talk about:

  • what design systems are and why we need them,
  • how GitHub deals with legacy code and refactoring.
  • how the designer role interplays with other roles at GitHub,
  • how and why designers do code reviews,
  • and how GitHub strives for inclusive designs that make everyone feel like an expert.
Continue reading

Episode 27: How I got a job at Spotify during a pandemic – Emma Bostian

In this episode, I talk to Emma Bostian, who recently started as a software engineer at Spotify. And Emma is the kind of person, that not only applies and interviews for jobs, but at the same time writes a complete book about her interviewing experience hunting for this dream job. This book sold so well, that she could pay back all her medical debt. Before joining Spotify, she worked for LogMeIn, and IBM. She won competitions and moved countries several times.

We talk about:

  • her interview experience with Spotify and Google,
  • her experience moving countries during a global pandemic,
  • what makes for a great onboarding experience and
  • how we can take action to make sure workplaces are friendly and welcoming.
Continue reading