In today's episode, we sat down with Nicole Archambault to talk about problem solving and the steps to take when solving a coding problem. In this part 1 of our interview with Nicole, we dive into her background in tech and go over the first steps to problem solving.
Build internal tools, remarkably fast. Connect to anything w/ an API. Drag-and-drop React components. Write JS anywhere.
Check them out over at https://retool.com/devtea
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
Hey everyone, I'm very excited about today's episode and interview with Nicole Archambault. I look up to Nicole in so many ways. She is the creator of Lavia and Code. Hopefully I said that right. Which is both a blog and a podcast. She focuses on problem solving and the steps to take when you are solving problems particularly when you are coding a problem. It sounds like a very straightforward idea, but I'm telling you right now, the steps that she provides for actually solving these problems are going to help you think through problem solving more methodically. And we actually go through every single one of those steps in this interview. Make sure you subscribe and whatever podcasting app you're currently using so you don't miss out on the second part of my interview. Let's get straight into this chat with Nicole Archambault. Nicole, welcome to the show. Thank you so much for having me Jonathan. I'm actually I've been a long time fan so we've had a chance to talk. I'm really excited to be here today. I'm excited for you to be here too. We had a really good conversation, pre-roll here and I was like, you know what, we should probably stop because you said the same thing. We should capture some of this on the show. So I'm excited for other people to hear your story, but I want to give you the chance to kind of give you a 30 second pitch on what it is that you do. So I am here today because I have kind of accidentally, as I said to Jonathan, I have kind of accidentally created my dream career. And I have an entire story behind it that is actually I'm already thinking about it and more that people give me feedback on it. It's pretty amazing. And it speaks a lot to the type of perseverance that I've had getting to this place in my career. But I am a self-taught developer that a front end developer and I had changed careers back in 2015 from customer service. And there's a whole lot in between there kind of which I'll weave in. But today I am actually an educational technology entrepreneur. I work with online courses and the audience that I have, the students that I have, and the people that I want to teach and fortify are a lot of the folks that are in your audience as well. Self-taught coders, new developers, you know, both front and back end, that I love to deliver content to them. That is very fundamental and like problem solving, which we'll be talking about today. And auto-diadactism as well be able to teach yourself. And so now I'm in the process of creating online courses because I can teach so many more people that way. And so that's kind of me and a nutshell as far as where I am right this moment. That's awesome. I mean, I think a lot of people probably identify with at least one part of that story, the short story, but I think you have a much longer, much more detailed story that we're going to get into here on this show as to how you ended up where you are today. But I want to talk for a moment about learning as a practice. This is one of the very earliest episodes of the show. I think it was like episode number three or something. And we're at like 850. So that is it. It's been like a constant theme. And I think that any engineer will tell you and it's not even a trendy thing to say that a huge part of what we do as engineers is just learning. We're just constantly learning. And for some people that is very practical, quite literally just learning how to write code in a particular language or how to use this special tool. For other people, it's more of a way of life. It's a philosophy. How they approach a project is, well, what can we learn here? So I'm interested to know how has learning played a key role in your story? Ooh, that's a good setup for me because I actually do, as I mentioned, have a really powerful story there. So I kind of to start off, I was diagnosed with a whole veritable cornucopia of neurodivergence back at 32 years old. So it actually was only a few years ago. And that is kind of a foundational part of my struggle that I came from which ties into how I learned to learn. And that was something I had to focus in on. But I hated school. I really, really did. Academia was stressful to me. I was having struggles because I'm on the autism spectrum. And that was again, that diagnosed until I was 32. And I look back and now when I see, oh my god, this is why I hated it so much. I was super hypersensory. I was all in my own head all the time. My executive function was garbage. But I still managed to really push myself through. But I feel like every time that I had to, for example, study for a test, it was like you would write up on the blackboard everything that you needed to know. And as soon as the test was over, I need to erase it. And my memory was really not coming into play. I didn't know how to learn deliberately at that point, which is something that I work very closely with now. And learning deliberately, along with being a lifelong learner, is a powerful combination. Because you're going to be driven by curiosity, the entirety of your education and your career. And I tell people that and their eyes kind of light up because maybe they thought about, I teach with emotion, okay? And emotion is what helps people to really learn and embed information in their memory. And I didn't have any of those skills growing up, but I still managed to get, I got myself to Wellesley College. And you want to talk about how, if high school was how, Wellesley just kicked it out, you know, to 12 and then ripped off the dial. Like, I still had not learned how to learn. And it turned out that I'm a much more auditory and a visual learner and a tactile learner than what I was getting in your traditional classroom. So that obviously was hell. And it actually affected my career in that, my freshman year. I was dating a guy that was doing it, Mr. Polytuck. And he was doing a computer science major. And up to that point, I had only really known about, you know, IT, things like that. And so a little bit of web development from, you know, my space, live journal. We have a whole generation of people that have gone through that. And, but I arrived here in my computer science degree at Wellesley. And we started out with the intro we were programming with Java, which was an interesting place to start as I realized now them in the industry. But there were no web concepts that were involved, that were included. It was primarily algorithmic and data structures. And I struggled from the get go. And I kept blaming myself and just saying, I thought I was so good with computers. What the heck happened here? Right. And it's like you start to really doubt yourself. And I got to the point finally. And here's the interesting thing, Jonathan and audience. I heard about this after the fact. So I got caught up at data structures and algorithms. So that was the actual course. And it was CS230 and that was where I started to fall apart because I could not contextualize based on another, you know, part of my charitable cornucopia is a nonverbal learning disability. And that means that it makes it very difficult for me to be able to contextualize data that I can't actually see or concepts that I can't actually see. Until I can drop a mental model of it, it's basically lost on me. It will not click. And then once I finally can do it, it clicks into place. So that was another component of my struggle. I ended up dropping out of the computer science degree and switching to political science and Spanish double major. And I felt so defeated. It was, I was working at the on campus technology center, but I feel like I checked out kind of emotionally. And when it came in terms of tech, because I loved hardware, which was predominantly what I was working with there and projects. But it just wasn't the same. It wasn't the same programmatic problem solving, which, as it turned out to, I didn't have those skills developed yet. And so here I am. I crawl across the finish lines. I tell people I was a well-sleeved survivor. And I graduated right into the recession. So this was 2007. And we know the graduates there are going to be facing a lot of similarities. And maybe worse now, but being, I was about to say, being born, which it kind of feels like, but being released into the wild from academia into a recession is just so hard. It took years for me to get myself back on my feet. You know, I was working temp jobs. I was competing with folks with their master's degrees for a $15 an hour job. And that's really how absurd it was. You can't start a career in that kind of environment. But eventually, again, if nothing else I'm determined, I am persevering. I get knocked down all the time that I get back up. And I'm at this point where I had finally made a few moves. It was five years after five or six years after I graduated. That's how long it took me to get to the point where I could finally actually call what I was doing a career. And I got in stock basically in administrative. And I did make a move. My last job in administrative and customer service was at a tech company. And I had been sought out while I was working at another company. And I just kind of got excited. I got a good feeling about it. And they were a startup in Portland, Oregon, where I was living at the time. And I listened to what they were saying. And I kept getting more and more exciting. They were a web-based application. I'm like, oh my god, there's so much more to the web now than. You know, the HTML with the inline CSS that I've been writing back in the 90s. And really, you know, are the early 2000s and really hadn't seen since. And the job just sounded like something that was so exciting, which was, I mean, really exciting compared to what I was doing, which was working at this old-ass maritime organization basically Portland's a big maritime area. So I was like, yes, let's get started with tech. And we got started all these like new folks in a new office. And we had this app. And the app was a point of sales service done not as well as the name competitors. So they're still around. And the stuff that I was learning, oh my goodness, I was so excited to go into work. And he was known as working customer service, I was getting to work with tech. And at one point I was promoted to a manager. So I got some managerial experience. First manager there. And then a lot of things were happening. We know startups. They can be volatile. It's, yeah, there was a lot of contributing factors. And in 2015 in May, I was like, oh, and oh, man, as soon as I say that. But every time that I think about that moment that I got fired, it was such a pivotal moment in my life. Like they brought me in the room. It was funny. I messaged one of my team members that I had. I was managing a team of like eight people. And I managed one. And I just started feeling it wasn't going to end up well. And I messaged him on Slack. You know, remember me fondly. And those were the words that I got. I was being a little bit, you know, exaggerated. I am, they brought everything out to me, you know, in one door out the other. And that was it. And I'm sitting here with all these bags in my hands and thinking to myself, what the hell am I going to do now? You know, I had no clue what my next move was. But I did take a little bit of time to kind of decompress and process everything. But I had also fortuitously, I had found a company that was right there in Portland. And that company was called Treehouse. And so I don't know how many, or if you or your listeners are familiar with Treehouse, they are by far my favorite learned code platform. And totally familiar. Yeah. Hopefully. They're so wonderful. Actually fun fact. My picture. I saw it just randomly in some YouTube video on DevSlide, I think. And when you come off the elevator in the Portland Treehouse office, my picture as a student's success story is directly across from it. They have an entire wall of their people. And I happen to see it in a video and was like, oh my goodness, that's me. What are the odds of that? No, well, yeah. Once I started learning with them, I took off. To the end, it was crazy. They were catering to my preferred learning styles at that point. People still argue whether or not that's a thing. I'm going to tell you right now, at least to somebody who is quite neurodivergent, it is most definitely a thing. I could not learn from textbooks. I had difficulty. I mean, if I really take my time, I could, but remember, I didn't have these disabilities diagnosed before. I couldn't get accommodations like untimed testing, you know, having as much time as I needed to learn. It turns out I can learn all of these computer science concepts perfectly fine, but I didn't have the time or the control over my educational environment to do so. And of course, I started asking myself, I was like obsessed with Treehouse. I got started and I kept going and I'm in like the 99 percentile of, you know, their students and as far as points and badges. And I was just so excited and driven. That was that. I mean, I was watching videos. I could hear it. I got my hand started and that was my entrance to, you know, answering that question of kind of what black magic is this that allowed me to learn something that I couldn't seem to learn before. And the answer to that was educational technology. Now, what did I say the first part of my career is now educational technology entrepreneur. There you go. Ties right in beautifully. Now, another part, which is tied into where I'm going to be talking about problem solving today. I didn't know and nobody had taught me back when I was going through my CS degree about problem solving skills. They, I had no clue. They, I wasn't even seeing the algorithms as problems. I was almost too freaked out and I was just looking to like, to, I don't even know what cheat. That doesn't really sound all that great. But like, I don't even know. I was thinking about the code and I jump right in and try and write stuff and I just get so frustrated. And it wasn't until I believe I wrote it in 2015. So I was probably about six months in and I are not even at that point, maybe four. And I had written this blog post that became kind of a part of my little brand, Love Young Code. I was blogging from the very beginning when I started learning to code. I love writing anyway. And I really wanted to document what I was learning so I could solidify it. Another thing that works very well for me. And I wrote a blog post that was called how I was it scaled that how I scaled back on learning to code and ramped up on learning problem solving. And this was around the point that I recognized I was getting straight up blank screen paralysis. I sat there and I shared it that screen and code does not write itself. It turns out. And here I was, you know, having to turn around and learn both how to learn and how I learned in particular. And also how to actually approach a problem. And from everything that I learned in answering those two questions that had affected me throughout my life, I inadvertently came across the perfect career for myself, which I had to build. Because I knew how I wanted to teach people. And I knew how I was going to get it across to them. And I needed complete control over that narrative. So that is a huge part. And you know, kind of afterwards I did get my first dev job, my first time. It was kind of full stack admittedly, but it was weird. They used cold fusion, which I was like, I also used JavaScript there, but I was like, what is this? And they didn't even use version control. It was like this little two dudes and a dog web development shop down on Cape Cod. Massachusetts that did real estate software. But you know what? It was still cool. I got to ask questions. I learned a lot of stuff. And it's kind of every new dev's dream or actually any dev's dream to get paid developer money to learn. Yeah. Absolutely. Yeah. I know. That's what I keep telling people. Your eyes light up. It's like that first job is going to be your forever job probably, but it's going to be the job that gets you that bigger check and you got to learn on it. And you're going to be excited and you're going to be just moving forward for, you know, from that point on. And so that is kind of the story. I can't even say TLDR, but that's the main part of the story that led me to where I am right now. When somebody asks, how did you get to that exactly teaching these foundational skills, like problem solving and auto-diagnetic skills being able to teach yourself? That's how I had struggles. I overcame them. And now I want to share what I know. And that's basically my entire career now is making online courses and doing the coaching. So at all fits in, I have crafted my dream career because I never saw anything that really fit me and I fit me. And I tell folks to, you know, if you walk into a room and there's nobody else there, it doesn't mean you're in the wrong room. That means maybe if you know for a fact that that's it, it feels right, set up camp, maybe more will come. And that was kind of that eye-opening part for me when I went. I tried freelancing for the after that dev job too. And I had the client from hell is like my third client and I was just like, nope, screw this. I just felt so out of control still. So yeah, and then it was entrepreneurship. And I'm also hosting my podcast. I have the Lebian Code podcast that I started in, wow, that's almost four years now. I think I started in September. Congratulations. That's awesome. Thank you. I've got a lot of stuff related to some of the more, one of the things that I love about your podcast in particular, Jonathan, is that you focus on the emotional intelligence part of being a developer, of being a human being. You know, I talk to people as human beings, not everything is just limited to code. That is going to be critical to your career. Most of the stuff is going to touch on other areas of your life as well. And those are the messages that I get really clearly from your little bite size messages. I love it. I wish I could do the eight minute, but I just can't. I am way too in my own head. And I love it. But yeah, that's kind of my story. That's so awesome. You know, on that point, I think I just want to focus in on something you just said that I think is so critical. Not to fast forward pass your story. I think your story is absolutely incredible. And thank you. Very inspiring for people who are listening right now, who they themselves have their own cornucopia of whatever type. And you know, they may feel unfit or they may feel out of the norm. I am such a normal developer. So I can't inspire people in that particular regard. But I think everybody has something that they face that makes them feel at some kind of disadvantage, right? And whether that is your own confidence issues, which is something that I certainly deal with as an engineer, manager, especially, right? You're being on the spectrum or anything in between. Yeah, being a human being, I would tend to say. Yeah, yeah. And that brings me to the next point, which is this idea that all of this is integrated. To say that we have different, you know, distinctly different types of intelligence, I think that it's all integrated. And in the sense that you bring your emotional intelligence in the same way and you cannot bring only that, you can't turn it off. You can't suddenly say, well, I'm going to turn off my feelings because I have to code. You will have emotions while you're coding. That's such a strange thing. People don't often deal with it. But the reality is you're not a machine and if you try to treat yourself or try to fit yourself into the mold of a machine, if you try to shoehorn the human experience into this production machine kind of way of thinking, it's going to go poorly. It's going to go really poorly. It does. And so I like to talk about emotional intelligence, not because I think it should be promoted, but because I think you can't have any kind of intelligence without including emotional intelligence, right? In the same way. It's such a great plan. You know, I don't think that you can be a complete human without experiencing those emotions while you code. You're going to get mad and want to throw your computer across the room sometimes, right? But there's going to be times of joy and you should feel good. You should feel okay. Feeling those joyful moments when you suddenly happen at Piffini, you're going to feel moments of jealousy of your coworkers or of other companies. Are you on my mailing list? This is legitimately, I'm so sorry not to interrupt. You're hitting on exact keywords. I just sent out today's Wednesday. I just sent out a newsletter. I have a great newsletter. You should subscribe. I'll kind of give some links to Jonathan. It's called Loveean Code. My brand translates to Life and Code in French. My newsletter is called Life and Code. I really want to emphasize that life part. I wasn't planning on doing this, but actually, it piggybacks beautifully off of what you're just talking about in terms of emotions because I'm going to actually read what I wrote. It was a little bit long, but I think it hits it right on that. I love to write too, and this was very stream of consciousness, but I got so, I must have gotten like a dozen messages back. Jonathan, people, I've never gotten that much engagement in my life, and it was by far, as I mentioned before, do you, my most vulnerable post yet? So actually, I just pulled it up. I open up every email that I send out in the newsletter with Happy Monday Dev Friend. I want to talk with you this week about a kind of messy issue that I've been having lately. It's kind of long, but I promise that it's important. So let's talk about negative human emotions for a moment. I'm having a really rough time navigating some tricky social situations that I have zero context for, and they're making me feel things I don't like. I've received a late-life Asperger Syndrome Autism Spectrum diagnosis in 2017, which explained so much of my life's experiences, but it particularly explained my struggles. I'm also a lot more aware of the social issues that I face now, and why I'm facing them, and I see the hand that I've been dealt, but it doesn't make it any less stressful to play with. And a lot of the time, it's that my emotions as a person on the spectrum don't seem to translate it to human. I don't know if that makes a whole lot of sense, but it hits the right on the head for me. It's always rooted, though, in kind of my inherent ineptitude, in reading and understanding what other people are thinking. And a lot of the time, I don't know what's expected of me, and it gets overwhelming really fast. I still have legitimate meltdowns. At 35 years old, almost I cry, I isolate, and it really sucks. And so basically, this whole situation has been stressing me out for about the past month, and it just got more and more stressful until I nearly had a breakdown. I needed to figure out how to not feel so strongly. I needed to figure out how to shut these emotions off somehow. So I do weekly therapy for nine and a half years. I realized this week that I've been doing, and it has literally saved my life. So I reached out to my therapist for a bonus session that week. And oh my god, I was complete waterworks the entire time. And I was explained to her that so often, people don't respond to me the way that I want them to. And it really jars me. Do these things, and I don't understand why they do them. Like that's not something that I would personally ever think to do. And then it makes me wonder, well, how different is the rest of their brain from mine? You know, if that's how they think. And also people were hurting me. You know, over the last couple of months, I've been a lot more social, so you open yourself up to that sort of thing. But they hurt me and it's hard not to blame yourself because I'm still confused as to what happened. So my therapist listened, and she was really, really, really understanding. But while I was exploring kind of those emotions out loud, she gave me some advice that I didn't really want to hear. And that advice was it turns out there's no way to shut those negative emotions off. It just got to sit with them. Damn it. And I need to teach myself to respond to those stressors in the emotions that arises a result in a healthy way. People are never going to be 100% predictable. And that's just life. You know, there's absolutely nothing I can do about that. And I can speak personally this too. I could maladapt, you know, that's responding in harmful ways to something that you're experiencing those emotions. And I've done a lot of that in my life. That is for sure because I'm not perfect. And life is really tough sometimes as we know. And acting out and blaming other things or people is just easy to do. It's being able to sit with those emotions though that will help me to make my social life a little less stressful, maybe eventually a lot less stressful. I don't know about that. I'll hope for a little. But that's the hard part is just sitting with them. And you started to list some of those emotions of Jonathan, which is when I kind of perked up because you're hanging on them. And I said, I've been recognizing all of these negative emotions, fear, anger, frustration, jealousy, sadness, insecurity, and just so many more. And those are harsh emotions to feel. And when I was saying those emotions out loud to out loud, I realized that those were also common and prominent emotions that I experienced during my career transition while I was teaching myself web development. Same exact emotions, just originating from different sources and experiences. In my first six months learning to code, I was angry at myself a lot of the time. I was frustrated that I couldn't seem to solve those code challenges that I was struggling with or to keep up a project once I got and started once it got hard. I was jealous, which jealousy is a really ugly emotion to me. It's very associated with shame because it's so petty. I was so jealous of other people's projects, especially when they looked so much more polished and professional than mine did. And I was sad and really afraid too. I didn't have a job yet. I didn't have a job and I didn't know if I was going to be able to pull this off this career transition. And that scared the hell out of me. I really wish that I had known back then that fighting those emotions was an exercise in futility. 100%. I wish I had had the therapy skills then, but it's taken me nine and a half years of hard work to get there. What I did back then was kind of swallow them down and then I let them fester. I remember that I was having nightmares for months about being unprepared for and messing up a job interview. And at that point in time, again, totally transparent because we're human beings, I was actually drinking a lot to us, going out with friends. Again, those maladaptive behaviors, we feel a lot of shame about those. So it becomes a cycle, right? So the lesson that I want your listeners and for my newsletter audience to take away from this whole issue that I had written about is that you need to get comfortable with being uncomfortable. When you feel uncomfortable, it's generally going to be accompanied by those other also negative emotions. You need to stop and recognize them for what they are. They're painful human emotions. And you also need to recognize that all you have control over is how you respond to them. And you know the crazy part is to that I recognize this. I teach all of my students this. You know, you have to get comfortable with getting uncomfortable. I've been throwing that out there, but of course you fail to apply it to your own life. I just didn't connect the dots. And I realize now that it's not just about code or anything else in particular. Like we said, it's about life. It's about us, about the human experience and our ability to respond to obstacles in a healthy way that won't derail you ultimately and leave you broken, right? If you have had a job as an engineer, then you've probably had the chance to build internal tooling. Now, if we're being honest, most engineers don't love building internal tools. Maybe at first it can be a little bit exciting. It's fun to build something that people you know are actually going to use, but eventually you're just building admin panels for crud operations and customer support or inventory management tools. Integrating with all of these things, it can be kind of a thinkless kind of work, right? Every business runs off of these though. So we have to have them, but no one really wants to deal with the headache of building and maintaining those kinds of tools. When you think about it, internally tools are mostly comprised of the same building blocks, tables, drop downs, buttons, text inputs, and forms and that kind of thing. And they all are pretty much intended to connect to some kind of data source and to some kind of code to manipulate that data source and to function as intended. This is where re-tool can help. Re-tool gives you a drag and drop interface. So engineers like you can build internal apps and the UIs in hours rather than days and spend more time building features your customers will see. It connects with any database, any API. For example, to pull in data from Postgres, you can just write a query and drag a table onto the canvas. And you can also write JavaScript pretty much anywhere inside of re-tool to manipulate your data any way you would like. Go and check it out. Head over to re-tool.com slash devt to get started with re-tool today. Thanks again to re-tool for sponsoring today's episode of Developer Tea. You know, I don't know that there is one way. I mean, if you think about the physics, the physics of those feelings, and really break it down to the reality of what causes our emotions, there are so many ways that we deal with our emotions. And in fact, emotions are the labels that we have for them are just labels that we have to explain the same phenomenon that another human is feeling. We literally feel our emotions. And so it's a very physical experience. And this is something that is often, you know, especially, I won't say all engineers. A lot of engineers I know, they try to separate their physical experience from their, we'll call it their mental experience. Or even their kind of thinking experience, right? Their consciousness. And our consciousness and, man, this is getting way, way out there, isn't it? Not at all. You'd be like, all of this, it fits in. I see exactly where you're going. Well, because so much of our work lives in that conscious thinking space. So we don't, we try to hold up this barrier, this kind of down as if our emotions are a river and we can't allow it to flood over into the physical experience, I'm sorry, into the thinking experience. And so a lot of times, even the way that I try to process my emotions is to think about them, right? It's right. What can I do? What process can I run in my brain to break this emotion down and root out the bad parts and leave the good parts and then move forward, right? But that's not really how the emotional experience works. And when I say works, I mean, emotions don't really care about your thought processes per se, right? Now, I'm getting into territory that I need to be careful of because I'm not a counselor. And certainly there are therapies that are based entirely on thinking through things, right? So cognitive behavioral therapy is probably the most prominent example of that. But we can't control just through our thoughts. I guess that's kind of the summary of what I'm thinking is we can't control those emotions directly. There's not a tuning knob where you can say, okay, I'm going to turn the sadness down, right? Turn the happiness up. And so what you're doing. Right, exactly. So what we're going to do in those is finding something that does that for us. Sometimes, like you said, maladapt, we will go and we'll find something that increases our serotonin, right? Or we'll find something that changes our chemistry in such a way that it resolves the feeling for us. And you know, our brains don't really know the difference between that and real what we would call healthy resolution of those things. And so all of these feelings, we bring to work every day, right? And so it's very easy, especially knowledge work, especially as engineers. It's very easy to try to sequester those emotions and deal with them at five o'clock when you get off. I think great developers, they integrate that. They integrate those emotions. They integrate the way that they deal with them into their work. And I think this is particularly true for managers to say, hey, you know what? No, you're not going to bury those until five o'clock. We're going to talk about them right now. Like we're going to want to necessarily force you into it. But I'm going to give you the open space to be fully human while you're at work, not just treating you like the machine that I want you to be and ask you to produce code and devoid yourself of all those emotions to later. Absolutely. You hit the nail on the head repeatedly. It's the way, basically the way that I understand it is that our thoughts inform our actions and our actions create our reality. And so by connection, your thoughts create your reality. And one of the hardest things for me to wrap my head around forever was that I actually had control over my reality. You know, I had the control over my reality had to be, for instance, that I wanted to teach myself to code. And I wanted to change careers. Well, my thoughts needed to be pushing me forward. They needed to be positive and I think that's a huge reason why I actually was able to succeed. And I never had a doubt that I would succeed despite the fact that I experience quite low self-confidence and a lot of other areas that I'm still working through. But my thoughts were consistently that if other people can do it and this very much the growth mindset, if other people can do it, well, why the hell can I? And you know, that kept pushing me forward, but as I started to get further in and also your thoughts create your context. So we see something in the world around us and we bring it into ourselves by relating it to something that we already know. So everybody is going to have a different context for learning even the same bits of information. And there was just so many variables here. When I studied these concepts, you know, under some of the best I had Barbara Oakley on, you know, talking about learning and connecting different ideas to one another and how powerful that can be. And then when you combine that with the emotional intelligence and the mindfulness to be able to be aware while you're there in the moment at the office, not checked out, very much present and very much keeping an eye on how you're feeling because if you don't do that, we've run into all kinds of issues, right? In terms of behavioral problems, social interaction issues. I mean, when I was feeling misunderstood in the office and this was really when I was brand new in therapy, when I was feeling misunderstood, I lashed out at one of my co-workers one time and I didn't get written up, but I'm pretty certain that that contributed to me getting fired. It was that anger that came forward and feeling betrayed and putting that label on all those emotions. If I had been more mindful about how I was feeling, I would have responded to it in a very different way. So yeah, I mean, and it can be connected. The same principles can be connected to somebody who just goes in and a lot of people enter this industry thinking also that it's just going to be writing code, sitting there by yourself, but so much of our personalities go into our code. The way that we create our creative process needs to be something that we're mindful of. Every part, really, we cannot go wrong by introducing emotional intelligence, compassion, which is a huge part of emotional intelligence as well, simply being aware of the fact that other people are around you and they might not be something that spectrum votes really struggle with them. It's called theory of mind that other people don't think the way that you do. And that's a tough one for me to wrap my head around natively. And it's very overwhelming. Learning about theory of mind answered so much of my life because I got, like I said in the news, that are so overwhelmed. So those social interactions and proving those by being mindful, it'll improve your relationship with not only yourself, but the world around you, and that includes the people, the legacy that you leave, all of it. So you really can't go wrong being out here like we are in this podcast episode and talking about this openly because it's not really fluff. It's not a whole bunch of soft skills, so to speak. These being a more emotionally intelligent person will help you in all areas of your life. And that includes your work life and your career and your education. I need to code as well. And we're constantly learning. So you got to be mindful of the learning process. Yeah, there's so much intertwined here. Mm-hmm. Yeah. It is learning on its own. Again, we already talked about integration on this episode. And to say that we engage in learning as if it's a singular activity, learning is something that our brains are kind of wired to do always. We're always, it's kind of the whole function of the brain is, I say it's the whole function. It's a huge part of what our brains do. It's responding to stimuli is what our brains do. And encountering new information is stimuli. And our brain wants to do something with it. So then we introduce concepts like, you know, learning very intentionally and deliberately and getting the most out of that stimuli. You know, what your brain does in response to that stimuli. But yeah, that is the sole responsibility of the brain, basically. It's to respond to stimuli. And we have control over that response, although I think a lot of people believe and I was one. So I can say that, you know, that we don't have that capacity. And that is the growth mindset. We have the ability to change how we respond to the stimuli that is inevitably going to happen and trigger our brain to go, whoa, or yay, or, you know, runaways, Jay put, it's, you know, happy or sad. It's tied to all of those things. So the more intentional you are about creating your reality, the more you'll be aware of what you can do and how you can change your responses in order to make your life a little bit easier and the lives of people around you. Trust me. I'm going to go in therapy because of other people. This has been excellent. I want to kind of shift our focus a little bit. It's almost, I feel like a 180 here. But it feels about learning. And you know, I love this idea that our brains are kind of geared to deal with stimuli and to respond to that and sometimes do adapt in response to that, right? And some of the dealing with stimuli is to change the structure of the brain itself. Yes. And so much about what we do as engineers is about trying to decode whatever stimuli is coming at us. Sometimes it's a very strange or novel stimuli. So you have a lot of thought that you've put into the problem solving process as an engineer. I love you to share your specifically your eight steps that you have referred to before the show began. Can you tell me what that is and then we'll walk through those steps together? Yeah, definitely. These steps I put together, I did during the course of my learning about problem solving when I kind of banged that sudden turn inside to go toward problem solving. Now I was able to kind of, I think I changed the number at one point. I kind of condensed a couple of steps. But the eight steps that I have here are step one. You want to read and understand the problem. And now this sounds so basic, but I'm amazed at how few people actually understand the true intention of the step by and again, we respond to stimuli by reading this out loud to yourself at least, I tell folks at least three times, your brain is going to start to wake up to this problem. Kind of like a warm up. You know, you're doing a little warm up. You are introducing yourself to this issue and then the second time around. Your brain is responding to stimuli that it's already encountered, right? And then the third time around, it's starting to build on it. So you're really fortifying that. And that's a huge, that's your first step. You know, when I was experiencing my blank screen paralysis really rampant, when I was learning it and actually I don't deal with it anymore because I don't face up because I always have a first step. And that is just to start by reading and making sure you understand it. Step two, piggybacks off of that, but it takes a step further. You're going to rephrase the problem. Now this is something that not very many people do, but I challenge myself to do it any time that I'm learning anything is to show your real deep understanding of a concept. You should be able to put it into different terms in a way that still makes sense. But basically, you're attaching it to a different context. So the point still gets across. Maybe the words are different, the terminology that you're using, but it still clicks as a concept. So rephrasing that problem also needs to be in a way that really works for you. Sometimes I've done some examples in my course and in group coaching where I'll break it down and I like to use kind of some bullet points. I like to clearly define input and output and like capitals, what type of data structure we're expecting, what kind of data structure is going out. So it's really rephrasing everything. And then that will set up what we're doing forward. That in just rephrasing it is going to easy right into that step. And step three is to identify your input, your output and your variables. So what I mean by this, it's usually pretty clear to people what input now put me in. I like to very clearly say, okay, we're expecting a data structure. And then it is going to represent this, so I'm using plain English to remind myself at a glance, what are we expecting? And then to remind myself to glance also, what are we needing to get back? And what are we looking for? You know, sometimes you won't return, for example, the same data structure as you're putting in a lot of the time you own. So something like that will help to set your expectations. Now the part that that trips folks up is that they're like, well, what about the variables part? Well, here's the thing that I teach folks. You can start thinking about variables. So key points in your program, in your solution, where you're going to want to hold on to some kind of information. You're not going to get them all perfect right off the bat. But again, remember this kind of the me simple of doing, you know, setting up for writing your code. And by identifying, you know, for example, maybe at this point, I'm going to need this information to put in somewhere else. Okay, we're going to want to set up a variable for that. So you're just getting a sense of what your approach is going to look like. Step four is to break down the problem. Now, a lot of people stop here after they, if they do this step at all, and a lot of new folks will look at the big problem and get paralyzed, like I said, that link screen paralysis and they get turned off from it or they just panic. You can't really focus while you're panicking. You cannot do both things at the same time. So to break it down is such an important step. And you need to also understand that you're going to have to probably make several passes at it. And one of the analogies that I tend to use is going grocery shopping. All right. We know the term going grocery shopping kind of for the outcome. We know at the end you're going to have groceries. If we need to focus in on that process as well. So in this case, that would be like writing a function, you know, to go grocery shopping. And if you were to start off the top of your head, what are the steps involved with going grocery shopping? Well, you're going to go to the grocery store. You're going to buy the things and then you're going to take them home, you know, like load them up your car and take them home. That's one pass. Okay. Let's take another pass and see what we could have broken down further. Sometimes you might not need to break it down but so far. But in this case, for example, you might have to make a shopping list first. You might have to, you have to get in your car clearly to get there. You get in there, maybe you have to grab a cart, a shopping cart. You need to go in and then you need to pick your items and put them in the cart. You need to pay for them, go back outside, load up your groceries, return the cart, drive home, maybe even put them away. Depending on what's expected, you know, to kind of be in there as kind of a start and a finish point for your program. But it's no different with really writing the code. You see that once you start to break down all those steps, all those steps are tiny. You know, if there were one line of code, maybe. So for, I mean, I guess I just thought of this. But if for example, your grocery cart were to be in a raya or something, you'd be pushing stuff to your array and that could be a step, you know, that you would include, it could be one line of code for one action, could be multiple lines of code for one action. But while we are another, you're taking this big problem and breaking it down into bite-sized pieces, you can actually do something with. Step five, and mind you still, we haven't even written any code yet. All right. And there has been a mention of any language. Nothing there. It is programmatic problem solving, fundamental skill. Step five is to pseudocode your solution. Now a lot of folks do know of the phrase pseudocode. It is essentially going to be telling you in plain English what in it's for you to understand this, not for the computer yet, to give a directive in plain English at each step for what you're going to be accomplishing with the code. So for example, again, if you were to pseudocode your solution, all those steps that I just described in the process of going grocery shopping, each of those could be something that is a step, a pseudocode step. And once you've broken the problem down enough, you're going to find those steps are really small. And you might have a bunch of them. That's great. It's great too. Because in step six, you're going to write your actual code and it should be like translating from one language to another. If you've got your approach right, you're going to and you're still going to have to debug after this. We're not there yet. You're going to need to basically translate. And I tell folks either put it side by side. Do I do this whole process right in my code editor? And then you can kind of go from there and flesh things in. But you shouldn't have much more to do than just translating from readable language to syntactical language. You've already done most of the work here. Because programming and solving a code challenge, for example, is only like 20% actually writing code and debugging it and figuring out what to do there, how to make things happen. 80% of it is knowing what you want to make happen and why. So at this point, you're going to translate it to your actual code in step six. I give my students some advice for that, as far as how to set it up, what to do if you run into a situation where something doesn't make sense. But step seven, you're going to debug. And that's a, I don't think there's anybody that could easily skip step seven or wouldn't need it, especially the bigger the problem gets. So you're going to have to debug your code. There's nothing wrong with it. It's an accepted step. I think tech is one of those places and there aren't very many of them where failure and making mistakes is par for the course. It's about failing fast, making sure that you've taken the lesson and always say, take the lesson, leave the experience. So at that point, you're learning how to do right what you've done wrong. And then once it works, step eight, you're going to optimize it. And I also teach folks about measuring efficiency. So at this point, you know, this is why a lot of new coders will post their solutions. And then you'll get more advanced coders, we're like, oh, well, you can do it this way. And maybe it'll shave multiple steps off, you know, but maybe you forgot to optimize it. And we've all been there. And then you kind of feel like as a new coder, you're like, should I have known that? I don't know, like, okay, it's out of hit to my ego. I don't know. But it's a learning experience. But as we know, there's like a bajillion ways to do any one thing in programming. And that can be so overwhelming that there's not just one solid solution. So a huge part of step eight of optimizing is to ask people, you know, there are going to be folks with different perspectives. And you'll need to make the ultimate decision as far as what's right. And I do mention also about things like object oriented principles, design patterns, and what have you things that have already been designed for you to use this kind of a boiler plate. But it doesn't give you the solution. It's just guaranteed to be the most optimized and, you know, clean cut, something that's easily recognized within the language community. So those are my eight steps, you know, and that's just in a nutshell, I died in so much, you know, we use examples. I love grabbing, you know, I'll tell my students, okay, send me some problems, you know, and then we'll pick one and kind of walk through it. I learn just as much as they do, if not more. I have gained confidence in solving problems just by walking through it with them. And yeah, it's funny. I also, on the line of problem solving. I also have been hosting a free code camp meetup group for, again, like four years. I know Quincy, Larsen, I are good friends. And I was awarded top contributor in 2018. And I, we've been going strong, but I was playing this game with them. It was funny. I'm like, guys, I'm going to go in and play this game that I have called human resource machine. And it's kind of like a scratch type game where you have to, you know, they say, okay, you're getting the input on the left hand side. We want you to do X with it. And then, you know, output expected, you know, what we're expecting. And I was in there in the early stages, kind of tinker around and like one guy, it's mostly guys, of course. But like they've won guy wanders and he's like, what are you doing? And I was like, I don't know. Look at this. What do you think? Like I already knew how to solve it. But, and he's like, okay, well, you do that. And I'm like, there's nothing else. I love explaining their thoughts on it. It's so, it's like, just go for it. So crazy. And then another walks by and was like, no, no, no, I do it this different way. Group problem solving can be so much fun. And it can also be a little overwhelming because you're going to get so many different perspectives on how to approach it. So all those people have different context. And the context is going to inform the way that they create their solution. That's it. Those steps. I'm amazed. It have few people actually even do up through step five in step six is writing your code. But what are you writing? How do you know for sure, unless you've written that exact solution before, how do you know for sure what you're doing and what you're going in there? You know, I would like to think that maybe these advanced developers are just natively because they practiced it or they have really a good understanding naturally of programmatic thinking and programmatic problem solving, you know, how to think like a programmer and analytically, and I've done episodes on that too. And I'd like to think that they're just good at it, but I'm not so sure. I'm not so sure sometimes. I think some of these senior engineers, you know, I'm like, okay, where did you get this from? I don't even know, but I want you to explain it to me. And you be amazed how many of them can. Thank you so much for listening to this first part of the interview with Nicole on Shroom Pro. Make sure you subscribe and whatever podcast you're using. So you don't miss out on future episodes, especially the second part of this interview. Thanks again to Retool for sponsoring today's episode of Developer Teahead over to Retool.com slash DevT that's R-E-T-O-O-L.com slash D-E-V-T-E-A. Thanks so much for listening to this episode. You can find this in every other episode of this show along with all the show notes at spec.fm. Thank you to Sarah Jackson, who produced today's episode. Sarah is amongst many people. Perhaps those of you who are listening right now, who are trying to stay safe out during the wildfires that are happening in the West part of the United States. So I wish Sarah and all of you well. Thanks so much for listening and until next time, enjoy your tea.