Overcoming Imposter Syndrome Part II

About this Episode

Impostor Syndrome is definitely a topic that deserves more than one discussion. It's easy to be at a desk and feel like you're not sure; do I belong here? People around me seem to know what they're doing, do I? The answer to both is Yes. We return for Part 2.

ICYMI: Here's Overcoming Impostor Syndrom Part I!

Transcript:

MIKE: Welcome to another episode of our Acima Development Podcast. We've got what I think is a good one today. So I think it's something that we struggle with as developers. I think most, if not all of us, hit this occasionally, at least. And we've got a perfect group today to talk about this subject because we've got a wide range of experience.

The topic we're going to be addressing today is impostor syndrome. Before we dive into that, let's go ahead and introduce ourselves. I'm Mike. I'm going to be hosting today. Well, let's go around. Eddy, do you want to introduce yourself?

EDDY: My name is Eddy from the QA team. Happy to be here. Thanks for having me, as always.

MIKE: Great. Damon.

DAMON: My name is Damon, and I am on the application support team.

MIKE: Thank you. And Ramses.

RAMSES: Hey, everyone. I'm Ramses. I'm on the Atlas development team. Excited to be here.

MIKE: Thank you. And I'm currently Director of Engineering here at Acima. So we've got a range of experiences, of backgrounds which I think is perfect. We've got somebody who's been doing software development for decades, somebody who's officially on the team who has only been doing it for a short time, somebody from support, and somebody from QA, both of which hope to get into development. It gives us a chance to talk about the different perspectives that we might have on a career in software and how that feels from those different positions. And there are similarities and differences, but I think you'll find that there are more similarities than differences.

Let me give a little introduction of this idea of imposter syndrome. It doesn't just apply to software; I think it applies in a number of fields but particularly in software where our job is to solve problems. There's no handbook, and there's no clear set of guidelines that this is exactly what you do. Instead, you're sitting in front of a computer with a problem to solve and sort of go ahead, solve it, and that's it.

And you certainly have peers who can help you. But it's easy to be sitting there in that desk and feel like I'm not sure; do I belong here? People around me seem to know what they're doing, do I? [laughs] I have a hard time imagining that there's anybody who doesn't feel that way sometimes. To talk a little bit about my background, I've been, as I mentioned, doing this for over 20 years. I started my full-time software career right after the dot-com bust.

A lot of those big dot-com companies from the late '90s went belly up in the early 2000s. And the industry was flooded with developers, skilled developers who had just been let go from their jobs. And there was a glut of people to do work, and the jobs hadn't quite caught up yet. And it was very challenging to find work. I eventually found full-time work. My recollection is I was making less at the time than I had been doing working construction previously. [laughs]

And I went and got a degree for this. It was certainly easy to feel like I didn't belong and I had made some wrong choices along the way. That led to some interesting developments. I was working for a startup that went really big and then crashed spectacularly. They actually let go of all the software development team but one, and then he quit. They ended up hiring me back on. So I went from being just a junior developer to running all the software for the company within just a few years. And I wasn't perfect yet, and there was a lot of pressure.

I learned a lot during that time, trying to run things on my own. I also made some mistakes and had that, you know, I'm swimming in the deep end now. There's nobody here to help me experience lots of mixed feelings. Do I belong here? Do I not belong here? I had some respect in that I was doing the job, but then I wasn't doing it perfectly. And I had all those questions.

I later moved to another company where I had a somewhat similar experience. We grew tremendously and then slowly tapered off. That company finally shut down operations back in January. And I ended up there at the department for a while and asking myself, am I doing okay? Am I not doing okay? And after a while, after that, I went to contract work.

Across all of this time, I had experiences that taught me a lot and had positions where they seemed to show some respect. But all along, all along my entire career, I've wondered, am I really doing okay here? Do I really belong? And now I'm here at Acima. I recently got my title to Director of Engineering, and it sounds kind of respectable. [laughs] But just like everybody else, I'm figuring it out. I can't claim to know everything. There's a lot that I don't know. And I'm always trying to learn just by reading and paying attention to my peers, trying to figure out how to do this the best way.

