#058 - Landing a Developer job

So much of development, I find now that I do it all full time, is not just writing code. It's patterns. It's thinking about structure and how to approach problems. Hello and welcome to the PY Bytes 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. Welcome back, everybody, to the Pivots podcast. This is Bob Eldebos, and I'm here with Josh and Gruff. Josh, welcome to the show. Thank you. Thank you. I'm honored to be here. I appreciate it. Yeah, thanks for coming on. Unfortunately, Julian couldn't make it, so he's having big FOMo right now. But, yeah, we are going to chat today together and, yeah, maybe just introduce yourself to our audience. Yeah. Hi, my name's Josh Engroff. I'm a working software developer. My background before development, software development was product management. Like my first tech job in the Internet industry, I got in 1999 working for an e commerce company, and I was coming out of grad school and some friends of mine started like, an e commerce company, and I was supposed to be the copywriter, but then I was like the webmaster, and then I was like learning on the job how to write HTML, and it was like super old school, like old waterfall process for getting projects done. And it was. But anyway, so, yeah, my background is product, product management, Ux. And I made the jump to the other side about three years ago, but in a serious way, two years ago. And then I took. I was in your PDM group, I think, a year ago. Was it a year, full year ago? Yeah, yeah, almost a year. I think so, yeah. Yeah. Tell me a bit about the transition, because. Interesting background. Thanks for sharing. Now, you're a developer, so what made you go into development? That's a good question because I worked in. I've only ever worked in tech. I came out of a humanities PhD program with no qualifications to work in tech, but that's where I started because my friends had a startup and I was always working. If you're in product, you tend to be working with developers, explaining. Usually it's explaining the what and the why, not the how of doing something. But you work with developers, you work with the salespeople, you work with marketing. And so I was always around developers, but I also realized development is very different. And even though I had been in a PhD program, et cetera. I was really intimidated by coding and by developers, and so I just avoided it. And if you're in product, you're not expected to code. So anyway, about three years ago, to answer your question more directly, three years ago I got really interested in. I came to python through data science and machine learning. I wrote an article for industry publication and I was very fascinated by the conversational chain of member chat bots. And all those things that came out became very popular. But just the automation that was starting to happen, I got really into machine learning. My first foray into Python was taking, it was, I think, a udacity course in deep learning. And, and it was so, it was like, it was tar. It was marketed to people with no background in Python. It's like beginners and it was so miss targeted. Like, it was very, I mean, I still have the notes, it was, it was fascinating, but it was, it was unbelievably hard. But long story short, I came to python through data science, but when I got to Python, found that I loved the backend stuff. I bought every beginner's book and I think I took, I spent quite a bit of money. Like, I took general assembly course. I did a couple of udacity courses, which weren't at that time very cheap. Did a coursera course. That one was Andrew Eng on data science. And I felt like I was dancing around a subject, but I didn't really. I really wanted to be a developer. And so I basically turned my job by then, job where I was the technical product lead. I started to code in the job to find a reason to do it on the job and to make it useful to other people. So I coded some admin tools. I was very much working in Jupyter notebooks. And then now, to finally answer your question, about a year ago, I just realized that this on my own, kind of bootstrapping it, I just maxed out where I was going to be able to go. I was working with a development team in my last job, but they were in Russia and they were all working in node js. And so, yeah, it just became, it became very clear that I needed a coach, and I didn't realize at the time, but I also very much needed a mindset shift because I was still very much intimidated by people who could code and, you know, and couldn't quite imagine myself doing it. I listened to your podcast before I joined, and I also started talking you on Facebook, and I would respond to your posts every now and then. David spoke on Facebook. Yeah. So to break this down. Yeah. Decoding on the job, that's great advice overall and a great way to get started. Right. Like, that's similar to my story where I was a support engineer. I really wanted to become a programmer. But you're not confident enough to apply, nor would you have maybe enough skills. Right. So what can you do? Well, look around. What problem can you solve on the job? How can you best use your current situation? So that's great. So then the follow up question would be, so you got a bunch of coding done. You obviously learned a lot. Where did you feel then? Still stuck after doing that for a while? What made you reach out where you saw that gap? I think, yeah, I think the key moment when I realized, I realized two things in this key moment. One is like, okay, this is real and I actually am starting to own it, not just following someone else's instructions. And two, it's also going to be harder than I thought because I want to build my own stuff and so I really do need help. And this is, you know, I think for me, my first experiences with coding were very much, I bought all the books I spent. I mean, I have a lot of money, but I bought, like the Ned Shaw book about the Al Swigart book. I bought a bunch of recipe books from O'Reilly, kind of just like haphazardly, like stumbling through the dark. And I would read about these things and I would go back and then, and then I would do tutorials. And the thing about tutorials, I find it's very much like a recipe, a food recipe. You could be making cupcakes and it's kind of like a modest tutorial and your time commitment's not too big and you know what you're getting into. Or you could be doing a buffet for ten people, so to speak, to use that analogy. And you're halfway through and you're several days into it and you realize you're not that interested in the outcome. And that's happened to me a couple of times. And I realized, okay, for this really to work, for this to click, I need to build stuff I want to build, not build somebody else's scheduler. Are you stuck in endless commutes? Have you ever dreamed about being able to work anywhere, control your schedule, give back to society, become an open source contributor, or become a successful developer, doubling your salary? Well, it's time to look at the PDM program, and it's time to actually build something that's going to help you get the future that you're looking for the people that we've worked with in the PDM program have achieved some incredible things, including starting their own SaaS business with their own application. Imagine that. That could be you building your own application, selling it, making your own income. We've had people more than double their salary. I'm not making that up. I'll say it again, double their salary. After completing our program and applying for developer jobs. These are the sorts of things that you can actually achieve through ten weeks of dedicated life coaching in the PDM program. So here's the challenge. If you are actually serious about taking your future into your own hands and not letting someone else control that for you, click the link below and get on a call with myself or Bob. That's right. We want to talk with you about your goals and how you can use Python to leverage your career. So book a call below and we cannot wait to talk with you soon. Tutorials are great, and I'm. I have great admiration for people who teach like you guys do and who also write tutorials, because I know it's not easy, but often the point is to show your technology. The point isn't to produce something really cool, except for the Al Swagger examples where you are actually producing stuff. Cool, cool stuff. So I think the first thing I did on my own, which was creative, was I created a little chat app and it required me doing a little bit of a test driven development or test driven IO course, but then going off into my own, into the woods and realizing, okay, now I'm going to use postgres or I'm going to use Mongo and I'm going to, which wasn't in the course, and I'm going to use Twilio, which was also not in the course. And they're using flask, but I'm going to use fast API. It's kind of like that point where as a chef, I imagine, because I'm not a great chef, but where you realize lamb and garlic and rosemary are three things at elemental level, go well together, and I don't need to follow a recipe to be able to use them in this or that dish or this dish. And so it was kind of scary. But when I sort of took the leap and started to create my own stuff, that's when it both got more like kind of magical and amazing and harder. And that's when it became really clear that I needed, I needed a mentor. And you got, and it's wonderfully named developer mindset. To be honest, going into it, I was sort of discounting the mindset part, because I really wanted, like, a code mentor. I wanted to do code reviews. I wanted to, like, I remembered it. Yeah. And then. And I was just, like, stunned. I'm like, oh, my God, it's so much about the mindset, too. It's like, really? Yeah. So that's an amazing. You and Julian figured that out because that's an amazing calculus. It really is. So what was it about a mindset, then? But that surprised you? Where. Where did it hit you unexpectedly? Like, wow. Oh, shoot. The mindset. Yeah. So I had spent. I had spent. I had a career, you know, 15 years doing something that I got quite good at. I mean, hopefully. I think anybody can get good at something if they focus, and they spent 15 years of doing it, and I had a career and I had big titles, et cetera, et cetera, whatever. And I have two kids, and I had two kids then, and it was like, the risks of switching of massive content, like, going back to being a beginner, because I didn't have any illusions about developing. People like to say, and I think it's really kind of a not helpful thing, people like to say, python's easy. That's kind of like saying Spanish is easy. I think the friction to get into the language quickly is low. But once you get into it and you really start to try to do stuff, you realize it's vast and it can be complex. There's something about becoming. I don't know, there's a name for it. I'm sure you guys know the name. But becoming good at it in a skill, which is your livelihood, like, you depend on it for money. There's a lot of existential things tied up with what you do for a living. Right. Because it's your financial support, it's your manifestation in the world of being productive, doing something, and the whole idea of leaving and doing something, that's really hard. Where I would be a beginner, I mean, I have a lot of context, but I would be a beginner was. I just went into. It was. It was intimidating. There's something. There was something. Thank God there was something in me, and I don't know what it was. It was almost like I had no choice. I had some drive once. I think I made a mental decision to pursue programming as my, you know, the rest of my career. Some part of me is like, you just got. So I would always go. Even when I ran into big roadblocks, I would always come back to it. Like, if I got really frustrated, I would come back to it into days, not because I said, here, it's on my list. I got to come back to it. I just would be drawn back to it. And so I would beat my head again against the same problems and I would eventually figure them out. But yet there was a lack of confidence and a real intimidation with coding interviews. For example, I had a coding interview before I met you guys where I just froze. It was my first ever live coding interview and I was doing some, it was like your typical, never going to see this on the job kind of algorithm thing. Um, and I've kind of froze. And I just sort of like bowed out of the interview. And it, it wasn't until I was in the, in the groups with, with you guys and some very senior developers who were in the group, too, and hearing, hearing them say that they sometimes had imposter syndrome or they felt like saying the same things or having the same concerns or voicing those in that group made me feel like, like, oh, I'm not a freak. It was just, it was a completely, I can remember the actual conversation where I think it was, I'm not sure it was Eric or somebody. He voiced the internal anxiety I had in my, in my little voice that says, you can't do this. And I was like, it changed everything for me. It was like, oh, my God, everyone has this. You don't really realize what's going to make a difference in terms of your confidence, but that made a big difference. It was just became more real, I guess. Not that every, you know, every coding interaction I've ever had or, you know, every other interview I ever had was flawless, but it was a, it was a, it was a, it marked a definite shift. Cool. Right. Now that's, uh, that's good to hear. And, yeah, being in such an environment and realizing that we all have imposter syndrome to a certain extent and never really goes away. Right. You need to embrace it and you're going through that experience of failing a coding interview, then doing better. So flashing forward then to, I mean, you got the developer job. It definitely did. You became better at the interviewing. Right. You got that job. So what are you doing these days? I work for an asset management company, specifically for the real estate private equity group. My group is portfolio management, which means forecasting cash flows to try to ascertain at what point to sell the asset. So we buy an apartment building for save $1 million. It's actually usually quite a bit more than that at some point. And we leverage it so we have debt and then we have, it's an income producing property, so it generates rents. And so those rents, you can do calculations with those future cash flows to determine what you think the exit value will be in x years. And then it's a lot of financial modeling, and it almost all happens in Excel. And so this is an example of a lot of people who are doing some pretty sophisticated modeling in Excel. Some of them don't realize it yet, but the people I work for specifically, they've just reached the absolute limits of Excel. And it's quite amazing. And so sometimes when we think about or talk about the really cool tech jobs, it's like, oh, it's computer vision or whatever, it's some kind of neural network, et cetera, with three layers. But what I found is a lot of the bigger problems are lower hanging fruit, where it's just about using tech, not even sophisticated ML or deep learning to automate things that have reached their natural sort of extension, where humans are no longer effective at this thing, for example, because everyone uses Excel files, they get traded around, they get, of course, they have terrible version problems. They also get bogged down and sometimes don't open. It's really hard for the organization to have a collective intelligence around a certain batch of assets. My job, and right now I'm working on it alone as a sole developer, is to build a software application to replace what they're doing in Excel. That's cool in itself, replacing Excel, because Excel clearly has these limitations, but also the theme of your work being part of that modeling, which influences the decisions to acquire or sell, whatever, that's quite a responsibility. So, yeah, so, right. I mean, one interesting thing about, I was ecstatic when I got the job, my first developer job, I'm gonna do like, I'm getting paid to write code all the time. I don't have to, like, I don't have to like sneak hours or, you know, make it only evenings and weekends. But the flip side of that is like, I'm getting paid to code and I've got to produce work and, you know, it's, and so I had, there was a moment about like a couple of weeks, you know, I think probably a month and a half ago or two months ago, where I got started to get like that, I started getting nervous that maybe what my code wasn't going to be. This is my first major delivery. I'm the only developer on it right now. Maybe it wasn't going to be great. And then I think actually I went back to one of your co clinics and to Julian's mindset calls. And it helped me get out of that place of like, fear of making mistakes, because what I didn't realize is that, that writing, you know, writing applications or producing software is, it's inherently a creative act. It doesn't get enough credit for being that it's not just tink, you know, engineering and what we think about as engineering. And so there's an element of risk involved, but also an element of like, of figuring out yourself and kind of ownership. And I was, I guess I sort of hit that bridge and was, became sort of locked up and a little bit scared. And then anyway, went back to your clinics and they helped me get out of that mindset. But what, what did you hear there that solved that? Um, you know, I was, uh, I was asking a question in the forum about, um, how to do x, y, z. And I, I'm not sure it was Antonio or, or will or somebody, somebody said, or maybe you said, you just, just do it the way you want to do it and work through it and you'll, you'll figure it out. And I realized then too, which it seems naive, like, there's not always an exact way to do something right. These tools allow you to do a huge and various very different number of things, and there's different ways of accomplishing those things. And for some tasks there's obvious ways to do it and some tasks there aren't. And you just gotta sort of go, you know, sort of move forward and that. Always moving forward. You guys always make that point. Always moving forward. That makes a big, big difference because there have been days where I'm just like grinding and I'm just working on a problem. Like I can't figure out how to get pretty low data into the database and I'll just keep doing it even though I'm frustrated. And the next day, or when eating breakfast or something or not specific is an email I guess you guys have for this. I forgot what it was, but I'm not specifically drilling on that thing. The solution will sort of occur to me. And so just to click always moving forward kind of approach that you guys espouse is super important to me and it's become helpful in rest of my life too, actually. You need to basically step away from problems. We have spoken about that many times here as well. And also I think it's in our nature as developers to always want to optimally prepare the tutorial paralysis. I remember when I started my first dev job, reaching out to the manager, like, what's the stack and then geeking out and having to learn all these technology upfront, buying a stack of books because I had to learn SQL alchemy and postgres and whatnot, and then to only discover that. That was the least of my concerns when I entered the group because it was highly contextual to the solution. I had to learn the domain first, what it was about, and the python was just a small part of it. And the frameworks I would just learn on the job. And these frameworks were highly customized. So even from going back to your example about the tutorials, even if I had read the whole book, it would have been theoretical and not applicable to the actual job. It's always different, right. When you actually get on the floor. Yeah, there's a saying, like, I'm not sure it's exactly germane, but, like, we suffer more imagination than in reality. So, like, my idea of what I should be able to do with this particular job and this application is, it's, it's actually much bigger and grander. And I've got it. Like you said, I've got to be an expert in every framework, actually. Well, the day to day is not like that at all. It's like, I've got to, I've got to learn this subject area and I've got to do these things over here. And it's, um. I found that when I was just doing tutorial after tutorial, a kind of rigidity sets in where you're like, if you encounter a problem that doesn't look just like this one, then you kind of lock up. I was doing that a little bit, and I guess it's, with anything that's complex and requires new skills, you have to sort of, these are, there's a certain element of, like, risk taking or like, I'm gonna make it my own now and I'm gonna do it my way. When you find your own kind of flow or you find your, you find you have your own opinions about how to do something because you're making up your own mind, not just following somebody else's rules set. It's kind of a, it's kind of an amazing feeling and it kind of snuck up on me. So, yeah, no, thanks for sharing that and happy that you got through that transition and got more comfortable in that uncomfortable of the new job. Right. And maybe do you have one more piece of advice for people that aspire to become developers and are where you were one to three years ago and they tried to get a developer job and they find it hard. What's one more piece of advice that you can give or audience. It's a piece of advice I learned from your. It sounds like I'm just chilling, but this is all authentic truths. I don't think I would have this job if I would have gone back to product or something if I hadn't met you guys. And that's why I'm still hanging around a year later. Right. PDM is not necessarily a year when you first do it. Anyway, so the thing I heard was voiced by somebody else in one of our groups, which was about interviewing. And it kind of de stressed interviews for me was like, just see it as practice. I mean, if you're, if you're really actively looking for a job, you know, becomes its own kind of part time job, like it's, you know, devote a lot of energy to it. First of all, there was an amazing change when I got Julian's, like, help to reshape my LinkedIn so I could tell my story now with the developer frame on it. And, you know, it was the, it was a lovely sort of feel and I'm sure it's like times ten for really experienced developers. But like, the inbound recruiter emails were like, they're still very strong. So that's a wonderful thing about our profession, I have to say, in general. But, um, so I would respond to the ones that I was genuinely interested in. So I wasn't taking throwaway interviews. I was, I went in caring about them, but I, I started treating them like practice. And it, it de stressed the individual interviews. So I wasn't so worried about, if this one doesn't go right, I'll never have a job again. Um, and I kind of like turned them into practice and I became okay with not knowing or just getting better. Like, I should have known that first, very first tech interview I had. I probably should have gone in knowing, like, this is my first one. It's probably not going to be perfect. Don't sweat it. But I didn't. I went in thinking I got to nail it and I froze. And I think if you do, if you get to the habit of interviewing when telling your story and doing these different kinds of coding challenges, in my experience, it's not just solve the algorithm. Sometimes it's a take home thing, sometimes it's a pair programming thing. It becomes more natural. And that's the key. If it becomes natural and in the flow of the interview, specifically about finding a job, then good things will happen and that's the place to get. And it took me a while. And it certainly was. I benefited from the advice of you guys and others in our group. Sweet. So really expectation thing, right? Saying to yourself, this is just one of the many interviews I'm going to have. It's a numbers game. In part, every time we're going to get better. I think there's also a little bit of a fake it before you make it kind of element to it. Like, it's not only about the pure code you get to write in an interview. How can you talk about it? I mean, I got stuck on a tree algorithm one day. I kind of messed up. I mean, technically coding, but I was still turned out later because I got the job and I spoke with the person that interviewed me and he said, well, yeah, I mean, the code syntactic was kind of messy on the whiteboard, but you could really argument, well, why, how this worked from a design perspective and that counted. So don't get obsessed about the actual whiteboard. Yeah, there's also reasoning and how to explain stuff, and that goes a long way. Yeah, I didn't realize that either. I thought it was going to be like I had to be a savant with a syntax and, and really, you're right. Reasoning about structures and how to approach problems and working through the problem step by step. I mean, if you have a regex problem and you don't remember every little piece of syntax with Regex, which most people don't have necessarily handy, you can, you can walk. I mean, I think Julian actually uses this example. You can walk through it saying exactly how you would do it without having to actually write the, you know, the final solution. So that's a really good point. I did not realize that when I went into the. So much of development. I find now that I do it all full time is not just writing code, it's patterns. It's thinking about structure and how to approach problems. And that, to me, is a wonderful intellectual experience and challenge. Often, yeah. If you can grow to that more senior level and do more design and architecture, you might be writing less code and you will be spending more time on code, reviewing and thinking about the solution as a whole. And that's fascinating. It is fascinating. Yeah. I mean, I'm not quite there yet, but I can see, I can see it. That's another nice segue, though. What's next? It's funny. Now, going into the engineering role, I kind of like, stopped wearing the product manager hat. And then about a month ago, the project manager in me says, you know what, you really need to staff this product a little differently because so it's got a heavy backend component, it's got a DevOps. So I'm doing everything. I'm doing back end, front end DevOps, but I'm not great at front end. And so that realizing that was important, like, there's things I really like to do and I think I'm good at, and there are things I'm not good at. I should acknowledge those. So we probably need a front end developer, but I've been writing, doing a lot of work in Vue js. I like JavaScript, actually, quite a bit, but I know it's heresy, but actually it's not heresy really here. So, yeah, so building out the team a little bit more, launching of MVP at the end of March is next. And then if all goes well, and this is an internal tool in building and it gets traction and it gets adoption more across the organization, it could become quite something. And one of the goals is to build it, is to build something. It can be used by the rest of the company. It's a large company. And if that happens in any fashion, then we'll be growing a team, which is great because I'll be at the ground floor. So that's pretty exciting. Exciting. Congratulations. Thank you for getting that job. Because it's not only the job and the coding. You have a clear way forward and sounds fascinating. What's ahead of you? So my final question is, what are you reading? I heard you guys discussing this in your podcast with ed, and you were reading some. You were in like two books and eds reading books. And then Julian's like, I'm not reading anything. I don't finish him, though. How can you, like, you read microservices architecture, 500 pages? That's a tough one. I'm usually reading a textbook and a, like a novel. I'm not reading a novel, but in terms of. I've been reading. You know, it's funny, actually, right now I'm not reading anything, actually. It's not true. I've been. I've been doing a lot of reading Django because I work a lot in Django now. I did not expect to love Django as much as I do. It's very powerful. But the last really, really good thing I read cover to cover was the one that we all read was a hell of typing advice or tips. Well structured. What was it, the robust python. Oh, yeah, I read most of that. That's a great book on Titan. Yeah. So that's the last one I read. I think I'm taking suggestions for the next book though. Oh, putting me on the spot. Let me go through my stack. You're always reading something. Yeah, one book I'm reading and enjoying is Anand Johnson's Bush or Django DX, and I'm 30% in and it's mostly the tooling for Django and for development and already picked up some really cool tricks. So yeah, I highly recommend that book. Bush your django DX by Adam Johnson yeah, Adam. Joshua Yep, it's about tools that make your Django development experience better, right? It's not about Django specific things. Yeah, it's more about like being more more effective developer. Is it applicable to development in general in Python, or is it specific somehow to it's a bit Django focused, but definitely a lot. What I've read so far is super generic to any Python developer. Yeah. And shout out to Ryan, because I think Ryan pointed us to that book on Twitter or Slack. Yeah, I really appreciate your time and having me on the podcast. Bob. Yeah, no thanks, Josh, for this awesome interview. So thanks for sharing your knowledge and experience, and thanks for having me. 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 pybikes.com slash community. That's Pibit es community. We hope to see you there and catch you in the next episode.