What are the low points in your career? This is the question that we kick off today's episode with, the second part of my interview with Michael Kennedy. Michael is the host of Talk Python to Me. He's also the author of a couple of Python books, and he is an excellent podcast guest. And I'm excited to dig into these kind of more personal things with Michael today. Thank you so much for listening to Developer Tea. If you missed out on the first part of this interview, I encourage you to go back and listen to that so everything in the second part makes sense. Thanks so much for listening. Let's get straight into my interview with Michael Kennedy. What is a moment in your journey as an engineer, in your journey as a podcaster even, where you look back and you say, that's a moment where I felt totally unsure. I felt... Maybe down or lost or not really sure what was going to come next. Do you remember a moment that was like that? How many episodes you got time for? No, certainly I can remember times like that. I remember some of my first, like one of my first programming experiences was I was in a math research group, and we were using MATLAB in very basic ways to do some analysis and some how-to. And now folks had gotten money to get a Silicon Graphics mainframe computer that we could all work on rather than just personal computers. They're like, all right, we got to program this stuff. And it does cool graphics. So let's program it with C++ and OpenGL. Nobody here knows how to do any of that. So how about we get you a book, Michael, and you can just go do that? What? Excuse me? But that turned out to be a fantastic experience and really changed the trajectory of my career. Another one, I would say probably the most significant thing that I did that was uncomfortable, but also awesome was to get into public speaking around technology. So I'd been sort of working mostly on my own, maybe with one other person, you know, just reading books and doing whatever. And then the opportunity to give a presentation at a user group came up. So I did a bunch of studying, came up with a whole presentation and something I was really interested in. And that really opened my eyes to how much technology can be beyond just writing code to create software. But it can be, you know, working with people, communicating these ideas. And once you start doing those kinds of things, it just, it puts you in a different place. And so I really encourage developers out there to go out and just do some form of public speaking. And I'm not necessarily talking like Toastmasters or some random thing, but something that you're really into. And I'm not necessarily talking like Toastmasters or some random thing, but something that you're really into that you're, you know, would be great to talk. Like if you just did a bunch of cool stuff with Docker, you know, give a presentation on Docker or whatever. And that is a huge step that I think changes the type of stuff that you can do in technology. I'm going to play, I'm going to play the role of a, of an engineer that heard that. And they're like, oh, well, here's my handful of reasons why I'm not going to do that. All right. And I want you to, I want you to tell me why I'm wrong. That's what I'm looking for here. Yeah. Yeah. All right. Absolutely. All right. So reason number one that I don't want to go out and do public speaking is because I barely just started on this. I'm a brand new engineer. Yeah. Anything that I have to say at this point, I'm not confident enough in, but also like it's probably not worth anybody's time. Yeah. And that's a real challenge, right? Like, so there's two angles. One, you could look around and say, well, what am I doing day to day? And is there something? At the end of the day, you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and from what folks are talking about. That's, you know, that's probably after like a year, right? Like it's probably not right away. If it's really right away, something that you could totally do that would be perfect was let me tell the journey of becoming a software developer. And here are 10 tips for helping your junior software developer be better. Here's what people helped me at my company. I really appreciated this. I really hated that. Here's, here's my journey, right? They almost like, uh, uh, telling the story of what you would have journaled or like if you're into journaling, I'm not into it, but maybe people are like that kind of stuff, right? You're an expert in that. You're more of an expert than the people that have been out for 20 years. Cause they didn't come up in this realm of, um, massive abundance of languages and libraries, right? Like when I learned programming, it was their C plus plus, uh, Java had just come out. There was visual basic. There was a few languages. So it was really, like, well, which of these fewer choices, it's really hard to become a programmer now, right? I mean, even choosing the language are so many, but then what do you specialize in? Is it front end back in? Like you said, is it a data science? Uh, there's just so many choices. Like I want to draw a picture. There's 27 different things I could learn to do graphing and visualization, right? Like it's, so that's a different challenge. And you would be an expert in that now. Whereas I have been, I've been doing this 25 years. Didn't have that problem. Yeah. So, so I don't have a framework for answering, you know, how to solve that problem. If I, if I've been in this 20 years, right. And that's such a good, you know, that's exactly what's in my mind is as the opposite of the devil's advocate here is, is the idea that, you know, my beginner experience is very much removed from today's beginner experience. When I started at, you know, I started as a front end engineer, reacts didn't exist. And so I didn't have this, you know, massive ecosystem. It was like, You probably fought between, yeah. You probably like I use I can't handle different browser versions. This is a hard world. Yeah, exactly. New problems are right. Yeah, exactly. Yeah. It was like, oh, uh, how does, how does the box model work in this over here versus over here? Oh, okay. Yeah. So if you were a beginner, I think that those are the kinds of things that you could present either to like a brown bag at your company, or like a, you know, like a, you know, like a, you know, like a, you know, like a, you know, like a, you know, like a, you know, like a, you know, like a, you know, company, how could we help other juniors in my company or at a bootcamp or meet up, whatever. Yeah. I think the, the, what's, you know, the misperception here that's, that's at the core of this is like every tech talk that you, uh, that you attend or that you put out has to have the same level of, uh, first of all, like technical, what do you call it? Content? Like what the technical, I guess, uh, a core, right. Has to be similar. And that's false. And then the second thing that I think a lot of people get wrong is I'm supposed to be doing this to teach everyone else something that they've never heard of. I think that's kind of maybe an unexpected or a default assumption about tech docs is that I'm supposed to be giving you something that's fundamentally new. I'm announcing to you something that you, you know, a part of the API that you've never explored before or a totally new way of doing things. Right. And first of all, that's, that certainly is not the case because we'd be out of tech docs pretty quickly if that was, if that was true. But also when we teach people things through, through public speaking, we're not just teaching them about a technical thing. We're teaching them about our experience with tech. And I think that is what, what gets discounted, which leads me to my second, my second reason to not do a tech talk. And that is, you know, I feel like anything that I could talk about has already been covered by 20 different people. Why should I be number 21? That I think is a more valid concern. What I find a lot of times is even though something may be covered in one, in one venue or medium, it's not covered in another place. So maybe at the main conference for what technology work in, for me, it would be PyCon. Maybe there's already been a talk on that, but my local user group has not had a talk on that. Or even in these days, there's so many remote user group presentations, and they're just looking to, to have some time together and some inspiration. And so even if it's been covered before those people did not see or hear those, that topic there. Right. So there's usually something that you can, you can find and just choose a venue, right? Start small. Don't start in something big and stressful. Start in a small meetup or brown bag at your company with people who already kind of know and trust you and it's comfortable. Yeah. There's that. And then the other one is you sort of touched on it as you were leading up to this. It's the goal is not necessarily just, or even to communicate. Here's the deep internal technical knowledge that you need and so on. It could be to inspire or to shop around, right? Like, yeah, I want to do a presentation on Vue. Okay. Well that's maybe we've already had a bunch of presentations on Vue.js, but what if it was, here's, I want to compare the same app built in Vue, React, this and that. And as a beginner, my experience was this, or as a expert, my experience was this. And here's what I would love to see in the next version of Vue, or here's what I would like to, you know, these are the choices I want to make. And then the other one is, I want to compare the same app built in Vue, React, this and that. And I want to compare the same app built in Vue, React, this and that. And I actually think this other thing is better. I think there's a lot of ways in which you approach that, that are wide open. Yeah. And, you know, the audience will change based on how the message is presented, which is really the messenger. So you could have the same exact content delivered by two different people in two different audiences are going to hear it, right? They're going to be able to, to, uh, uh, absorb that message in different ways. And so I think it's easy, especially in technical discussions, it's easy to believe that covered once is enough because it feels, like you said, cold, right? The cold, you know, we don't need another of the same thing. But I think the misconception is, well, it's not the same thing because the messenger has changed and therefore the message itself will have the kind of that imprint from the messenger. And so you're going to end up with, you know, React talks about hooks. It seems like we've had enough of those, right? But there's probably another talk out there that React engineers, if they heard another talk about hooks, it might enlighten something in them that they hadn't really thought about before. And it could be very, very sad. Similar content just presented in a different way. And I think that's very few times is somebody going to be like, well, I'm pretty sure there was a talk on this back in 2017. So, you know, you're invalid. Like suddenly you've lost all ground, you know, that just doesn't happen. Yeah, it doesn't happen. I think really there's all these opportunities. And once you start getting into that space, you're like, oh, here's four more ideas I could do. And then here's a bunch of other ideas. And all of a sudden you are submitting five, six talks to a conference and see which ones they like and whatnot. And the reason I was really excited about this is it just opens up new opportunities that are so hard to get. If you just work at a company, heads down, writing code, I mean, that's great. You learn a lot. But all of a sudden people see you speaking up there at the podium. Hey, you know, that's cool. We actually, this other place, we've got this new opportunity for you, or like maybe you would be interested. It's kind of doing what you're talking about. Just it. It puts you in a different space compared to other people. And if nothing else, you just make these connections with other people doing amazing stuff like that because now you're one of them. Yeah. I really like this idea of career crafting and starting with something like this as a way to say, hey, I'm going to branch out beyond whatever my normal kind of responsibility is to my current employer. Right. That's not all that you have to offer in your career. And that's not to say that, oh, well, you know, then point blank, a best practice for everybody is to go and speak at a conference, but rather to say who you work for is only a part of what you can do in your career, right? You can go beyond that and develop a community beyond that, for example. But also you can be, you know, the way I think if you choose to be an engineer, you're not an engineer because of your employer, you're an engineer at your employer, right? Like you just, you've kind of chosen to be there. And what this means is like, if you didn't have a job, you could still be an engineer, right? Like that's, that makes sense to me. And so, um, I think that this is a step in that direction, right? It's like, oh, I'm doing something as an engineer, outside of my work. I'm suddenly kind of freed up mentally to think, okay, I have opinions and I have agency beyond whatever is just bringing in the paycheck. Yeah, absolutely. If you want to be successful, both in terms of having a good job that pays well, but also being able to work on the technology that you want to work on, you've got to take control of your career. And it's not enough to say, well, my company didn't give me training on topic X. It's 2020. You can find that on the internet, right? But you've got to decide you want to go in that path and take those steps. Another example of this that doesn't involve public speaking, but it's kind of in the same vein is you could find a way to take on roles within your company that you might not be super comfortable with, but would help you grow. Right? Like we don't really have a continuous integration, continuous deployment story. It's always painful. And they have us come in on a certain day and there's like downtime. And I think I want to solve that problem for us. Like, I don't want to have downtime anymore or something, you know, like if you work at a company that's not necessarily a tech company, right. And you could say, I would really like, raise your hands. I want to learn Ansible and CI and testing and make that happen. Right. If that was something you wanted to do, you know, I would definitely do that. But I think that's a way to like grow yourself really positively would just to be, to like step up and, you know, volunteer yourself for those types of things. Yeah. Yeah. And it is definitely a multi-factor kind of solution to think about your career beyond the terms that you're used to thinking about it. And rather, you know, especially this is, this is particularly for younger engineers. Somebody somewhere in your career, you know, you're going to give you a picture of what career progress looks like. And I can guarantee you, it will be incomplete because in this industry, which is more than one industry, there's, I mean, it's not an, it's, it's really not just an industry on its own in the same way that like accounting is an industry on its own. In some ways it's, it's kind of like accounting and that every type of industry needs accountants, right. As long as they're, making money in that way, it is kind of multi industry. It is similar, but it's not similar in the sense that there are so many different types of of engineering roles, right? There's, there's all of these completely different responsibilities from one engineer to the next, from one company to the next, but you can't really call it a, a singular industry. Right. It really isn't that. So any picture that you get of, Oh, this is what career progress, this is what a, you know, a senior software engineer, you need this amount of experience and these core skills that might be true at a company at a point in time, but very broadly speaking this, this is a very difficult industry to have a kind of standardized path in, right? Because it's not, it's not just a general, you know, it's not a single industry. I think the other, the big thing there is that the knowledge that you have has an expiration date, right? Yes. Yeah. And so you are either you have two choices, either you can sit there and just do the same thing and it'll sort of taper off in terms of value, but then you've always, you've always got to keep growing. And do you grow in the way that you, you know, somebody else is just directing you, like, we just need you to go do that, please. Or do you really want to, or do you want to be more proactive about it? Because it can be super proactive and it's really valuable to do. I think so. You just, you know, you got to always kind of be your own advocate, I think for your career. And I would say one of the common themes under these things that we've been talking about is like, do something uncomfortable. Yeah. Yeah. Do you, I mean, doing uncomfortable things certainly stretches you. I think it's also interesting to know, like exactly what you're saying. I'm trying to rewind back to some of my early career experiences and I'm trying to think, okay, how do those contribute to my current competency, my current work? Maybe not at all. Right. But in some way, those experiences do have similarities to what I'm experiencing now because they are ways of problem solving, right? These, these kind of more abstract skills that we have to develop as software engineers. And you think about an engineer from, you know, the software engineer in the eighties, they have such a different, just landscape to work in, but that, that experience still matters if they're in the field today. Why does it matter? Not because they have some specific esoteric language memorized, right? That's not the value that that experience gave them. And not because they built some incredibly complex system either, because we just didn't even have the ability to do complex systems with computers back then, right? It was, it was a totally different system of constraints. What we, the value that that produced for those people, those engineers, was that they were able to do complex systems that they were able to do. And so, you know, I think that's, that's a really important thing. And I think that's, I think that's a really important thing. And I think that's a really important thing. is stripped of all the specifics of the technologies, right? Like all of that stuff falls away. And what, what is remaining is they had a, a problem to solve. And I know this sounds, this is very cliche to be like, oh, I'm a problem solver, right? But they had a problem to solve and they had really kind of these constraints to solve it with, and then they were able to do it. That's kind of the, that's the, that's the, that's the, that's the, that's the, that's the, the core kind of human skillset there goes beyond whatever tech you're choosing to use. Yeah. Yeah. I did an interesting episode on my show called beginners and experts had Ned Batchelder and a panel of beginners who were, had just all gotten their first job. And so it was sort of, what was your experience coming in? And one of the really interesting takeaways was as an expert, you have so many things where you're like, I've seen that problem before. And I've solved it not necessarily exactly the same way, but this is a lot like that. And we tried three ways. Those two were bad. This one was good. So something like that in modern terms of libraries and technologies and whatnot, probably is what I need here. Right. And I think that that skill that you build up, like that's, that's pretty universal. Yes. I, you know, pattern matching the, the idea that you can see something and say, oh, I've been here before, or I've been like, this feels familiar. Right. That is the kind of that fast system of thinking where you have some intuition for what direction to go. Whereas when you're a total beginner, everything is like, I have no direction. I have no intuition yet. And so a random guess is almost as good as what I think is an intentional guess as a beginner. Yeah. I've seen a lot of people struggle with like the equivalent of writer's block in a blank white page or blank white word editor. It's just like, I have this, I've opened up a page and I've got a blank white word editor. And I've got a blank white word editor. And I've started a project and I have no real idea what steps to take. And so just learning to take those steps, you just got to just try some stuff, bounce off the walls a little bit and, you know, build up some experience. Yeah. Yeah. Today's episode is sponsored by DeepSource. DeepSource helps you find and fix issues during code reviews using static analysis. If you're not totally clear on what static analysis is, then this is definitely one great way to learn about static analysis. This integrates natively with your pull request code review workflow on all supported providers. For example, GitHub, GitLab, or Bitbucket. No more digging through linter logs from CI builds. It's usually where people are running their static analysis for the continuous integration. But now you can do it directly on your pull request workflow. Each issue has a detailed description and a detailed description. So if you're not familiar with what you're doing, you can use the description of what the issue is and how to fix it. And DeepSource helps you auto-fix some of the most commonly occurring issues. DeepSource can also run code form matters like black, prettier, et cetera, on autopilot. So you don't have to worry about those extra unnecessary commits. Less than 5% false positives happen with DeepSource. And if you find one, you can let DeepSource know right from the dashboard. And in just a few days, the in-house team will fix that problem so that it doesn't happen again. And if you find one, you can let DeepSource know right from the dashboard. And in just a few days, the in-house team will fix that problem so that it doesn't happen again. And if you find one, you can let DeepSource know right from the dashboard. And you can have configurable issue categories. If your team doesn't really care about style issues, for example, you can disable them directly from the dashboard. And DeepSource is free to use for open source repositories and small teams. I found this is one of the best ways to learn how a tool works like this. If you have an open source project, you can integrate it there first. You can get started with static analysis on your pull request review structure today by going to deepsource.io slash devt. That's deepsource.io slash d-e-v-t-e-a. Thanks again to DeepSource for sponsoring today's episode of Developer Tea. Well, I want to ask you kind of a different question in a different field here, because we've kind of touched in this direction, but I think you have more to say about this. The idea that our careers are not just about, you know, our employers or who we work for, but perhaps we can kind of generate our own value or our own business, even in the world as an engineer. For someone who's skeptical about this, they say, oh, I don't really want to be a founder, or I'm not really interested in, you know, dealing with all those same problems. What is it about being as an engineer that makes you kind of equipped in some way to be a founder or an entrepreneur? Yeah. So I've been running my own business for four years now, a podcast plus online courses that I'm making and working with a bunch of folks around that. It's really interesting, like why I see this in the software space. Why are there so many founders or people who have these ideas? And I think everyone has these ideas. I have friends who are like, oh, I got this really cool idea. There's this problem that needs solved. And I wish somebody would solve it. You know what I mean? Whereas software developers, we're kind of like wizards or magicians, right? Like we have thoughts, we peck on the keyboard a little bit and they pop into existence. And that's unlike a lot of, a lot of things, right? Even if I was an architect, if I had an amazing idea, I still need building materials and all that expense. Like we literally can create these things from nothing in a sense. So I think that that means we can act on a lot of these ideas, right? It's a lot of, a lot of stuff. You're like, I really wish this would exist. Well, if you're inspired enough and you're willing to spend, you know, two hours a night for six months, that thing could exist and maybe it will go somewhere. So I, I think there's just so many possibilities for, for people to go create things and give them a try. I mean, the cost of putting stuff out on the internet and see if it works or an app in the app store or whatever is, it's nothing these days. And so there's just this huge opportunity to do so. The, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, real challenge and what I, people who want to go down that path, what I would say is it's easy to fall into the field of dreams viewpoint of the world, which is if you build it, they will come. If I build something good enough and it's better than that thing that's popular, that's, that's not how it works, right? Like there's a really tricky part of getting the word out of marketing of that whole side. That is a challenging side that you, people have to be prepared to work on and address. And it's hard to give just general answers for that, but that's a skill you got to cultivate. But if, if you've got an idea you really care about, you know, maybe it's worth it, right? I mean, we're use your magical powers to create that thing you always wanted and see what you can do with it. Yeah, this is honestly, this is why I started being, I started being, this is why I got interested in software engineering to begin with, is this idea that, you know, I'm going to build something that's going to be like, hey, this is free materials. Essentially, as long as I have a computer, I've got like all of the building materials I could ever want essentially given to me for free. So I could build something locally for free. And then it's incredibly cheap even then to get like the first thing up, you know, into the public. And I remember wanting to do something like this, wanting to get a message at least out there when I was in like fifth grade, right? This idea of like, oh, I'm going to build something that's going to be like free. And then I was like, oh, I'm going to build something that's going to be like free. And then I was like, oh, I'm going to build something that's going to be like free. It's unbelievable to me. And I think that only that, that interest only grew. And I think this is something that a lot of software engineers don't connect to the entrepreneurial spirit or whatever you want to call that, that drive to make something is, is different for engineers because we immediately have the capability of saying, what is step one? Where most people say, I have an idea. That's all I've got. I need to go hire somebody, right? Like that's, that's the next step. I got to go get money to hire somebody to do this thing. The next step for me is like, do I have a free hour tonight? You know, like, can I, do I have, can I put together a prototype and see if this is going to work? Exactly. And like the biggest detractor for me is like, well, I just don't know which CSS framework I'm going to use. So I'm not going to do that. Exactly. That's, that's the, the rope. You know, it is definitely an interesting prospect. Yeah. And bringing this back to my people coming in with like the superpower of programming, I think that that even makes it more possible because, you know, it's great to do like the next, the next Uber of this or the Airbnb of that, but where the true opportunity lies is, is in these sort of dark matter, shadowy places that you don't, you don't necessarily know about. Right. So if I was working in like heavy equipment supply, there's gotta be some really bad arcane sections of like that world that if you could just solve that, you would, you know, unlock that for that, that industry. Right. And you would be one of the few software developers to see that space and be, have the expertise and the connections to actually build that and solve it. So I feel these like, these like non-glamorous startup things that would actually be really awesome because no one else is going to know to even try that. Yeah. Well, and this goes back to the very first point we were talking about on, on the show, which is the idea that everything has to be polished and you have to be, you know, a 10 year veteran in order to do a startup, right. Or to have an idea that that's valid. It's like, well, I'm sure somebody else has taken that. So I'm not even going to try or the market is already optimized to some degree. And, and there's no, there's no new entrance in, into this. And I think that's, that's completely false. And I think you make the point perfectly well, that there's still ideas. There's still ideas and people who have these, just like the reason you started your podcast, right. And you had an idea and you're like kind of blown away that somebody hadn't already done it. Right. And so it's time to fill the void. Exactly. And those are the easiest to get the word out about, because there's people are probably wanting that and there's no one doing it. So you don't have to talk about why you're better. You just got to talk about that. You exist. It's like built-in SEO, right? Oh, I'm the only one. So you better, you got to click on me or nobody else. Yeah, exactly. So I feel like there's just tons of opportunities and all these little niche special is specialized industries that I don't know about that probably you don't know about, but whoever's in it, it's like, yeah, this could be way better and in an easy, short route to that. Yeah. Yeah. Michael, this has been an excellent discussion and I feel like we could go for, a much longer interview and I hope that we do again sometime in the future, but thank you so much for joining me for this one. No, it's been a great conversation. I really enjoyed being on your show and happy to have another one sometime. Thanks. Awesome. Thanks. Yep. Bye. Another huge thank you to Michael Kennedy for joining me on today's episode and on the last episode of Developer Tea for this excellent interview. I encourage you to go and subscribe to Michael's show. Talk Python to me. And in addition, you can find some training resources, some Python training resources, including a course called Python for Absolute Beginners, or you can go all the way to something like Python or Talk Python. That's async techniques and examples, all on manning.com. Thank you so much for listening to today's episode. Thank you again to today's sponsor, DeepSource. Head over to deepsource.io slash dev tea to get started today with static analysis on your phone. Thanks so much for listening to today's episode. If you enjoyed this episode and you don't want to miss out on future episodes, subscribe on whatever podcasting app you're currently using, or of course, one of the best ways you can help us keep on going as a podcast. After five years, this continues to be one of the most important things is reviews of this show on the various podcasting platforms like iTunes. This helps other engineers like you continue to find and start listening to developer tea. This episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.