I've learned to recognize that I'm never going to know everything. It's a fast-moving field with so much to learn that I couldn't possibly know. And doing well in this industry is not about knowing everything but about having that humility, recognizing you don't and being willing to ask, and further, just trying to solve problems.

And with that, I'd like to, you know, I wanted to give an intro there. Now I'm going to be quiet for a while. And I'm interested in the thoughts of the others here on the call to share what their experience has been and how they perceive things given that background, this idea of imposter syndrome.

DAMON: Maybe you can add to what you were saying. You mentioned you were in the field for over 20 years. How did you warm up to the idea of imposter syndrome, and how did you get over it?

MIKE: That's a good question. I don't think I heard the term until much after my career had started. I don't think it's gone into widespread use; I could be wrong; one of those things that I might just not have heard about. But I don't think it's been in widespread use until the last few years. So I think there might be a few answers to that. First of all, when I heard the term, I thought, oh yes, that's what it is.

And I've noticed that as I've mentored a lot of people...and that's something I'll point out that has helped a lot. As I've mentored a lot of people, I've noticed that most developers I've worked with tend to feel that way. They'll express something along the lines of, you know, how am I doing? Do I really belong here? I feel maybe out of place, not because the people around them aren't supportive, but, wow, I'm around a lot of smart, capable people; am I really that? And the answer universally has always been yes. Yes, you are that.

And we have differences in experience. It's not that everybody has exactly the same skill level and exactly the same background. But everyone that I've worked with has had something to contribute. Perhaps the biggest differentiator I've seen as I've done a lot of mentoring between people who are really successful and people who aren't is that the really successful people are deeply curious.

They don't see asking questions as a sign of weakness but the natural consequence of their insatiable curiosity. [chuckles] They just want to figure things out. And because of that, they're willing to be vulnerable enough to ask, whether it's to ask their peers, ask mentors, ask Google, ask whatever it is they need to ask to figure problems out and experiment and try. None of us are going to quite know the answers. If we all knew the answers, then we could automate this job, and we'd all be out of work. We don't know the answers as the people who are asking the questions who have been very successful.

So to answer your question, how did I see this and get over it? A lot of it has come from not just my own experience but watching everybody else that I've worked with. I've seen so many people become successful. I've mentored a number of people who have gone on to be quite successful in their careers. And they were a diverse group of people, and they've come from different backgrounds. The number of people coming from customer support or similar roles to that, you know, who felt like, wow, I'm going into development; do I really belong here? They went on to become extremely successful.

And seeing that progress of these capable people who maybe doubted themselves at first but allowed that curiosity to blossom allowed that curiosity to lead them to ask those questions and solve the problems. If I'm curious, if I'm solving problems, if I'm helping people out around me, well, I'm adding value. And it doesn't matter if I'm exactly like everybody else around me; I'm helping.

DAMON: I find that kind of interesting because I came from a different background. So I never did customer service or anything like that. I was in the military for a few years. And I had a position where it was, hey; we're going to give you this piece of equipment. You need to figure out how it works. If it breaks, you need to figure out how to fix it.

And asking questions wasn't encouraged. It was almost frowned upon. It was like, oh, you can't figure it out? Okay, we'll find somebody who can. And when I came to this role sitting side by side with super smart people like Ramses or learning from somebody else, it was like, am I supposed to be here? Is it okay to ask these questions? I think breaking that habit for me is very challenging. [laughs]

MIKE: That's interesting. Well, I've got a couple of things to say to that. I've seen research that suggests that people who come from the military are more likely to be successful in this field. I don't know all the reasons, and I don't know that researchers know all the reasons. [laughs] But something about that background, maybe about the requirement to be a problem solver, tends to be very helpful.

The other thing I would point out, though, is what you said, is that idea of it being frowned on that I shouldn't ask questions; you experienced it there. But I think most of us experienced that somewhere. People who've gone to school, well, if you're asking the person next to you for help on your assignment, well, that might be cheating. And we get ingrained in us this idea that you shouldn't ask for help; doing that is doing it wrong.

