If you don't have some kind of really concrete feedback mechanism showing you what it is that you're doing wrong and telling you that you're doing it wrong and saying no, here, adjust this weight. Do this. Whatever the case may be, you could never improve. You could hit the ball 100,000 times the wrong way and never know it. That's why having some kind of structured mechanism that gives you that feedback so you can actually improve is critical. Hello, and welcome to the Pibytes podcast, where we talk about python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldebos. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. All right. Welcome to another episode of the Pie Bytes podcast. I'm Julian, and I'm joined here by Bob. How's it going, Bob? Yeah, all good. Another week. Not our opportunities. Too many opportunities. So another special episode. This week we have another special guest. Last week, we had Christo from our community, and now this week, we are joined by a colleague of mine, which is awesome, but also another member of the Pie Bytes community, Chris. Patty, welcome, Chris. Thank you very much. I'm really happy to be here. It's been far, far too long since I've been. Had the opportunity to get behind the mic. We're really glad to have you and very excited to walk through your journey. So our purpose for this episode is to walk through Chris, walk through your journey as a developer. And the reason is, for everyone out there listening, is we just want to highlight that, you know, this is achievable by anyone. You don't have to be, you know, the 500 years of coding guru that just picks it up on the spot. Everyone has their journey that gets them to where they are. So that's a perfect segue to kick this off, Chris. So why don't you tell us about your early journey? Thank you very much. Yeah, it's. It's funny, actually. This is a very slight tangent, but not really. Actually, I've told a number of people when people have asked me, sort of like, well, how do I get into your industry? How do I do? You know what you do? And it's like, there really is. Because I do think people tend to feel like our field is very unapproachable. Like it's. It's. It's some kind of, you know, like you have to be Albert Einstein or something. And it's like, no, I swear to you, I am not Albert Einstein. It's really. It can be really good for people to understand that it's just a skill, right? Like, how did you learn how to drive a car? You decided you were going to do it. You went to driver's head and you practiced, practiced, practiced. It's kind of the same thing. So my early journey, I got my first computer in approximately 1980. It was an Atari 400 with a cassette drive and 16 blazing fast memory. Love it. Had to pay extra for the basic cartridge. So, yeah, I'm that old. It's kind of scary on the one hand, but kind of awesome on the other, because, you know, today I work pushing a button and building amazing infrastructure in the cloud at scale. So it's been quite a trip. So I am a college dropout. I never finished my undergraduate degree. That's not a great or exciting thing, but it does sort of serve to show that kind of, whatever your circumstance, you can do this as well. So I first started out in the field, oddly enough, in the early 1990s, working for a small company making, actually, TCP protocol Co. Processor boards for early PCs, like two hundred and eighty six s and things like that. And I managed. Yeah, right. It's kind of funny to think of like, we think of like, graphics accelerators and things like that that people have in their PCs these days. And back then, computers were so slow, you could overload the server simply by having a busy network and having the protocol traffic, like, bog down your machine. So that was a thing. And I managed to get that job because I was on a mud, which for young folks were these text based, you know, online, kind of like a chat, except there was more to it than that. But in any case, and this one was programmable. And he was actually kind of impressed that I had coded up a bunch of, you know, custom toys and objects and things like that. And he said, you know, we should talk. You should give this a try. Nice. Yeah, it was quite a lucky break, actually, because to be honest, I was out of college at that point. Not quite sure what I was going to do. And this is back again in 1990. For those who werent around back then, this was the first bush recession. Things were bleak out there. And I was sending a million and one letters and getting a million and one rejections. This was an era. There were bars where you could get a free drink by bringing in rejection letters. Right. Like, so it was tough out there. I didn't know that. That's a story. Yeah, definitely. I was, you know, I did not avail myself of that. But in any case, so, yeah, so I got this job working for this small company and I was a sysadmin at that point and I did, you know, but really it was such a small company, I kind of wore all hats. I did sysadmin work, I did kind of like tech support work, and I even did a teeny tiny bit of software development even back then, my next sort of ten years as a sysadmin, the, you know, the sort of themes that would be interesting to folks on this podcast were it's just kind of a lot of very simple procedural problems to solve, like scripting, you know, tasks that you would normally need to do by hand editing a configuration file here, restarting a service, et cetera, et cetera, that kind of thing. So it's just this really kind of very simple list of do this now, do that now, do the other. And I recognize that, like that's what every computer program kind of is when push comes to shove. But no, these were really just that simple. Very little conditional logic, just sort of straightforward recipes effectively. But you know, it worked and it saved me time and it started building those skills. And you know, prior to that I had only ever sort of messed with things like basic on home computers and the like. So then I ended up getting a job at a company called Wildfire as a release engineer, which is kind of a position that, I mean, they still exist, I still see job listings for them, but they're way, way less common these days. It's kind of like, you know, in between Dev and QA, you're sort of the person that handles the middle, like the bills and media production. Back when people used to actually ship media software on media. Can you imagine what a quaint idea that is? In 2021, we used to actually have to burn CDs. And that was one of the first things I did was automate. They had this really crusty old Windows machine with some ancient CD ROM Burner and flaky software that only worked one in two or three times. So you had to burn a whole bunch of bad CDs. You could get the little stack of good ones. And I said, guys, this is just absolutely insane. Something's got to give. And they were kind enough to give me an old pc, let me buy a low end modern CD writer and run Linux on it, and then the world is my oyster now I can actually write a script that automates the whole media production process and the validation so it will burn the CD, actually do the checksumming to validate that the bits are correct and life is good. I cut media production time by orders of magnitude, and it certainly made my life an awful lot easier. And that's sort of where I really got the bug of like, I love automating processes. I love taking really sort of like onerous, manual, tedious things and writing some code around them and pushing a button and watching them fly. So, yeah, that's been an ongoing theme, you know, in my career. And what has really, that's sort of like the, aside from code, that's definitely one of my core passions. And it's been a. It's been a central theme of my career from then on. That's amazing. There's an automation thing, and once you see the time, you can save, and if you can help other people make their lives easier, that's really where that programming passion kicks in. Right, right. Absolutely. You start looking for other ways, other other ways you can leverage that, and other, other circumstances, you can make use of it. So, yeah, yeah, there's so actually there's two things I want to call out there that just blow me away. So one, as Bob, you just mentioned the automation thing that's scratching your own itch. So you are looking to solve the problem for yourself first, and that's then obviously something that's going to benefit everyone else. So you're scratching your own itch first, and that provides value to other people. That's something we talk about a lot. So that is amazing. And the other thing I want to point out there is your break into this entire world from using that mud and making the little objects and stuff for it. That was you at a earlier stage in this whole technology space, but you were still building. And this is again, the message Bob and I were always trying to put out there. Just build. Just put stuff out there. If you have an idea, build it, contribute to stuff, whatever, and it opens doors in some way, shape or form. And in your case, it was someone noticing it and saying, hey, come and let's have a chat. Absolutely. Really amazing. Yeah. Thank you. And the key, one key, just to sort of play off of what you said, is having fun, right? Like, absolutely scratch your own itch. Think of find some way to do something that you will find useful. But if you, especially if you're in that place of you haven't yet broken in, this is something that you're passionate about, though, and you really want to get into this field, you really want to do this, find something that's fun for you, find something that's a joy for you. To work on and contribute to because it shows if you build something and it's really exciting to you, first of all, it's going to show in the code. And second of all, it's going to show when you talk to people about it because you're excited about it because it makes you happy. And there's this really great sort of like, what do they call that? A virtuous cycle, I guess, where you're having fun with something, so you're doing better work and you're doing better marketing and there's all sorts of like, you know, to sort of take it back full circle, neurochemical happy things happening, right? Because you're getting like hits of dopamine as you're, as you're doing things that you find satisfying. I mean, I know it's crazy to mix, you know, metaphors and sciences like this, but if you're trying to nurture habits, particular kinds of habits in yourself, these are good things to keep in mind. I love it. And it's better to find the dopamine hit from the work you enjoy than rather app notifications or piece of chocolate doom scrolling on Twitter or whatever it is that people try. Dopamine. Cool beans. So, yeah, I was a release engineer for a number of years, and that, that brought me a number of really neat adventures. I worked, you know, for the human genome project at the Broad Institute of MIT, which was an awful lot of fun. It was great having an office mate who came in every day and worked on curing dengue bone break fever, you know, who also made a mean espresso. Funnily enough, I can see the relation between the two, right. Well, he's a scientist. It was really funny. He got this espresso, you know, Kit Brewer, whatever you call it, I can't think machine, and he didn't know how to use it. But he's, he's a biochemist, right? So he says, oh, I bet I could figure this out. So over the course, I shared an office with him for about a year. And over the course of that year, he went from just starting out, whatever to making the best espresso you have ever tasted in your life. Because he's like optimizing for, you know, alkali levels and this and that, doing tests on his espresso. It's really kind of funny. Unfortunately, I never took the. Yeah, there you go. I never actually learned to make espresso from him, which was critical error. But in any case. So the human genome project was fun. And I worked for a company that did a substantial portion of the fundraising for the Barack Obama campaign here in the US. And that was really exciting for me. I've always admired him and the work that he does. I know it's politics, which, you know, can be a controversial subject, but for me personally, it was really quite an experience. It was like working for a cause. So I was a release engineer there for a few years, which was, like I say, pretty exciting. And then DevOps came along. I could see that being a release engineer was kind of on the wane. Like, companies were less and less willing to pay for that, quite frankly, although the sort of like, and on top of that, the space that release engineers inhabited, things like build systems and the like, were becoming more and more and more complex. And as the old world of, like, media production and shipping, shrink wrap software fell away and it became more of this sort of modern cloud service software milieu came into being, the whole idea of a release engineer kind of started to make a lot less sense. And essentially, even in order to do what used to be that job, you had to start acting much more like a software developer. And that's when the whole DevOps philosophy and movement came into play. So I was pretty excited by that, and I was lucky enough to be able to jump on board with another company and things like configuration management systems, like chef and ansible that allowed you to use code to build the infrastructure that your system needs to run. I love that stuff. And that's still what I'm doing in AWS. So it's a wild ride. I will also say, going from the first company where I worked, which had a relatively small stable of infrastructure, to bigger and bigger, and now I'm at AWS, which is just kind of like head exploding scale. It's been quite a journey. Quite a journey. So where did the python come in? Was that at Amazon or earlier? No, no, the python actually, happily enough. And I'm very grateful, grateful for it, because truthfully, when I started at AWS, I had a lot to learn, which we'll get to in just a moment. But the company that I worked at before that was a company called Carbonite. They do consumer oriented backups for PCs, and they were a mostly, as far as my end of things, 100% Python shop. And I had mostly been Ruby and Perl before that. So I had never really touched Python before. But I discovered that as I sort of got into it and as I learned it, I really loved it. I had been like a hardcore ruby zealot before that, because I started scripting with Perl and shell scripts. And compared to that, Ruby was this, like, oh, my God, warp speed here. Like, this is such an amazing tool. I can do such amazing things and I still like Ruby to a certain extent. Then I get introduced to Python and I realize that Python just fits my brain better. Python has a very unclever way of expressing itself, if that makes any sense at all. Like, it tends to be very straightforward code. It doesn't have to be, but it tends to be more straightforward, more readable code. And I love that it fits my personality to a t. I am not a complicated person when push comes to shove, and I. Better than complex. Right, right, exactly. There should be one obvious two things. Right, right. Readability matters. Yeah. Which is funny because it's. Are we going to decode the whole Zen now? Let's just read. It's in direct opposition to per, the old Perl slogan of everybody. There's more than one way to do it, right? Yeah, everybody just import this now. There you go. I do love the zenith. The Zen of Python actually is another really cool. When you're learning a new programming language, for better or for worse, humans make first impressions, and those first impressions count for a lot. The Zen of Python, actually, to me, counts for a lot. You type import this or import anti gravity and you get the XKCD thing. That kind of combination of real sort of, you know, hard bitten wisdom, but also a really wry sense of humor that pervades the entire community. Really spoke to me. And since then, Python has become my absolute favorite programming language, bar none. It is what I reach for, for every personal project, and I'm very happy that my work life seems to be revolving very heavily around it. So, yeah, that's where Python came in. Do you get to use it a lot at work? Oh, yes. Yeah. AWS has a lot of python, and my team in particular, I work for EFS, the elastic file system, and for the sort of infrastructure as code stuff, the custom code that we write. A lot of it has traditionally been python, so it's most of what I do. And I, you know, I love, I love it. No, that's. That's really, really cool to hear. I mean, the. For me, the key here is that you are able to work with the language that you really enjoy. Right. And that. That makes a very big difference, rather than. Yeah, because we meet people and hear people that love Python, but they currently are, say, stuck with just coding in C. That's because that's what the company needs and what the company uses. So trapped between a rock and a hard place. Right. They want to use Python, but they can only do something else. So I've been in that situation. The one thing I would tell those people is maybe try to bring some of what you love about Python to C. Right. I'm not suggesting that you code pythonic C because then your coworkers will hate you. And nobody wants that. Right? Nobody wants to be working with the person who's Java for life and comes over to Python and writes Python that looks oh so remarkably much like Java. But think about what it is that you like. What about, what about Python makes you happy and maybe see if there's something that you can leverage from that in your work life with C. Right. That's just a thought. Yeah. Yeah. So when you first got into Python, and maybe even more recently, like, how do you upscale in Python? How do you get to that more advanced level? Because although we say Python is very simple and easy to get started with, of course it's very thorough. It goes very, very deep. Exactly. For sure. It's actually really, really interesting timing in that we just had a fairly senior person leave my team as well. And she was, is amazing. And she, her programming skills were just off the charts and she rewrote, redesigned a major subsystem before she left. And I've been working in Python for like six years now and it was almost like an alien language. I'm looking at it saying, what is she doing? Like, she uses a pure functional style and it is very heavily. It heavily uses python three. Typing throughout the entire thing. Not just type hints, but like really heavy leans into the whole typing paradigm. Generics and stuff. Yeah, yeah, yeah, exactly. And it's very, it's, it's, it's. When you think about it, there's a huge difference between that and the sort of like relatively, you know, even when it's complex kind of procedural or strictly straight object oriented python that I mostly code in my day to day. So you're right, the language has a tremendous amount of depth and a tremendous amount of. Yeah, I guess depth. Depth is the right word. So how do I advance to my next level? It's funny that that sort of fits also with the general theme of the sort of, you know, my journey is, you know, I'd been working for years, starting off doing and really continuing to do comparatively simple procedural things when I had done DevOps work at other companies, again, it was for using tools like chat, financeable and the like to build infrastructure. And in those cases, you're using pre existing dsls, right? Like, so the problem space is very, very, very narrow and very well defined, and it's just a matter of figuring out how to use the parts that you're given in the right way to get the infrastructure that you want going. But when I came to AWS, there is a really rigorous engineering culture at AWS, and it was a real adjustment for me. It was like, all of a sudden, I went from splashing around in the kiddie pool, thinking I was doing great, doing the backstroke, laying in the sun, life is good. And all of a sudden, it's like, pooj, I am in the ocean and it's deep, and the waves are crashing above my head, and I'm going, oh, my God, isn't that interesting? Right? If you join, like, a big team, and all of a sudden you go from big fish because you are setting all the rules, because you're already expert, and now you're, like, small fish again, and all of a sudden it seems like this is not even python anymore. There's so much more stuff around that I need to. Right, absolutely. The thing is, though, I'm the kind of person, luckily for me, who really kind of thrives on that, in that it's kind of like a radically new experience for me, and I love that. So I'm very lucky in that regard. But that actually is how I met you guys. I shouldn't say met because we just chatted online. But how I first encountered you guys is I took the course that you did with Michael Kennedy, the hundred days of code in Python course, because I knew that, you know, like, writing code from books or trying to do Euler's problems, or whatever the case may be, is good. But after having read peak, I realized that what I really needed was a situation where I was given some structure to have truly deliberate practice. Right? Like, where there was sort of like a well defined curriculum, kind of well defined guideposts for what I was trying to write, what I was trying to build, and timelines to ensure that I was actually making the progress that I had hoped to make so that I actually would get what I needed to out of the course. And it was a tremendous, tremendous boon for me in my career. It was hard because AWS is a very intense place to work, and I was taking the course and writing all the code after hours at that point in time. So it was kind of like I must do my day of code crashing out at the computer, trying to, like, trying to get this done, but it was totally, totally worth it. Because when I came out the other side, it's like my skill level went from kind of going like this, and I'm drawing a very, very gentle curve, barely even a slope to this. You know, like, it was a. It was an order of magnitude improvement because of that sort of, like, you know, consistency frequency over a relatively defined period of time. That was so tremendously helpful to me, and I really fell in love with your platform, and it has been. It has continued to be with pybytes, a real boon to my career. That's really amazing feedback, so thank you. Of course, Chris. But the thing I'll call out there as well is that with 100 days of code and. Yeah, okay, that's a nice, fluffy wrapper around it. But at its core, it's just that consistency. Right? It's that consistency of coding every single day, of pushing yourself and not giving yourself that reason to slack off. Because if you didn't have the hundred days challenge there, you'd be like, oh, yeah, you know, I'll go Netflix. Not only that, right? It's. It's not only like I'm going to dedicate that hour, which is already tiresome after work and stuff, it's also, like what I'm going to do in that hour. Increasing complexity. So it's an hour of not just chilling out, but probably sweating and, you know, and doing tough stuff. Exactly. Yeah. It's the idea of deliberate practice. Yeah. Yes. That's exactly what I was going to say. So the. The deliberate practice you did, other than your skill going up, you know, I'm just going to, you know, dump this word in there. But did your confidence go up as well at the same time? Tremendously. Tremendously. Because the thing that had always. It struck me after the fact, I kind of realized it, actually, a few months later as I was going through my workday, and it was like I encountered a problem. I was given a sim, a bug to solve, and I sort of worked it through and I solved it. And then I had this moment of clarity, like, oh, my God. It was just a few months ago that I would have looked at that sim and said, oh, that looks like it might be a little too complex for me. Probably over my head. I should probably go find some, you know, something else to do. There's always plenty of, like, manual labor or organizing tasks or, like, whatever the case may be, I would have shied away from it. Right. Because I think there's a lot in this culture, there is almost like, an emphasis around, and it's. It's not like, explicitly said, but it's almost like we train ourselves to sort of swerve away from discomfort. And sometimes that's good. Obviously, you don't want to make yourself uncomfortable in situations where that could be damaging to you, but in cases like this, that's very, very bad because you're keeping yourself from growing. Right? Like, you're never sort of like embracing that discomfort of, no, I don't know how to do this. But if I try this and I maybe even ask for help and I maybe stretch myself a little bit, maybe push myself a little bit, maybe I'll come out the other end understanding how to do it and building my self confidence. And because the course was like day after day after day, project after project after project, in these little incremental chunks, like, oh, here's how you use an orm. Oh, no, let's use the orm to build an inventory system. Oh, now let's use that to go build something else. It's like you're building the skill slowly. It's like you're widening the scope of your confidence around the code and the different techniques. And when you finish the course, it's like, wow, I actually feel like I can now tackle moderately complex programming problems that I never would have been able to tackle before. And I don't mean to over index on that course because it's just one technique, just one potential mechanism that you can use to attain this. But, like, I desperately needed that structure. I needed that consistency, I needed that regularity, and I needed that deliberate practice. I need the self confidence boost. Man, that is. This is amazing. It's like hearing us talk about it because we go on about this, you have to be uncomfortable to grow. We talk about the deliberate practice all the time, so. Makes my day to hear you say that. And that we could have been part of that process for you. Um, but, yeah, I'll bring it back to the core, I guess, issue here. Not issue, but the core concept here that, yeah, it doesn't matter what the structure is around it, it's the deliberate practice. Right. So you. I mean, this is not a plug for our course. Right. Right. You could have taken anyone else's course. And the catch is, if you dedicated that time, that practice, and followed their structure, whatever it might have been, you know, it's the practice that gets you there. It's that conscious effort that you put in deliberate practice. Though. I actually. So there's one really key thing I think is worth mentioning, because I actually, for years I had spent a lot of time in my prior career doing extracurricular work. Right. But actually, it wasn't work. It was play, to be honest. But, like, you know, saying, oh, this programming language looks neat, I'll go try it, download it, and write some, you know, small code samples in it. Great. Now, I have a passing familiarity with this programming language, but I haven't actually built my core skills at all in the process. And so one of the things they talk about in peak that I. That was really a game changer for me, is they use the example of an athlete. If you're an athlete and you're, let's say you're a batter in baseball and you practice at a batting cage, if you don't have some kind of really concrete feedback mechanism showing you what it is that you're doing wrong and telling you that you're doing it wrong and saying, no, here, adjust this way. Do this. Whatever the case may be, you could never improve. You could hit the ball 100,000 times the wrong way and never know it. Right. And that's why having some kind of structured mechanism that gives you that feedback so you can actually improve is critical. Yeah. And not just solve an exercise, but also compare your solution or talk with others about how you could better write the code. Right? Yeah. Yeah. That's one of the things I love about, first of all, I apologize if I'm plugging your stuff too much. Just. Just slap me. But never. That's one of the things I love about the pibytes platform is that even in sort of, like, outside of a course per se, when I'm just practicing with solving bytes, I have the feedback mechanism because they have the tests. Right. And the tests, most of them, are really carefully designed to ensure that you're not just solving the problem for the most common case or for the easy case, but you're solving it for some of the edge cases as well. And so that is, again, a mechanism to provide feedback on the practice that you're doing to ensure that you are actually gaining the understanding that the exercise is meant to impart. Great. But inevitably, you're going to get stuck. And what do you do to get unstuck? Do you have some tips? Because this deliberate practice is tough. It is. It is. Or even, like, you know, in work or whatever the case may be. So, yeah, so I actually have a little checklist that I made for myself because I can definitely get to the point where I'm just staring at the code. I've really sort of reached a point of, like, I have absolutely no idea what to do here. And so the first, most obvious thing is, like, get up, walk away, take a break. Ideally, move your body, go for a walk, do something that really sort of, like, changes your mind and gives your brain a chance to actually ruminate on the problem. There's actually some really good science that exercise, and I know you guys have talked about this, too, is great for that, because it's kind of like, you know, while your body is busy, your mind can do background processing on whatever it is that you're working on. I know, obviously, you can't, like, stop in the middle of your workday and, like, you know, go run a mile, but it's, you know, even just taking a short walk or whatever, drawing a picture of the problem or its data. Right? Like, because sometimes when you do that, and there's a lot of science to support this as well, that by engaging different brain cells, by having, like, using, like, a whole brain response, whole mind, I guess, response to a problem, you are actually increasing your potential neurological processing, cognitive processing capability against that problem. So by drawing a picture of it or drawing a picture of the data structure and how your algorithm might traverse it or something like that, you can give yourself new insights into that problem that you've been sitting there stuck, you know, on for a while. Julian, stop squatting right now. No, that's awesome, though. You know, that's awesome. You know, the thing is, you know, your standing desk. It's funny that you say that, because I'm not standing right now, but I adopted a standing desk a while ago myself, and I found that that actually does improve my productivity. Because your body keeps moving. Right? Like, I'm coding, I'm listening to music, and I'm, like, literally standing there, kind of bopping around. And what's funny is it sounds like. Well, that would be distracting, but it's absolutely not, because it's like you're. You know, it's like you're engaging parts of yourself that you. That you wouldn't think. So I think standing desks are great. And by the way, with regards to this. Watch, Julian, I don't know if you have this issue. I do. With a standing desk, sometimes, like, your feet and your lower legs can get tired. And I found a standing desk mat that has these, like, contours for your feet so that as you're standing, you can kind of, like. Like, mush your feet on the contours and, like, kind of move around. They have, like, different levels. It is fantastic. I'll toss you a link. I mean, I forget the name. That's a great idea. I've just been doing calf raises. Yeah. Getting up on the balls on my feet as we build some. Absolutely. That's a very good thing. So clearly, to get unstuck with problems, the physical side, the exercise is very important. Any other tips? Yeah, sure. Absolutely. Google is not cheating. I think sometimes people can get the impression, I've sort of caught myself slipping into this, where it's like you're looking at solving a problem. And obviously, especially if it's a programming problem, don't necessarily Google stack overflow or look up stack overflow and copy the code verbatim, because then you're not learning anything. You've just proven that you know how to copy and paste. That's not helpful at all. But if you need background, if you reach a point with a problem like, where you are totally stuck and you just really have no idea what to do, absolutely google it. You can at the very least, gain background knowledge and understanding that will help you. And also, quite frankly, even just when you're not working on exercises or problems as part of your work, you got to be able to draw on the hard work of others. Everything that we do, anything that you can do with a computer, is building on the back of other people who are smart and created these amazing tools that we can use. So, yeah, definitely Google if you need to. Or stack overflow. The other thing is, if you are like me, I call this analysis paralysis, where I'm sitting there and I'm staring at the code and I'm not doing anything. And it's almost like if I stare at this hard enough, the problem, the resolution will just, like, pop out of the screen at me and whack me upside the head. And when you get past a certain point, that's just not helpful or productive. Right? Like, you've got to recognize that you're in this loop of not actually making progress. And so what I have found is try anything. Literally try anything. Even if, even if you say, I have no idea what to do here, I'm just going to change a variable, put some debug statements in there, do anything, literally anything that you can think of, because even if you don't think it's right, it may well get you towards the solution and it breaks that state of paralysis that you were in. I even use a little egg timer kind of thing to make sure that I'm not, like, falling into that pattern. And I'll just like, if I'm sitting down to a fresh problem, and I haven't tackled yet. I'll set myself an alarm for, you know, two minutes or five minutes, whatever the case may be, just so that there's, like, that reminder to say, like, hey, don't fixate. Like, just do it. Do something. Make progress, man. Beating perfectionism. I love it. Yeah. Momentum is everything. If you get started and you drop that perfectionism. Yeah, that's a really good tip. You can take that to anything you do as well, like document writing and so on. So that's a really good tip. All right, so look, before we wrap it up, I'll ask one question off the cuff. So how important to you? We've been asking a lot of people this. That's why. How important is mindset? So these mindset skills that we've talked about for a developer tremendously. Because thinking about doing this podcast with you guys actually got me thinking about, like, well, why is it that I spent so many years, I've been in the business now for 30 years, over 30 years. How is it that I spent so many years working in this industry where code just predominates and I'd always just kind of, like, psyched myself out of really going after and attacking the more complex problems? And I realized it started years ago, in fact, in the 1980s when I had my little Atari computer. And I would, you know, back then, believe it or not, they used to publish programming listings in magazines, and you used to have to type them in by hand. That's just like. It was crazy, I know, for, you know, 2021. But the thing is, a lot of people, when you hear people interviewed, like, some of the greats in the industry and programming or game design or whatever, and so many of them talk about that as this formative thing that they typed in the program and it didn't work. Well, quite frankly, I typed in the program and it didn't work. And I might try a few things, but I allowed myself to get intimidated and just basically say, well, it doesn't work. There's a bug in it, I'll go do something else. Right? And that critical lack of, like, wanting to peel the onion, saying, no, really? But, like, why doesn't it work? Like, what is wrong? I can with change this. I have the code. I have everything I need here. Just keep at it. I think influenced my whole life and my whole career. And even though it's not like, not saying, oh, it's been a terrible journey until piebinds came along, that's not the case at all. But I definitely did hold myself back from having opportunities that I could have had if I had just had the confidence to say, you know what? This is a problem. It's code. I can figure it out. I'm just going to dive in and get dirty and see what I can do. So, mindset is tremendously important, in my opinion. Oh, man. Wow, that's. This is really cool. So, Chris, thank you so much. What I'm going to do quickly now, I'm going to summarize just everything you've spoken about. I really apologize. There was one last thing, and I just want to say this real quick because I feel like if I had done this at the beginning of my programming journey, I could have saved myself a lot of pain. And also, really, I could be a lot further along than I am today. Don't do what I did. Pick a few core skills and a few core tools to using your journey to mastery, and don't deviate without really good reason. Right. Like, pick your favorite programming language and learn it. Learn how to solve complex problems with it. Pick your favorite editor and learn it. Learn it well. Right? Like the pragmatic programmers say, choose one editor, learn it well, I did not learn this lesson, and I spent a lot of years playing with bright, shiny things and honestly never really learning anything. So I'm sorry to derail you, but I felt like that's important. The shiny new object syndrome, right? Yeah, exactly. It's way more valuable to go deep with a few core skills. Yes. Yeah. It winds up. Winds up being a form of procrastination as well. Oh, I have to try out this new tool. I have to try this new framework, this new version of versus code or something, you know, and what's the difference between that and Pycharm and. Or should I use vim and, you know, it's just. There's a week. There's a week down the hall, you know? Yeah, no, I love it. Thank you for saying that. That's a really, really good point and a good lesson. Great advice. So, to summarize, and this is the key that I just love about your journey, Chris, and everything you've shared today, you started just out of pure interest. And this is where so many people that are likely listening to this art, they're hobbyists. They love just. They love the idea of coding, but they don't see themselves as developers or having what it takes to. To get there. And you are that perfect example of someone who's taken that and through sheer will, mindset, perseverance, determination, deliberate practice, throwing that back in there, you have been able to, you know, just throw yourself in there and try out something new. You put yourself out there, you built things. It opened doors of opportunity for you, and then you just ran with it. You never let an opportunity pass you by. You jump into the next big thing, and now you're working at one of the biggest companies on the planet, doing incredible stuff and using the language that you love. So I just. Very inspired by you, chris. So thank you for sharing today. Really appreciate it. Thank you very much. I count myself so incredibly lucky on so many axies. It's just amazing. So I think it is so awesome that you guys are doing what you do. And I know I love helping out anybody that I can who's just getting started. So fantastic. It's a real honor to be here. Thank you. Thanks so much, chris. This is great advice, and I'm sure that our audience will get a lot of value from it. So last question. Where can people find you and get in touch with you? Absolutely. I have a blog at www.feoh.org, and my twitter handle is feofe. And yeah, I'm on various other services. I'm on mastodon, the fediverse as well. I think anybody who's at all remotely technical should definitely check that out. Check out the fediverse. The tech content that's there these days is just amazing. Yeah, I think that's probably a pretty good list of contact methods. Please feel free to reach out. If there's anything I can do to help anybody get bootstrapped, uh, into our field, I'm happy to. Thanks. Awesome. And you're also in our slack community, right? Yes, I am. I love your slack community. I mean, I really do, actually. It's, it's. It's really cool to see people sort of, you know, just starting out, coming and asking their questions there and then more experienced people. It's a really great mix. I like it. Thanks. Appreciate the feedback. So. All right, Chris, well, thanks so much, man. We'll have all of those links to your website and Twitter and everything below in the show notes. But, yeah, we really appreciate your time and loved hearing about your journey. And hopefully those of you listening, you've been inspired by what Chris has been up to. Thank you very much. Sincerely, thank you both for all you do. You've been a huge help to me, and it's great. I think it's fantastic that you're helping so many people. We hope you enjoyed this episode. To hear more from us, go to Pibyte, friends. That is Pibit es friends and receive a free gift just for being a friend of the show. And to join our thriving slack community of Python programmers, go to Pibytes community. That's Pibit es forward slash community. We hope to see you there and catch you in the next episode.