Today we are joined again by Naomi Ceder. I'm so thankful that Naomi has decided to come on this 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 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 Ceder. My name is Jonathan Cutrell. You're listening to Developer Tea. 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 Ceder. I think people are inspired just by the fact that you've been able to stay so consistent in your career for 20 years. I want to return to that for a moment and 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. I think it's pretty clear 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 it may not be the hugeest factor. But I will say that Python is a little bit special because it is of what is exemplified in the first line of the zen of Python. And for anybody who's not familiar with the zen of Python, 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 while 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 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 explicitly gone for that. I mean, you know, Ruby, I don't know, I mean, you know, from what I've heard, it was like, maths was, you know, programmers should have fun. Okay, that's that's kind of a principle. But I don't know of another programming language that has taken this aesthetic sense in it. 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 is you know, features prominently and a lot of discussions about the directional 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 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 an imperative means that the Python developer and it's also contrasted against another part of the, this then 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 this 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, 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, 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 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. So that that post is five five years old. I've since become more and more interested in the notion of 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, and 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 there seems to be particularly amongst people new to coding and whatever they get told that variables are containers 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. So, I guess, and I'm also currently now with with Manning publications working on a 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 sound or mental model. So, how do I go about that? And how would I encourage people to do that? I think the first thing is to be sure that people are aware that they actually are using a mental model when when somebody tells you that, 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 going along with that, people should be willing to examine those and more importantly, to verify those. So, when I'm looking at at at things that I don't quite understand them, you can do a certain amount of research online. You can look for maybe books or posts or whatever by by people who are reliable. But 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 like to get into an interactive shell or these days, I use a Jupyter notebook. And then I start asking myself, okay, so if it works this way, what other things would I expect to happen? What things should I be able to do and what things should I not be able to do if that's true? What sort of outputs do I get? And then I just sort of work through those possibilities. Can I do this thing? Yes, I can. Can I do this thing? Whoops, nope, I can't. There must be something else going on here. And that's the sort of thing that I like to encourage people to do. Back when we started quarantine, I did a Twitch stream every Friday afternoon on the same topic of exploring these things and just sort working through. Here, here's what I would try. Okay, see what happens. Okay, well now let's look at what happens here. Just as ways for people to get used to exploring and constructing their own knowledge rather than simply, well, it says in book or blog post or heaven forbid stack overflow response acts. 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 what is really going on. So I think that's really important. 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, etc. 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 at an awkward time on down the road. Yeah, that's so good. This is also a subject I'm kind of endlessly interested in because there's a lot of layers to it. We operate entirely on models. There's never 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 constructed of? Sometimes it's a little bit more obvious than others. And I think that 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? Am I operating with something that at least at its core level is going to give me the things that I'm trying to get out of it? 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 not name this person at all. But I do know of a person who was never really educated and never really understood how electricity worked. 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 because I made all of those experiments when I was growing up and working through things. But this person will believe that if you put on a lamp socket, if you change a lamp socket, let's say, you have a serious, serious chance that the whole thing will explode. It's like, I'm sorry, there's no way that's going to really explode. A trip a breaker, sure, but you're not going to blow any, there's nothing to blow up. And this seems almost silly, except I wonder really how many people who aren't a little bit of a geeky bent do understand how electricity works. We say it's a current. That means if I unplug something and have a bear wire, is it dumping current out under the floor? I don't know. So there are a lot of those things. Actually, if you, it's interesting too, when I went to grad school at the university, Wisconsin, which at the time, I think it has 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 help but just get excited when I talk about it because what's so fun about this, I'll say fun, it's okay to have fun with this, right? What's so fun about it 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 based on that model and use that same thinking in other places. And I think that's true for other things as well. In fact, I know it's true for other things. I've done it for myself. I have a background in music. My father was a pilot. I have my 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 being able to recognize when those models are useful, right? And then also when they're inaccurate. Every model, of course, will not be complete. If it would be the model, then it wouldn't be the, yeah, it's exactly. What is it? The territory, the map is not the territory. Right, right, that's the idea. So I think that's why I say I think actually being aware that that's what you're doing and that may have limitations, but you want to have the best model that you can. I think that's the important thing as opposed to, as I say, not examining that at all and just sort of 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 maybe a full picture of reality, which is a dangerous place to be, right? In some ways, because then you start applying that reality to 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, maybe not maliciously even, but you expect them to kind of see the world through 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. I'd love to ask you a couple of questions that I like to ask all of the guests who come on the show. 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, definite, definite thing that I would love to talk about more with people. Okay, that's great. So if anybody runs into, we can always sit down and have the beverage of our choice. Well, once we get out of the quarantine situation, the current crisis we can sit down with our favorite beverage 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 is a tough one. I think for only 30 seconds, then I think I would say that 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 to talk about something else, but I think that is the most important thing. I know that as I've hired, 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, because those can actually be, those can usually be acquired, but I'm more concerned with a couple of things. Mainly, this 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? So that may be kind of poaching this whole line of discussion off in a different direction, but that's kind of the way that I approach diversity is, you know, you're trying to build a team and a better 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 two, I guess, base level arguments that can be made in a valid way 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, they bring different models. And this is for people who are 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, on a second layer, 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 even at a moral level, but certainly at an ethical level is entwined with the, with the models discussion. 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 going to be able to get there. Right. And I think that's so critical to understand. And we 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? I, well, let's see, what can I put in a plug for? As I say, we're not yet in a position where we have anything published yet. But for 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, and, and sort of sort out the, the things that, that they did. So that, that will be, that will be coming along. Of course, I've got to plug the book. So again, quick Python book, third edition, it's gotten very kind reviews in, 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 key notes 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, in English and Spanish coming up that would be kind of a boring list, but they're there. I can be found at NaomiCeder.Tex. So there's that and Naomi Ceder on Twitter. So I guess that, that kind of covers that part of it. So yeah, it's, you know, just the same old stuff, I guess. Excellent. Thank you so much, Naomi. I appreciate your time today. Oh, 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 and whatever podcasting up you're currently using. This episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.