But in the industry here, the opposite is true that if you're doing it yourself, you're doing it wrong. And let me explain that a little bit. It's not that we can't go off and solve a problem largely independently. But almost none of us are going to write in machine code. We don't write zeros and ones; we're writing computer languages, which were written by somebody else. And most of what we do is use libraries that were written by somebody else or maintain libraries that are written by a community.

And we're just working at the very top of this pyramid that stands on the work of so many women and men who've gone before us. This idea that we would be working alone is, I think, really misguided that we're all deeply dependent on those we're working with now and those who've gone before who've laid the foundation for us.

There are many different sources that will tell us, "You shouldn't be asking. You need to be figuring this out on your own." I think most people have to overcome that notion from a variety of backgrounds. Well, you got it in your previous career; many of us get it from our previous careers, or from school, or just from our upbringing. And it may not be universal, but it's quite common.

DAMON: Yeah, I think that makes sense for sure. Yeah, like you were saying, just being in this field now and asking so many questions, there are so many people that want to help you. There are so many people that are like, "If you have a question, ask." And you kind of think like, oh, that's just something people say. People are just like, you know, "If you have a question, ask." But if you really ask, they're like, "Okay, hold on, let me pair with you and break it down exactly how it's supposed to be." And you learn so much from that. And that has been super helpful, for sure.

MIKE: I'll ask a follow-up question. Have you had people say things to you like, "I love pairing?"

DAMON: Oh yeah, especially like Melissa, Afton. They're always down to pair and like, "Well, let me show you exactly how to do it," you know, it's great. They actually love just teaching.

MIKE: And that love is genuine. It's not, “I'm going to put down this because I'm sympathetic.” They genuinely love it. And I think that those of you listening can probably find a mentor like that because there's a lot of joy in mentoring. It's very enjoyable to go and watch those lights turn on in somebody's eyes and see them get it. It's a wonderful experience, and it's probably my favorite part of the job.

It's not something that I feel like I'm being burdened to do, but it's something that I feel like I get to do. Like, oh, wow, I can get out of a long meeting and instead go and help somebody find something cool. It's not something you should be shy to do. And if you're not finding mentors that are willing to do that, then maybe you need to look a little farther afield because they're out there. I found that there are many people who want to share when given the opportunity.

EDDY: When I first picked up the Atlas backlog tickets, it was easy for me to feel that I was the only one having a problem and seeing other people pushing dev tickets and stuff, you know. But in reality, with pairing, you get to see really quickly that others are presented with the same problems as well. And the unique part about pairing is you get to see their approach to how they solve a problem.

To me, the important thing that I've learned thus far is to ensure the problem doesn't become bigger than you do. Use it as a stepping stone, in a sense. So you get comfortable, and you accept it, and it's okay. And accept the fact that it's okay to ask other people for help. You've done a phenomenal job with picking the people that's on the team because everyone that I've reached out to has been more than willing to help and pair. For me, it is basically don't get scared of the uncomfortable situations and instead embrace them, and then eventually, you will find the solution.

DAMON: I think that's just something to piggyback off of here. That's something really interesting that you say because when I did my first ticket, I think it was the day before yesterday. And I was like, "Hey, can I pair with you? Because I don't know where to start," and just seeing how someone will go through the process and they run into the exact same issues that you would run into down the line, it's like, okay, I get it. [laughs]

Like, I wasn't the only one, you know, just not getting it. And then they need your input, or they want your input, and you want their input. So it's just, I don't know, I love it. Like you said, Acima, as a company, picked a fantastic team as a whole.

MIKE: One thing I'd like to maybe add to that is that...let me preface this a little bit. There's a cultural trope of a software developer as being an antisocial recluse who maybe goes down in the basement and bangs away on the keyboard alone for a long time and comes out with some masterpiece. And I'm not going to say that there's nobody who works in the basement. I work in a basement office. [laughs] But that is, in general, a misrepresentation of how software gets built. We work as a community.

