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 2 of the interview, we dig a little deeper into the steps of code problem solving with examples and best practices.
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.
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 8 you're going to optimize it and I also teach folks about measuring efficiency. So at this point, you know, you 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 show 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 not a 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 and programming. And that can be so overwhelming that there's not just one solid solution. So a huge part of step 8 of optimizing is to ask, ask people. In today's episode, we continue our interview with Nicole Archambault. If you missed the last part of the interview, I encourage you to go back and listen to it first. It will give you a lot better insight into what we talk about in this part of the interview. Nicole has a blog and a podcast. We talk about that on this episode and we talk more about those specific steps to problem solving in this episode. Thanks so much for listening to this episode of Developer Tea. Let's get straight into my interview with Nicole Archambault. I think this is such an interesting breakdown and it seems obvious before you hear it. I knew a thing. It's obvious before you hear it. But once you hear it, it's like, oh yeah. I remember a problem where I didn't do step 2 or I didn't really do step 8 properly. I'm interested. This is one thing I was thinking of very end when you were talking about optimization. Because I think this is a really rich moment in those steps. One of the languages I really love is Ruby. Ruby has some really interesting built-in stuff. A lot of people who listen to this show also use Ruby. For example, we have a try method. Another good example, probably an easier one is dig. If you're listening to this, you're probably familiar with a dictionary structure, a key value structure. It's what JSON is based on. Dig allows you to safely, and we'll get back to what that means, safely index into that dictionary. You can dig into one key that has a dictionary under it, nested dictionaries, and then you can dig into the next key and then dig into the... That's right....there's ever anything in that chain where the key just isn't there, it'll just return nil. It doesn't tell you that you've tried to access a key that doesn't exist. It doesn't mess up anything. Intuitively, if you didn't have a dig method in your language of choice and you came to Ruby, you wouldn't just know that dig was there. It's not in your mental model. You might write out in your pseudo code, I got to check all the way down this six keys deep into this nested structure. I'm going to check and make sure they exist and do all this iteratively. Then you write out the code and then you get to that optimization step. Let's say you have a pair code buddy and your pair code buddy says, hey, you can use dig, right? It's like this moment of realization that, oh, this is like a sub problem. This is a thing that the tool that I can bring to the table. I'm interested in your perspective. I say all that, I have a point. I'm interested in your perspective on what it means to bring the right tools to the table. Specifically because a lot of that wrote early stage programming learning and then you mentioned, for example, object-oriented patterns. A lot of the earliest things that we learned though are not about those patterns. If statements and for loops and those are all absolutely valid and important constructs to learn, how do we make sure that we're adding to the tool set in the right direction? What's your perspective on that? You know, as you're talking and really you're hitting on all these keywords that I taught, I originally put into my course. I heard valuable feedback that it was helpful for people. I feel so confident now that I've included the right topics because you keep referencing them. I have an entire section in my course dedicated to your toolbox. You need to know what you were working with in order to be able to solve the problem. Now we're not always going to have the answer as far as capability. That is the point there, but again, that should be such a small issue. For example, and I also really enjoyed Ruby. I was going through kind of the manic learning decode phase when I started it and was exploring Rails because I had hit that wall and I had to re-evaluate effectively how I was looking at my problem and how I was interpreting it. So I was kind of in that manic phase going from language to language. I had realized that, you know, I think I hadn't realized yet. The problem solving was at the core of my issue that it didn't matter which language I went to. It was still going to run into problems. And so knowing the tools for that particular, the capabilities of that particular language was less important than understanding the tools. And so I walk through again, completely code language agnostic, explain like a five type stuff. I walk through every component from variables, functions, for loops, the different type of loops. And I explain to you that your capabilities per language are going to vary. They are, you know, they're not just varying name, but it's, they're going to vary in capability. You just might not be able to do it. It might be three steps to do something. And every language has its own quality of life. You know, they have areas where they really thrive. You know, working with different types of data structures, maybe I know Python is very popular for working with data. And so understanding at least what you're trying to do. So I could say, add this to this, you know, add this name value pair to this object or something. And like you had said, in Ruby, if we were to go through that, they have this beautiful quality of life feature for being able to retrieve that information or to add information. And then it knows kind of just to stop if you'll get an error, I'm sure, because that will trickle down to your expected output, which won't be accurate. So really you're looking at that entire setup there of, it's just such an important, an important step is determining what those, what those actual things are that you can use. It is literally a toolbox. Now, if I were to go in, some of these are so easy to find on Stack Overflow or Twitter. Just ask, I want to do this. I aren't, but the key is you already know what you want to do, right? I want to do this. How do I do this in JavaScript? Also, you should have great Google skills by that point. You should be able to see if you can find something on Stack Overflow. Because you can't be the first person ever that is going from that language, that language, and just wants to know how to kind of transpose that ability. So I think the people really do put, and especially new coders, if they don't get caught up in that manic kind of cycle, they're really isn't, when you learn the foundational skills in the foundational tools, how to iterate through something. For example, I'll have in there in four loops. And you know, some languages might have switch statements. For example, others might not. It might be called something completely different. If you're able to do that at all, you know, actually expressing certain cases, you know, for different input. And so, yeah, that functionality is definitely going to vary. And it's going to vary also. You need to have your solution effectively step through so that you know what you're trying to do. That's really the key that in every step here, every step in the previous steps are informing the next step. So you can't just go out of order. Some people try and start from writing the code Godspeed. I hope to get us that works for you. But I am, if you can jump right to that point, if that is what makes you the senior or the lead developer, you know, and gives you that sexy salary, then so be it. Yeah, I expect you to be able to jump in at step six and kill it. And also, it's not teaching your team very well. I've kind of recognized that too. You need to be able to walk through that and rephrase it for them and do everything. That's a great team building exercise to walk through things like that together. Those tools, if you don't understand, understand what you're working with, you know, you look at a wrench and you don't know what to do with it. Well, what are you going to do with? You can't really say it might be a really important tool that you need. But if you don't know what it does and what problem it solves, then you're not going to be able to use it correctly. Yeah, it's really interesting. I think, you know, as you were talking, I think one of the things that stuck out to me is, you know, one of the, I guess because I've worked with some languages for so long, I sort of think fluently in them. Not in the sense that I jump to the code, right? But in the sense that that is my pseudocode. Right? So I think it's really important for people to understand that pseudocode is more of a concept than it is a specific way of doing something. So pseudocode for you might also include, for example, drawing a picture. This is one of the ways that you can wrap your head around. And that may also be part of your step two, right? Your rephrasing of the problem could absolutely include, you know, even bits of code, it could include drawing a picture, it could include a lot of different things. Even though it's a distinct step from the other steps, there's, you know, don't consider your code language, the same thing as that step six, right? You can use code as a language as a tool for thinking as well. It's kind of backdrop, a good backdrop of thinking. Yeah, sometimes the other way around. Exactly, exactly. Sometimes it's going to confuse you as well, right? So it could, it could absolutely cause you to trip up, especially, you know, don't try to do that because you think it's going to earn you cool points, right? That's not the point. You know, the way that I think about classes, I work with Python every day now, but I still think native more natively and Ruby, right? So sometimes I'll sketch a class out in Ruby, rather than in Python. And then I can translate from Ruby to Python is fairly, fairly easy translation, but it's not, you know, my first language is still kind of this other, this other language. And in some ways, if you do that, especially if you have multi-language, you know, if you, if you worked with JavaScript for a long time and suddenly you're working with Python, it can help you have different insights to how to solve a problem. If you take it to another language, right? If you do, take it out of whatever your target language is and move it over to somewhere else. And this to that point, you know, as I was mentioning that cool thing in Ruby where you can dig into an object. Well, now I have that question when I go to any other language, can I do that? So some way to do that, right? And so when I see, for example, JavaScript recently did, I think it's called option chaining or something along those lines. Very similar concept. And the specifics of that doesn't matter as much as now I have this pattern that I can recognize in the tooling. And I know, oh, that's a pattern I can use the same way I used it over here in this totally different language, different environment entirely. I can reuse that. Another interesting thing, I want to bring it up because I think it's, it's important because, you know, we don't always discover our need for tools, right? We don't always know what we need. Sometimes tools can be shown to us, right? As like, you don't know it yet, but this is going to make your life better. Right? You don't realize there's not a problem that you, you don't know that you have this problem yet. I'm going to show you that you have it once you see this tool. Hey, Jake, quick. I'll give you a perfect example of this. All right. Early on in my programming work, some of the, some of the patterns that I was following, I kept on getting once again exactly what we talked about earlier, the missing car problem, right? Ruby, you have this thing called whiny nils, right? Whiny nils. In other words, they're constantly, you're getting the same error message that nil class doesn't exist, right? And so, you know, there's all of this conditional logic that you have to add into your code and it's just littering everything. It's littering all of your, you know, your view code. You know, it's, it's just finding its way into every nook and cranny of your project, just deal with whether or not something exists. You can force it to exist, right? But sometimes things you don't want to force it to exist. So, I had this pain and I thought the fix to it was just like keep on, you know, plug in the holes, right? Keep on figuring out where could you possibly end up with nil and then plug the hole and move on, right? It's dealt with in that location. We'll deal with it as it comes in other locations. This is completely reasonable. There's nothing wrong with that thought pattern. But I heard a talk that totally changed the way I thought about nil. And it was actually, the talk was called something, nothing is something. It was a talk by Sandy Metz, who is once again, you know, big in the Ruby community. But she talked about the idea that the concept of nothing, right, that you can build code around that concept and you can have methods on that code so you can have an object that represents nothingness. And you can have it respond to all of your other. It's called the nil object pattern. It's not new. It's not even all that novel, right? But to me, it was totally brand new. And once I saw it and once I implemented it in a few places in my projects, it's like, oh my goodness, this is going to totally change the way I think about code. At least, you know, that project. So I'm interested in in how you see, once again, I do have a point there. This idea of having epiphanies and maybe not maybe not epiphanies that you stumble on, but that somebody else gives you, you know, part of our jobs as engineers, especially as engineering managers or senior engineers, is to help other people see that. Right. To give them those kinds of tools and opportunities to make the things that they're working with better. So how can we set ourselves up so that we're always, you know, I guess it's a balance. And that's that's really what I want to ask you about. How can we not be in that constant treadmill of changing our tools all the time. But also integrating those new things, not just saying, oh, I want to do X, Y and Z, which is a totally valid way to discover. So what about the tools that we never knew existed? I think by the way, Paul Graham talks about this specifically as it relates to this, he says that this is like a super power language, because it has things that know other language has, and know other language, you don't know that it doesn't have. You don't realize that it's not there. Yeah, that's, I mean, that's a great question area to go into as well. I tend to think that that is an area that. Alright, let me be honest here, and I think it probably makes me a better developer as opposed to a poor developer. I know that, you know, experience developers. If they are good and transparent, should be willing to admit that they are constantly relying on the knowledge of other developers. Even documentation is from other developers and writing documentation is such a powerful skill, because it will help you to understand how to think in terms of a language is capability. And sometimes they'll do for MDN in particular, and some others I've gotten to, Miss Ella, you know, the group, these abilities, by a particular kind of category, in terms of what you're working for. So there might be something for objects, you know, and it might take it down pretty root level. And what, as you were speaking about, you know, some of these things, and it sounds like quality of life largely, but also sometimes it is just straight up capability. I do find that the more what you're looking for efficiency, and I do find that, you know, if you're looking at a project where you know that you need to accomplish something, I rely on the knowledge of other developers for some foremost. It's the quickest way to get the information that you need to learn. And I think a lot of developers are very much afraid. And again, that comes back to those emotions of shame, of anxiety, of fear that maybe, you know, your code isn't all that great, or you're not 100% sure what you're asking for. And a lot of new devs are afraid of getting skewered on on stack overflow, but a lot of the information is still there. And I've even leveraged things. I know when I was learning learning Ruby after JavaScript again had kind of a band in ship with JavaScript and then PHP and then Ruby. And then was like, okay, screw this. I've just got a folks and I'm fundamental first. And I would find myself searching for, for example, PHP and then some function that I learned in JavaScript. And you be amazed what comes up and what you can learn from that is a few interesting things. Number one, you're going to realize what you actually need and what you don't. And I find that using libraries, for example, or something to extend a language and really add those quality of life improvements. We do see a lot of them as kind of bloated. And some of those things I know, you know, I mentioned jQuery before. There's a whole cycle you might not need jQuery. And it's something that adds quality of life. Maybe you can do, you know, one line of code. But if you're considering things like efficiency, you absolutely have to consider what you're going to need out of that entire suite of of capabilities. So we also have to be careful about what we're using to extend capabilities. If it's not something that is natively possible with the vanilla language. But no, I say exactly what you're saying there. And I have had very good luck though in either asking, which again, don't be ashamed to ask everybody has to ask you have to ask in the workplace. You have to ask outside the workplace while you're learning. And every bit of documentation that we had, every language was created by another human being. And they should be able to hopefully in the documentation explain, you know, what this does and why it does it. You know, and what it looks like once you've, you know, used it. So it really is going to take a little bit of your own judgment, I think, in determining what types of tools to use and also knowing how to be able to find them. So if you don't feel confident and be able to find them quickly, you know, on Stack Overflow or something like that, be prepared to ask, open up a conversation and just say, I've done it for, is there a way to do this? You know, I'm writing out my solution to this and maybe even share what you have in problem solving up until then. But that and then being mindful and deliberate about what you do with the information that you gather. So for instance, if somebody comes back to you and says, oh, yeah, you know, in Ruby, there's this way of doing that. And that'll actually return, no, even if it's not exactly what you need or maybe it is. But yeah, it can do that. And to remember what that does because you now have two contexts. You have one for, especially if the other one does what you need, but maybe does something more, takes different parameters, what have you. You know, optional parameters, you're going to want to reuse that for sure. I have taken notes, you know, any type of app that supports kind of writing code snippets is useful as well because that is how you're going to keep that solution and how you're going to own it. We have to teach people as well how to take the information that you're getting that stimuli from other people and to transfer that knowledge to yourself. Because it is very different from just encountering it in other formats, you know, audio, especially e-learning, which gives you a lot more capability. But yeah, it is critical to be able to find. And then you know, for example, these two languages do this similarly, you add on a third language, you have another context, to be, you know, two context to be able to connect it to. So yeah, being able to learn with those tools, understanding what they do, understanding how to dissect something that is a little bit, you know, that is a little bit higher level in terms of capabilities. And being able to explain what it does on the low level is really critical to make sure you understand it. It's kind of like rephrasing the problem but between languages or rephrasing the problem, maybe even rephrasing the solution. But yeah, that's very much on the dot. Yeah, that's so good. But you know, it's interesting, I see, you know, these steps make total sense. I can imagine using a step as a tool as well, right? It's like, oh, you know, in the debug process, for example, maybe I didn't do the rephrasing right. Maybe I need to go back and make that tool up and reuse it again in the debugging process. Make sure I did that. And then, oh, I need to go back and rethink, you know, how I did my pseudocode. There was something missing. I didn't translate my description of the problem to the pseudocode correctly. Another interesting thing that came up, and this will be the last thing to keep on, you know, this is such a great job. I know I love talking about this stuff. It is like my after-go special interest. So trust me, I could keep going for hours, but this is your curation. You take the lead. Absolutely. Well, so I think in interesting, I really want to hone in on that number eight again, because I think this is where a lot of engineers, they spin out. And this really makes a huge difference, especially as you progress in your career, how you treat optimization. You know, you mentioned solving the wrong problem. This is where that can happen in so many cases. If you end up optimizing your code in ways that don't actually matter. I'm going to get back to what matter means in a second, but if you end up optimizing your code in a way that is, you know, to you as an engineer, you're like, well, it's like three times faster. What's wrong with that? Right? There's nothing wrong with it. I didn't break anything. In fact, if anything, I'm being, you know, frugal, I'm using less cycles on the CPU, whatever the thing is that you're targeting. Here's the thing. The word matter needs to be focused on a little bit more here. Right? Because, and to be clear, I'm talking about in the context of a job, right? If you're, if you're getting paid to do this, if you're working on your own projects and you're like, well, I just want to learn about how to optimize something. What's wrong with that? Absolutely nothing. Go forth, ignore this section of the pocket. But when you have a job, a lot of what you're doing is dependent on who determines what you're doing. It determines what matters. Matter in this case is a business word, not an engineering word. Yes. Right? It has nothing to do with, you know, the metrics that you as an engineer are determining for your personal understanding of success. Now, maybe clear those things still matter capital M matter outside, you know, your self worth still matters, right? But when you talk about optimization, be very clear, be very, very clear in why and what you're optimizing. Oh, yes. And you brought up a great point there too. This is where domain expertise can also come into play because, like you said, understanding what matters. Well, when you're looking at maximizing efficiency in terms of maximizing the resources that you use and keeping them at the lowest level because really that's what we're looking at with, you know, looking at all levels of the efficiencies, base and time complexity. Look at big O notation, you're really marking a solution with how effective it is. But that doesn't speak at all to if it really solves the problem, right? Because you're going to have sometimes there are multiple problems embedded in a problem. And I've seen that, for example, like you need to know what you need. And you need to know what matters if you are creating a solution for something that doesn't matter, but it's highly efficient in terms of resources. It's still not going to do much good. You haven't really solved the problem. You came up with a solution to a problem, but maybe it wasn't a problem that mattered. And so based on, like you said, it's a company, a business decision on what matters. And I find things like user experience can come into play there. Really interacting with your users to see what matters to them. And then making what matters to them, the most efficient possible. I was just noticing that the other day using some web app, was I look at, oh, which I'm well, there's only enough. I was on OK, keep it OK. We're in there and I'm booking around. And I was like, damn, the site's lightning fast. I was kind of like clicking on stuff, going into a profile, going there, they know that people are going to be traversing these profiles. We know that there has to be a pretty smooth flow so that people can just go, no, no, no, no, no, no, no, no, no, that's my experience. And then it's like duck, duck, duck, and eventually you'll get a goose. OK. And they need you need to know also that when you get your goose that they're going to know, you know, and that you're going to be opening up a different experience. So once you've decided, for example, in that case, that one party is interested in the other party, the entire experience and the dynamic is going to change, right? Because you know that that attraction is there and this very much domain specialty where you might even consult somebody on what are data is looking for. You know, people who are single that are looking for partners, well, that experience of being able to switch gears from seeking to establishing a relationship. That is the problem that needs to be solved right there. It's you know, and like I said, very much tied into user experience, user feedback. And you're absolutely right. You can solve a problem. And like you said, solving the wrong problem. That's it. And in that case, wrong can mean the problem. It doesn't matter. And inefficient can mean that you're focusing the resources, you know, you are focusing on your focusing too many resources on something. So if something is inefficient, but it's required, you know, according to user experience, you're going to run into a problem. If you're putting, you know, tons of research, you're bloating up, for example, if I had gone to switch between profiles, that's an important problem that needs to be solved. However, it's not efficient. So those are kind of the two sides of it. And you can see where they're really kind of two sides of the same coin. And they're related, but they are very distinct. You're exactly right. Yeah, wow. So I mean, my mind is reeling on all the things that I could do as an engineer. When you're thinking about that domain expertise on OK, Cupid, for example, you know, moving from searching to developing a relationship, just imagined the idea of buying a faster load time as a user. You know, it's not a frustrating. It's kind of like somebody showing up late for a date. If your profile takes forever to load, then it's going to be frustrating for the person. So that's such a good insight, the idea that domain expertise is critical. And you know, this is why engineers, we can't just hold up in our engineering corner and act like our work is, you know, a secret to be kept. Our work is just another, and I say just I want to be careful here. It's another part of our business concern, right. It's another function in the business. It's not, you know, special unicorn. It just still happens to have some qualities to it that are totally different than some of the other functions in a business. But if you let's say you don't have that domain expertise, how are you going to optimize correctly? You can. You can't you have to reach out to let's say a product manager. Right. Someone who is whose job it is or who has the experience required to give that domain expertise to help you find, okay, here is the lever that you want to pull, right. This is the metric that you want to focus on. Here's what you want to maximize or minimize. Those are the kinds of things that a great developer, right, a great engineer, someone who is really going to progress well in their career. That's what they're thinking about when they think about optimization in my opinion. Certainly. And as soon as you're talking about that, I actually flash back my customer service days. So when I was working at the, it was a iPad, porn and sale app and understanding. I really took the time to understand the needs of a business owner because that is going, it's going to help you in so many areas that helps you to be more empathetic. It helps, which is so important in all areas of tech. I mean, outcare what area you're in empathy is absolutely critical if you're going to be a great developer. And being able to understand, you know, and to hear the frustration. So being a great customer service representative was very important, but then the question becomes, what can I do for them? Right. We're only able to do for them to manage kind of their expectations. What is created for us in terms of capabilities by the engineering team. So the customer service program and department is really also built by engineers. That even requires an area of domain expertise. And that's an area that I was actually really advocating for was to have customer service involved in the process of creating, you know, involve very closely with engineering because you cannot code does not happen in a vacuum. You have to read other people's code. You have to get feedback from user experience or else you're just going to keep going in a circle. And you probably will miss the right problem. And if we didn't have the right tools that we needed to be able to solve the problems that we found with, you know, being able to reset the data on something, you know, that's a critical problem. If you put that in there, but nobody really had to use it, but it's like mega efficient, but you're never going to use it because it's not something that solves a real problem for the end user. Then, you know, you're not doing it right. But yeah, no, it all comes down to the problem. And you can go way further in root problem. Then I find a lot of people even realize, root problems are powerful because they affect so many different areas of the problem, you know, as you break it down, that, that you're going to have to solve along the way to your big solution. But yeah, no, that is such a great point. And I am that's why there needs to be that connection between those departments as well. There needs to be that domain expertise, you know, me being there in the engineering, you know, stand up and say, you know, this how this is an issue that we ran into to talk to the project manager and have them determine if that's something that they need. So yeah, it's it's all over the place. There's no escape net. You can't just sit down and write code and trust that the project manager knows what they're talking about because even the way that you write the code is going to be informed by the bigger picture of where it fits in right. Absolutely. Yeah, back to that first point of integration, right. We are we are totally integrating our experiences and our knowledge and the context that we have, even if we're not even intentionally doing it, we are going to integrate that information. And so choose your information sources wisely. Yes, that's such a good word. And else clear. Yes, yes, yes, yes, and definitely a part of learning effectively as well. And learning deliberately got to know those resources to be able to find researching incredibly important that touches almost every step there is being able to find an answer when you don't have it yourself. That's a great topic though. I love it. Yeah, absolutely. Well, this has been a wonderful discussion. I really appreciate your time tonight. And I want to ask you a few questions that I like to ask all my guests who come on the show. Go for it. All right, the first question is what do you wish more people would ask you about? I believe that I can make the most impact in the area of fundamental skills. You know, and that's where I'm focused right now, which is good. I wish that more people would ask me directly what kind of skills they could learn to make the process of learning to code easier. That's a big one because it's answers that I provided, but I had to really do the work surveying what have you to actually figure out, you know, the exact questions I want to ask. And you know, some of them were maybe efficient, but they didn't answer that they didn't give me anything that I could use. It was a good question, you know, written, but. And yeah, I would say that I wish that more people would come to me and open up, you know, how do I get over blank screen paralysis. I do have to ask the questions myself a lot, but I have so much valuable information that people can take away from them right that moment and go apply. So it's tough though. You people don't often know what to ask for and that's perfectly okay, but you need to express the need at least. I would say to be as straight as possible. How can I learn, you know, make this process as smooth as possible. I don't think they recognize it could be smooth. Maybe. Yeah, wow. That's great. So if anybody encounters you in a workshop or at a conference one day, maybe a virtual conference for the for the time being, and they can ask you about those things. Yeah, if somebody, you know, I usually I started burning myself, I should say as kind of text programmatic problem selling expert. And from there auto-di-doctism connects and there are a lot of folks out there that are, you know, the cognitive psychology side of things on how to learn, you know, how our brains respond to stimuli. But as far as the problem-solving skills in particular, there's no one else out there teaching the way that I do. The reason I have the only code agnostic problem solving like context only course out there. And I created it because of a very specific need. So yeah, come up to text programmatic problem solving expert and ask me, you know, what you can take right now. What's the number one tip I could give? And I guarantee you with this topic in particular, as we've seen today, every piece of advice I give in every perspective I give opens up a door to another, another question. So the conversation will usually go on organically to a deeper level. Yeah, yeah, that's so good. Okay, last question. You had 30 seconds to give all of the developers listening to the show, a piece of advice, regardless of their experience level, maybe they're not even a developer yet. Or maybe they're considering joining this kind of motley crew of people who are becoming engineers better every day. What would you tell them? Well, I think I can touch on what will probably be the first part of of our conversation and also on the problem solving. The number one thing I would want Developer To take away is that emotional intelligence. You need it. There is not a single role that you will ever end up in that can't be where your presence can be improved by being more emotionally intelligent or a single social situation that can't be improved and trust me. I know that. And in terms of the problem solving, you really need to know, especially as a new developer, you cannot jump in at step six. You can't just start writing code. I don't know of anybody that was just able to jump in natively and keep going. That's the key. Eventually you're going to get caught. And when you get caught, you're going to need to go back to those fundamental skills. There's a reason why you're getting caught. So that's it. That's what I'd say emotional intelligence. Bring it to the table. It will improve your life and improve your career, your education, everything. And don't just jump right in. That process of problem solving is going to make you a better developer and really will. That's so good. Thank you so much for bringing this conversation to this audience. And for the work you do, can you tell people where to find you on the internet? Yes. So on Twitter, I am pretty prolific on there. I have kind of a weird personal presence. But my handle is lovey underscore on code. And that's L A B's Invictor I E underscore E and C O D E. And so be sure to follow me. I post a lot of valuable stuff there too and also a lot of bullshit. And then on the other side, my website is up where I have a whole bunch of guides and my courses are there and a shop with some really ugly merchandise in it that people seem to keep buying. And that's at levion code.net. And if you were to it's the same as my handle, but without the underscore on there are two ease in there. And I have a podcast. Do so. I would highly recommend it, especially if you're a new developer. I talk about so many important topics, mental health, mental illness, keeping motivated. What we do, you know, for problem solving career web developer roadmap. Oh my goodness. I loved it. It's my passion project. So check me out on iTunes there or Spotify. It's the levion code podcast. So should be able to find me that way. Awesome. Thank you so much for joining me. And I hope to talk to you soon. Yes. Thank you so much. Another huge thank you to Nicole Archambault for joining me on Developer Tea. Of course, a huge thank you to Nicole for being vulnerable, especially on this show and sharing all those personal details with us and her journey. Hopefully some of you can identify with Nicole's position and the unique scenario that she has found herself in as an engineer. And I encourage all of you to first of all go and follow Nicole across the internet. I'm sure you can find her. You can find her in the show notes, La Viet and code. But also for your own journey, recognize that there is no one type of developer. There is no one specific picture that we are all unique in our own ways. That sounds so cliche, but it is true. So no matter what your background, even if you aren't an engineer, of course, thank you for listening to this show and you are welcome to be a listener and a part of this community. Thanks so much for listening to today's episode of Developer Tea. Of course, a huge thank you to Sarah Jackson, the producer of today's episode. My name is Jonathan Cutrell and until next time, enjoy your tea.