How will you feel when you're 20 years into the job? In today's episode we talk to the author of the "The Quick Python Book," and Chair Person of the Python Software Foundation, Naomi Ceder. In this Part 2 of our interview with Naomi, we talk about staying consistent for 20 years, and how to keep going when the going gets tough.
Â
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.Â
Â
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
Today we are joined again by Naomi Seder. I'm so thankful that Naomi has decided to come on the show and be so vulnerable and transparent and open with us about her story. And I hope that you are as inspired and challenged as I am as you listen to this episode. If you forgot or you missed out on the first part, or maybe you are just now coming to Developer Tea and you didn't listen to the first part yet, I encourage you to go back and listen to the first part of this interview with Naomi Seder. My name is Jonathan Cottrell. You're listening to Developer Tea and my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Let's get straight into the second part of my interview with Naomi Seder. I think people are inspired just by the fact that you've been able to stay so consistent in your career for 20 years. And I want to return to that for a moment. I have a totally different question for you. Do you think that Python is special? And if so, why? I guess I will say, yes, it is a little bit special. Okay. And I'm now talking about the language and, you know, I think it's pretty clear. I think that the community is special and we've talked about why, but the language is the language special. I will say that it is, I'm not sure as we talked about how significant that is in the scheme of things, because, you know, it may not be the hugest factor, but I will say that Python is a little bit special because of what is exemplified in the first line of the Zen of Python. And, you know, for anybody who's not familiar with the Zen of Python, it's a little bit special. It's the 19 coins or sayings or whatever that guide the design of Python. It's actually 20, but 19 of them are all that have been written down. It was originally done half as a joke and half seriously 20 years ago. And now if you go to a Python shell, you can import this and it will show you the Zen of Python. Well, the first line of the Zen of Python is beautiful is better than ugly. And I think that the language as it was created and as it evolved, maybe has just a tiny edge because of that core aesthetic sense, that acknowledgement and embracing of an aesthetic principle as the heart of a programming language. I'm not aware of any other programming language that has that core aesthetic sense. I don't know. I mean, Ruby, I don't know. I mean, from what I've heard, it was like maths was, you know, programmers should have fun. Okay. That's kind of a principle. But I don't know of another programming language that has taken this aesthetic sense. It doesn't even matter so much what is beautiful, but the fact that people are asking the question. That it is a value. Beautiful is better than ugly. And if you follow discussions on Python ideas and Python dev, this aesthetic thing is, you know, features prominently in a lot of discussions about the direction the language should take. So I will say that as the core, as a core value that is kind of behind the organization of Python, is maybe something that makes Python special. That has been my belief for a long time anyhow. That's my opinion. Yeah. I definitely do not disagree with that. I think what's so interesting about the discussion about aesthetics is subjective in a lot of ways. You might have consensus, but still that consensus is going to be subjective. But making it a concept is a lot of fun. I think that's the key. Making it an imperative means that the Python developer, and it's also contrasted against another part of the, the Zen also talks about having kind of the, a close to one right way of doing something. So that you have three Python developers who have similar experience. They're probably going to write very similar code to solve the same problem. At least that's the, the way that I take it. And that's kind of contrasted in some ways to the aesthetics. And I think it's a good contrast because it kind of deals with the idea that the problems and the way that you express the problems is just as much a part of the problem solving process. So if you express the problems in new ways, then you may have outcomes that are different. then you may have outcomes that are different, right? And this actually goes to a blog post that this idea goes back to a blog post that you wrote somewhat recently. And this is on your site, on your blog. It says, well, I guess it's not that reason. It was back in 2015. Notes on teaching Python, the mental models discussion. And I'd love to talk to you about this because I think it's really important for engineers, not only engineers, but certainly engineers, to consider the models that they have and that they're using on a regular basis. Maybe not explicitly every time, but I'd love to know, how do you develop your mental models or teach others new models and how do you develop your mental models? And what would you recommend for an engineer who's looking to expand on their existing models? Well, I love this question, actually. We're probably good for the rest of the afternoon. That post is five years old. I've since become more and more interested in the notion of mental, mental models. It's partly prompted by watching people teach at community events and things like that. And having been myself a teacher for a couple of decades. And there are many, many things that people will tell you that get accepted at face value and then get passed along in terms of teaching that are, in fact, not the way things really work. And so, you know, I'm, I'm, I'm really interested in trying to get people to develop mental models that correspond to the way things really work because that's, that's more useful. I mean, in the, in the post you mentioned it's on, on Python variables, which, um, there seems to be particularly amongst people new to coding and whatever they get told that variables are containers and, and in fact, variables are labels. They're not really containers. It doesn't work. There are all sorts of problems if you believe that. Um, so I guess I, and, and I'm also currently now with, with Manning, uh, publications working on a, um, we're calling it exploring Python. It's a little mini live project, a series of 10 sort of hour or two activities where people work through exploring some of these things with the, with the hope that they will then form a sounder Mendel model. So how, how do I go about that? Um, and, and how would I encourage people to do that? Um, I think the first thing is to be sure that people are aware that they actually are using a mental model. Um, when, when somebody tells you that, um, you know, two goes into the variable X, they are implicitly giving you a mental model there. They're saying it's a container and that's how it works. And, you know, I, uh, going along with that, people should be willing to examine those and, and more importantly to verify those. Uh, so when I'm looking at, at, at, at things there, I don't quite understand them. I, you can do a certain amount of research online. You can look for maybe a books or, or posts or whatever by, by people who are reliable. Uh, but it's, um, it's sort of in the nature, of the game that you, you can't necessarily trust everybody on what they say and take it just at face value. So for example, with, with things involving Python, I really, uh, like to get into, um, an interactive shell or, or these days I use a Jupiter notebook and then I start asking myself, okay, so if it works this way, what other things would I expect? To happen? Uh, what things should I be able to do and what things should I not be able to do? If that's true, what, you know, what sort of outputs do I get? And then I just sort of work through those possibilities. Can I do this thing? Oh, yes, I can. Can I do this? They whoops. Nope, I can't. There must be something else going on here. Uh, and, and that's the sort of thing that I like to encourage people to do. Um, back when we started quarantine, I did, um, a Twitch stream every Friday afternoon on the same topic of exploring these things and just sort of working through here. Here's what I would try. Okay. See what happens. Okay, well now let's look at what happens here. Uh, just as, as ways for people to get used to, um, exploring and constructing, uh, their own knowledge rather than simply, well, it says in book or blog post or heaven, forbid stack overflow response X, uh, you know, instead I actually sort of poked at it and this is what it really does. And that can guide you as you explore more and trying to figure out, um, what's, what is really going on. So I, I think that's, that's really important. It's, it, it goes back to my time in education. That's sort of a constructivist philosophy, you know, where you encourage students to experiment and break things and try to construct their own knowledge of the world. Same way that a baby would crawling around, touching things, putting things in its mouth, et cetera. Uh, so that that's kind of the philosophy behind it. And it's just my feeling that once you do that and end up with a reliable mental model, you're much less likely to have those nasty surprises in your code that you end up debugging, uh, at an awkward time on down the road. Yeah, that's so good. Uh, this, this is also a subject I'm kind of endlessly interested in because there's a lot of layers to it. Um, we operate entirely on models. There's never a time when we are viewing the world or viewing our code without a model. Now, the question is, can we put our finger on exactly what that model is, is, is constructed of? Um, sometimes it's a little bit more obvious than others. I think, and I think that it's, um, you know, it's not always very clear exactly why it would matter to know what that model is. But to your point, I think what's wonderful about it is you have a chance to experiment with it and say, where are the edges of this model or is the model valid? Is, am I operating with something that at least at its, you know, at its core level is going to give me the things that I'm trying to do. Right. Right. If, if you do not have a reasonably accurate mental model, then you end up sort of dealing with things in terms of magic. I'm afraid I have an example and I will, I will, I will not name this person at all, but I do know of a person who, um, was never really under educated and never really understood how electricity worked. I mean, I grew up as a kid, I was a batteries and lights and little switches and things like that. So, to me, the knowledge of how electrical current works is pretty intuitive. Cause I, I, I made all of those experiments, uh, when I, when I was, was growing up and, and working through things. But this person will believe that if you put on a lamp socket, um, you have a serious, if you change a lamp socket, let's say, uh, you have a serious, serious chance that the whole thing will explode. Uh, it's like, I'm sorry. There, there is no way that's going to really explode. Okay. You could trip a breaker. Sure. But you're not going to blow any, there's nothing to blow up. Uh, you know, and this seems almost silly, except I wonder really how many people, uh, who aren't a little bit of a geeky bent do understand how electric electricity works. We, we say it's a current. That means if I unplug something and have a bare wire, is it dumping current out onto the floor? I don't know. You know, I, so. Is that a material of some kind? I don't know. Right. Right. Right. So, so there are a lot of those things that actually, if you, it's interesting to, when I, I went to grad school at the, uh, university of Wisconsin, uh, which at the time, I think it is since sadly been dismantled, but at the time had a very strong history of science program. And this whole struggle with mental models is in fact, the story of the history of science as well. And it is fascinating on many, many different layers. Yeah. I can't, I can't help, but, uh, just get excited when I talk about it because what's, what's so fun about this, I'll say fun. It's, it's okay to have fun with this, right? Um, what's so fun about it is, is everybody's experience gives them different models as well. And so your experience, for example, in this case, you have this model of how electricity works and it probably comes in handy. Even when you're not talking about electricity, necessarily, right? You can kind of create metaphors, uh, based on that model and use that same thinking in other places. And I think that's true, um, for other things as well. In fact, I know it's true for other things. I, I've done it for myself. I have a background in music. I have, um, my, my father was a pilot. I have my private, private pilot's license. So I use some of that information when I'm thinking about things that have nothing to do with music or with flying. And I think, you know, being able to recognize, um, when those models are useful, right. Right. And then also when they're inaccurate, every model, of course, will not be complete. If it weren't complete, it would be the system. It wouldn't be. Yes, exactly. Uh, there's a, what is it? The territory, uh, the map is not the territory. Right, right, right. That's the idea. So, so I think that's why I say, I think actually being aware, that that's what you're doing and that, that may have limitations, but you want to have the best model that you can. I think that's, that's the important thing as opposed to, um, as I say, not, not, not examining that at all. And just sort of not, not knowing what, what models you're using. I think you get very close to then just sort of using magic. Yeah. I think, I think the flip side, if you don't know that you're using models, then you kind of implicitly believe that you have, um, maybe a full picture of reality, which is, is a dangerous, uh, place to be in some ways. Um, because then you start applying that reality to, uh, not only every situation that you encounter, but also to other people. And that's where it really starts to, you know, if you can't recognize that someone else has a different model of the world than you do, well, you're going to impose your model on them. Uh, maybe not maliciously, maliciously even, but you expect them to kind of see the world through the same, uh, the same model, the same filter, the same, you know, biases that you have, that you've adopted over your life. And unknowingly you're expecting something that's unrealistic, right? Well, this has been an excellent conversation about mental models. I think we can probably talk about that for a long time. Um, I'd love to ask you a couple of questions that I like to ask all the guests who come on the show. Um, the first question is what do you wish more people would ask you about? I think you've done it. I think mental models would be a definite, a definite, a definite thing that I would, I would love to talk about more with people. Okay, that's great. So if anybody runs into, uh, we, we, we can always sit down and, and have the beverage of our choice. Well, once we get out of the quarantine situation or, you know, uh, the current crisis, we can sit down with our favorite beverage and, and talk about it for hours. Absolutely. Yeah, that's wonderful. And the second question that I'd like to ask you is if you only had 30 seconds to sit down with developers of all backgrounds, all experience levels, what kind of advice do you give them? That, that is, is a tough one. I think for only 30 seconds, then I think I would say that, um, the thing that you need to worry about more than the technical skills are the human skills. That's what will make or break your development effort. And that's only 10 seconds. There you go. I guess I got 20 minutes or 20 seconds to talk about something else, but I think that is the most important thing. I know that as I've hired, um, as I've hired people for my teams over the years and sort of worked through that, of course, there's a level of basic knowledge maybe that you're interested in. That is, they should have some familiarity with the basic tools, no a language, whatever, but I don't worry too much about specific technical skills very much, uh, because those can actually be, uh, can those can usually be acquired. Um, but, but I'm more concerned with, um, a couple of things mainly, um, is the person going, you know, the sort of person that will get along well with people. And I guess the other thing I'm interested in too, is does that person bring something different in terms of perspective and background to the team? Um, so that, that may be kind of poaching this whole line of discussion off in a different direction, but that's, that's kind of the way that I approach diversity is, you know, you're trying to build a team and a better team, and a team will have different perspectives on it. So why not think about that when you're actually even talking about people, talking to people about, you know, joining your team? There's, there's two, uh, I guess, base level arguments that, that can be made in a valid way for, for doing that, right? One is something we've already talked about, which is those backgrounds. They bring different models, right? So at a very tactical level, um, they, they bring different models, and this is for people who are, uh, trying to, you know, I guess in a dollars and cents way, try to justify why you need people of diverse backgrounds. But at a second, uh, on a second layer, um, this is an ethical question. And I think there are people who try to make one of those arguments override the other. And I don't think you can do that because those, the ethical discussion, or, uh, even at a moral level, but certainly at an ethical level is entwined with the, with the models discussion. Mm-hmm. We want to become better together. And the only way we can do that is if we seek a more truthful perspective. And when we only have one type of model, we're not gonna be able to get there. Right. I think that's so critical to understand. Yeah. Naomi, thank you so much for your time and for all of your investment in the Python community for your investment today here with me. Oh, my pleasure. Is there anything that you want to direct people towards on today's show, whether that's a book you're writing, maybe find you online or something entirely different. Um, I, well, let's see, what, what can I put in a plug for, We're not yet in a position where we have anything published yet, but from Manning Publications, there will be coming a Exploring Python series of little projects. They should be pretty affordable. There'll be some video and then some activities for people to do and then come back and sort of sort out the things that they did. So that will be coming along, of course. And I've got to plug the book. So again, Quick Python Book, third edition. It's gotten very kind reviews in various places. So that's good. I will be, for people who are interested in Python and community and various things like that, I will be one of the keynotes at PyCon India, which is available online for everybody in the world, which will be the beginning of October. So I don't have a link handy for that, but if you search for PyCon India, I'm sure you would get there. And I've got various other talks in English and Spanish coming up. That would be kind of a boring list, but they're there. I can be found at NaomiCedar.Tech. So there's that and Naomi Cedar on Twitter. So I guess that kind of covers that part of it. So, yeah, it's... Yeah. Yeah. Yeah. Yeah. You know, just the same old stuff, I guess. Excellent. Thank you so much, Naomi. I appreciate your time today. Again, my pleasure. Thanks for having me. A huge thank you again to Naomi for joining me on today's episode of Developer Tea. Of course, you can go and find Naomi and everything related to the Quick Python Book. You can find that all in the show notes, which can always be found at spec.fm. If you don't want to miss out on future episodes like this one, where we interview people like Naomi and on other episodes where it's just me here talking with you, then please go and subscribe in whatever podcasting app you're currently using. This episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.