Maybe let me give an example perhaps. The most successful software project on Earth is Linux, which is an operating system made by a guy named Linus who did his own take on something similar to the Unix operating system and made a portmanteau of that, of Linus and Unix, and you get Linux. He wrote this simple operating system quite some time ago, more than decades. He just gave it out to the community, formed a community around it. The community worked together to build something amazing. And he started getting industry support, and there are people paid by their companies to work full-time on that operating system. And it grew to become far more than what one person could do.

Now, Linus Torvalds is a very talented person, and he still leads that community. But he's a leader, not the sole developer. In fact, I don't think that somebody in his position should be writing most of the code or trying to because they can't, and they would be spending the time doing things that are more useful, which should be guiding the community.

I give this background to suggest something about how software really gets built. There are people who are capable and working and building things, but they really only become successful when they work together with the community. And as a leader that leader can cultivate an attitude of mentorship and community, or they can breed a toxic environment where everybody is forced to go work on things alone. That's a choice, and sometimes people don't make that choice consciously. I think they usually don't. But there are consequences to that choice that gets made.

We talked about choosing people well, and honestly, I think that that maybe misrepresents it a little bit in that there are amazing people on the team, but I think there are amazing people all throughout the world. And they're able to be amazing when they're empowered to do so. I'm going to make a passionate entreaty, a call to action to everybody out listening. Within your sphere of influence, try to create that kind of healthy community where people are encouraged and have the opportunity to ask and grow, and if you do, you will build a fertile ground for good software to come out of.

I'd like to share one more thing briefly. I'm an avid gardener. I don't always get as much time to do it as I used to, but I still enjoy it. One thing I've learned is that you don't feed the plants, and maybe if you're doing hydroponic gardening, you do. But if you're out in the soil, you don't feed the plants; you feed the soil. If you try feeding the plants, then you're going to be very focused on the plants, and that tunnel vision you get is going to miss important components. You're going to miss the broader aspect of the ecosystem you're dealing with.

If instead you pay attention to the soil and create healthy soil, so you're feeding the soil microbes and the invertebrates, and the arthropods, and worms, and whatever else is out there living in your soil and try to grow very healthy soil, then you will have a diverse ecosystem out there that's kind of self-balanced that is not likely to have a lot of diseases, for example. And when you grow your plants in it, they're growing in a healthy environment that will allow them to grow well.

If you're trying to force your plants to grow, you might be able to make it work sometimes, but it's not going to work very well in the long haul. Rather, if you feed the soil, then the plants will grow on their own naturally.

In the Midwest, where I live, there's been a change. I don't know exactly the time frame. But it used to be that the debris on the field was always plowed under in the fox. They wanted things to look tidy. They don't do that anymore. They leave the debris from the corn and soybeans on the soil to protect the soil over the winter. It keeps it from blowing away. And it decomposes, and then they turn it in in the spring, where it then feeds the soil.

And that change has led to a lot less loss of topsoil and better crops. Just thinking about growing the corn misses something really important. We feed the soil. And as leaders, what we need to do is create an environment for people to thrive, and they will because people are amazing. And they'll bring their different skills to the table and be able to do great things.

DAMON: I think that's a really good analogy.

MIKE: Ramses, we haven't heard a whole lot from you today. You've been working on the team for a while now.

RAMSES: [laughs] Yeah, it's been a while.

MIKE: What has been your experience with impostor syndrome and learning to ask those questions and feel comfortable and like you belong here?

RAMSES: My experience has been really interesting. When I started out in location support, it was very mostly do-it-by-myself kind of approach. I was very community-driven, but I was also self-motivated to find the answer however I could, whether that was just Google or asking a friend or a colleague, who are also my friends. And now it is very...it's kind of the same, but I am definitely a lot more community-driven now and not as self. I mean, I'm still self-motivated, but I try not to spend too much time on a problem by myself. And if I do find myself doing that, then I know it's time to reach out.

MIKE: Do you ever find yourself still questioning, am I sure I belong here?

RAMSES: Yeah, probably all the time. [laughs] I feel like I'm getting a lot more confident. But you do still always have the, you know, is this the right approach, or is this a good approach? Or how can I write my code cleaner or more simpler? But I think the best way to learn is to be uncomfortable, you know, put yourself in uncomfortable situations. That's how you grow.

MIKE: Absolutely. Put yourself in uncomfortable situations. We could probably spend quite a bit of time talking about that one.

RAMSES: Oh yeah.

DAMON: I remember when I was going to therapy for a minute, my therapist would always tell me, "Lean towards the discomfort. Lean towards the discomfort." And I'm like, oh man, [laughter] nobody wants to do that. That's something you just need to do. Because I feel like I have a lot of confidence, but just some days where it's like, man, I know somebody who could figure this out way faster than I could. I'm spending too much time on this. It's just a lot, you know. Yeah, just lean towards that discomfort and make yourself uncomfortable and just do it.

MIKE: Do people go to the gym because they're already, like, totally huge?

RAMSES: Sometimes.

MIKE: Sometimes. [laughter] It's true. [laughs] But they didn't get that; I mean, they didn't start out that way. They go to the gym specifically to do uncomfortable things so that they can grow.

EDDY: I think the biggest point is that when you're first starting in the industry, there's just so much knowledge, and technology, and frameworks that have been established for years before you even heard what programming was that it's really simple to start chipping at the top and you're like, dang, there's just so much I don't know, and it's really simple to feel overwhelmed. That's the problem I had when I first started. The infamous phrase it's just the tip of the iceberg, I think, applies really well here where at the surface, you're just like, yeah, I can do this. But then, if you don't have the right mindset, it's really easy to fall victim to that.

MIKE: It is. I said at the beginning, and I'll say it again, that I recognize every day how little I know after decades in the industry, and I'm an enthusiastic reader. [laughs] I've always loved reading and learning things, and I still feel like I'm just barely scratching the tip of the iceberg. But that doesn't mean that I'm not able to be effective.

I think it's a cognitive bias, some sort of psychological...I don't know if weakness is the right word because we have these biases for a reason, kind of heuristics that guide us but sometimes they lead us astray. And one of them is that we think that we have to do everything to be doing it right. That's just not true. If you've accomplished something, you've accomplished something. Accomplishing everything is nobody's realistic goal. Getting competent enough to do something is a great achievement.

If you're learning software and you're providing value to the company, then you belong there. You've just done something that company wanted. Well, of course, you belong. You just solved a problem. And you may not understand the full scope of every problem that the organization you're working for is trying to solve or the larger industry here, all the problems of humanity. But you wouldn't expect yourself to do that in other circumstances. You shouldn't have to expect yourself to do that here.

You do the ticket. You talked about working on a ticket and it seeming intimidating, pairing on it, seeing other people having trouble, and getting through it. But when you get that ticket up and in production, first of all, it's a really great feeling. [chuckles] And secondly, you've accomplished something now. You just provided value. And it doesn't really matter if it was hard. What matters is that you solved the problem.

EDDY: That's super helpful to know, and it makes me feel better about myself in a sense because a lot of the tickets that I will be working on will be beginner tickets, like right now, or cleanup tickets or something like that. So it's like, for me, it's like, oh, somebody just threw it on the side because they didn't really want to do it because, you know, it's simple to me. But it's like, hey, we needed that done. It benefited us in some type of way.

MIKE: We have a pool of work. I used to talk about it with a former product manager. And we said, "This is important work, but it's not necessarily urgent." It's kind of a monster. It applies in software, but I'm thinking it applies in probably many fields of urgency that there's always something that's got to be done in a short time frame. And if you're always paying attention to that monster and fighting it away, then you never take care of some other things that are extremely important. They're just not as urgent.

And in the worst case, you can have a situation they call firefighting where you're just running and putting out one fire and then running and putting out another fire because the whole system is just barely holding together, and things are falling apart. And you just solve one disaster after another because you're never taking the time to do the maintenance to prevent those disasters.

And you say that you're doing this work that maybe doesn't seem like it's the most urgent. Well, it is true that we tend to have people who are wanting to become developers; we'll give them work that is not the most urgent because we're trying to get it done quickly, but that doesn't mean it's not important.

I'm thinking about that condominium complex in Florida that collapsed a year or two ago. There were problems with the foundation that people had noticed for some years, like parts had been falling into the parking garage. And I think that the pool was not shored up well. And people had seen that for a number of years, seeing that there were problems, but there was always something more important to work on. And I can say important, that's the wrong word. There's always something more urgent to work on. And they didn't take the time to do that work of shoring up the foundation. When it failed, it was catastrophic and tragic. People died.

EDDY: Oh yeah.

MIKE: Had they had somebody go in and do that work to just shore up the foundation, "Let's fix the foundation here and make sure that important work is done. Even if it's not necessarily urgent, we're going to specifically dedicate some budget to having this important work done," then that tragedy could have been averted, and lives could have been saved.

We're probably not talking about such a life-and-death thing with most of the work that we're doing. Maybe you're in healthcare, and it is life and death. But there is important work to be done, and you shouldn't feel like it's irrelevant just because it's not the most urgent work. We wouldn't have identified that work and created stories for it to be worked on if it wasn't important.

DAMON: I think just hearing that is super reassuring for me personally. It makes me want to learn more and obviously just go and grab tickets and just be like, okay, let me figure it out. Let me learn. Okay, I don't know it. All right, who wants to pair? It's good to hear that, for sure.

Mike, let me ask you something point blank here.

MIKE: Yeah, absolutely.

DAMON: When you are in the middle of that transition where you have that milestone that you want to become a full-time developer, is there a general consensus, or is it like perspective for you when you know that you're ready to take that leap? Where do you define that line?

MIKE: That's a great question. Let me try to give you a nuanced answer because I think that a short answer is probably not going to quite cut it. And my nuanced answer is going to be that it probably depends on your situation. Let me elaborate a little bit. You're never going to be ready, and recognizing that, I think, can take a burden off your shoulders because if you're never going to be ready, then you don't have to worry about being perfectly ready. But I think that giving examples is helpful here.

So let's talk about Olympic athletes. Olympic athletes will spend years, sometimes even decades, of their life training. They're usually younger, so maybe not decades but many years of their lives training for that one moment. And still, only one person is going to win, and sometimes it's a fluke. Somebody has come prepared as well as they possibly can. And then something goes wrong, and it's outside of their control.

We have human limits that prevent us from really being able to be truly prepared for something completely. That shouldn't be our goal. So I'm going to scale that back to say, well, if you can't be perfectly ready, well, what can you be? And I would say you're ready to jump in if you can consistently provide value in the position that you're going to be given.

So, for example, let me take an example outside of software. I've worked in construction. And I spent some time as an apprentice carpenter. First, I worked as a laborer. And when they have you work as a laborer, you're not really expected to have any experience at all, and your value comes from being able to haul things around and tear stuff down. You can carry around power cables and plug them in.

And I worked at a job once where I tore a whole bunch of wallpaper off walls in a large building. You know what? I didn't have to have a whole lot of skills to do that, just the willingness to spend long sweaty days tearing [laughs] wallpaper off walls. After a while, though, because I actually had had background before that, they had me start with putting on sheetrock because I knew how to do that. And I was providing a little bit more value.

Now I was providing value as a laborer, but I could provide a little more value by actually doing some of the carpentry work. And then I started putting up some of the other parts of the walls, putting in the studs. The job I'm particularly thinking of was indoor construction in the south. So they didn't put in termite-vulnerable things. So we used metal studs, but you screwed them in. I started doing that, so I was providing additional value. Had I stayed at that particular job, I would have become an actual carpenter and become a master of that profession over time.

Well, back in software, nobody's expecting you when you start...if you're getting hired as a senior developer, well, then you should probably have senior developer experience. But when people are hiring you as a junior developer, that's not what they're hiring you to do. They're hiring you to provide value. If what they need is somebody to haul around the wires and the equipment and tear stuff off the walls, well, then you're providing value in that position.

And if you're at a company that would be interested in what you have to offer, then you belong, then you're ready. And if you don't have the skills that they need yet, well, then you should build those skills. If you're actively looking to get that career, one of the best ways to do so is to find a position where you can start to work on some of those tasks before you're necessarily full-time. Go and talk to the development team, "What can I help you with?" Most people would love to get some help with something.

I gave kind of a long answer to your question because I think that it's important to recognize that you might not be able to find a clear-cut point. You're never going to feel like you're perfectly prepared. But if you can put yourself in a position where you're helping, you're already doing the work. And I think you're ready to go full time when you're able to consistently be providing value all of the time and give more than you get, I guess I would say.

DAMON: Those are fantastic answers. Thank you. Ramses, I kind of want to piggyback off of that question to you as well since it's more recent since you made that transition. When the opportunity presented itself, what was your mindset before and after?

RAMSES: I'm probably a prime example of that question, I think. Before getting into application support in...what was it? October...no August 2020, maybe, time slips by. I had no development experience or very little. And then getting into application support October 5th is, when I picked up my first ticket. And it was a simple add a new selection in this HTML drop-down, super simple. But it kind of really sparked my interest, and from there, just on nights and on weekends, I'd go through Ruby courses and everything else.

But by the time I made my switch over to full-time development, I had maybe 160 tickets I had merged into production. Through my application support time, I tried to pick up a ticket, a development ticket every week, or a couple every week as much as I could, even if they were just small and simple, and most of them were. But sometimes, I'd work on slightly larger projects, but it was really helpful for my development, I think.

MIKE: I would point out just how closely that mirrors what I was saying, but Ramses provided help, started working on things. He was not full-time yet but grew his skills where he could eventually get to the point where he was basically acting as a developer anyway. So let's hire him on. He's already doing the work. Let's hire that guy already. And he's continued to do a great job, by the way.

DAMON: I can attest that Ramses has been a great asset and a great resource. Coming from someone he trained, he is the best. [laughs]

EDDY: Even though it's bias-ism, I agree, Damon, [laughs] cold-heartedly agree with that statement, yeah.

DAMON: Ramses, did you ever have the imposter syndrome whenever you found out or decided to become a full-time developer?

RAMSES: Yeah, I'm sure I probably did. It was something that I was long waiting for, had plans on moving into development in May 2021 and just had some unexpected events come up, so it just didn't really work out then. But I finally made that transition in...was it February, January? Maybe late January 2022. Sounds about right. Well worth the wait.

MIKE: So we've talked for a while about our individual experiences feeling this imposter syndrome and some ways that we can overcome it: working on building your skills, recognizing some of the psychological biases we have that might mislead us into thinking that we're not ready when we might be, and what we can do to be ready. There is actual value to preparation. Just jumping in completely unprepared isn't a good idea, but recognizing that no amount of preparation is going to fully prepare you. Does anybody have any closing thoughts to tie this up before we conclude our session today?

EDDY: I think it was just comforting to hear that even people who have years in the industry can also relate. And just being able to be vocal and having someone take time to listen to their concerns goes a long way with…

DAMON: The exact same thing. To piggyback off of what he said, hearing people that have had so much time in this industry and have been doing this for a minute they still go through the same things even to this day; as a newbie, it's good to hear that for sure. And it's good to know that we have people all around that want to listen and want to help because they were in that position.

MIKE: Well, let's go ahead and finish up then. Recognize that imposter syndrome is a thing. It's something that strikes most, if not all of us, in making us feel like because we're not perfect, that we don't belong here. We need to do a few things, you know, reach out to mentors, find somebody who can help you as that can make a big difference. Also, recognize that if you are providing value, then you belong. That's what organizations want is somebody who can help. If you're helping, then you're doing the right thing.

And finally, if you're wanting to grow your position, reach out and find opportunities to move into that gradually if possible. Find opportunities to help outside the boundaries of where you are. Stretch yourself. If you're not in software development, take a class or reach out. If you're working in a place where they have a development department, ask them if you can help. Can I take some tickets and work on those that you might not have time to do? And hopefully, that'll be well received. And many times, I think it will because people love help.

There are things we can do to move forward despite our lack of perfect experience that can really help overcome that idea of feeling like you don't belong. Because once you see yourself moving forward and helping people out, you recognize that you do belong there and you're making a difference.

It's been another great discussion, and I look forward to doing this again next time. Thank you.