The Python Podcast.__init__

Share on social media:

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try out a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode. With the launch of their managed Kubernetes   next generation of deployment and scaling, powered by the battle tested Linode platform, including simple pricing, node   balancers,   40 gigabit networking, dedicated CPU and GPU instances, and worldwide data centers. Go to python podcast.com/linode   today. That's l   inode,   and get a $60 credit to try out our Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show. You listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis. For more opportunities to stay up to date, gain new skills, and learn from your peers, there are a growing number of virtual events that you can attend from the comfort and safety of your own home. Go to python podcast.com/conferences   to check out the upcoming events being offered by our partners and get registered today. Your host as usual is Tobias Macy. And today, I'm interviewing Stephen f Laud about finding a project that you care about to aid in learning to program. So, Stephen, can you start by introducing yourself?  



[00:01:27] Unknown:

Hi. Stephen Lott here. I'm a Python developer. I've been doing this for many years since the previous century, really.   I'm an author of a bunch of books through Pact Publishing.  

[00:01:39] Unknown:

And do you remember how you first got introduced to Python?  

[00:01:42] Unknown:

It is an odd thing because it it happened a long,   long   time ago. I was a Java programmer   back in the day when Java first came out, like I say, the previous century.   And 1 of the questions that had come up was, is there a good alternative to Java? And I was a   traveling   consultant. I did technology   consulting, and, you know, the question is always, what's the next big thing?   Capital letters, n b t,   and what would overtake Java. And   Python,   back years ago, interested me a great deal because it looked like it would   possibly be   a thing that was an alternative to Java.  

And back in the day, your choices were Java and C plus plus and, you know, a language is like Eiffel, which never went very far and Modula 3, which actually is a little bit of Python.   But, you know, getting those to run on your home computer in 1977   was just a nightmare. These were not really viable things.   Python,   quick download, up and running, did everything I wanted.   Wow, it was wonderful.   And then moving into   the new millennium, the 1 we're in now, I used Python more and more   for small consulting projects. And like I said, I was a traveling consultant, so there were a lot of small projects.   And every time I wound up wrestling   with somebody's poorly structured data,   I use Python.  

1 of the biggest ones that I wrestled with   was a legacy   COBOL application,   thousands and thousands of lines of COBOL code   that had to be looked at to figure out how you could best rewrite it. That was the worst structured data   ever because it was source code in another language.   And then, you know, after those sorts of things, I wound up using Python more and more for development and things like that.  

[00:03:51] Unknown:

You also mentioned that you have authored a number of different books. I'm wondering what got you into that role   of writing books and being an author and going through that whole process?  

[00:04:02] Unknown:

The book writing business is a strange thing because I sort of fell into it. I don't even know sort of   whether you could call it like a sideways   stumble into the business.   The problem I had was that I was working on doing some development of a fairly complicated   restful API in Python.   It involved actuarial   work and actuaries and, you know, fair amount of thinking, and the test cases were very, very complicated.   So the unit test suite ran for, like, 5 minutes, and it was boring. So I started playing with Stack Overflow   and this is in the early days of Stack Overflow. This is the 1st year Stack Overflow   was available to the public.  

So I started answering Python questions there because I had time to kill, you know, 5 minutes while tests were running several times a day.   And as a consequence, I built up a fair number of points in Stack Overflow, so kind of surprising number at this point in my career.   And a packed acquisition editor   asked me, you know, do you have anything more to contribute than just sort of random answers on stack overflow?   And the answer was I did,   but it was not like I sought out to become a published author. I kind of stumbled into   it inadvertently,   but because I was a traveling consultant to the whole idea of, oh, wait, I've got a book and I'm an author and I can then travel around and   shop around   Python   ideas   to enterprise consumers   was very, very appealing. And so I definitely pursued that as quickly as I could because it sounded like it was a lot of fun and a really good career move.  



[00:05:45] Unknown:

Yeah. It's definitely useful to be able to have some published body of knowledge that you can point to as signaling your expertise in a particular area because it's   easier to demonstrate that through publication,   particularly to people higher up in organization as opposed to pointing at all of your open source contributions or the projects that you maintain because they're not going to care as much about that, and they're not going to be in a position to be able to evaluate   that for its overall effectiveness or usefulness.  

[00:06:16] Unknown:

Exactly. Until your open source   contributions   are, you know, a GitHub   project with 1,000 of stars,   there isn't a lot of vetting,   at least not the way there is in the publishing business. So the books all have technical reviewers,   then the technical reviewers have looked at every single line of code, every example, and complained about everything they can possibly complain about.   And most of the technical reviewers when you look inside the packed publications are are pretty heavy duty experts in their own right. And so getting past those arguments   really polishes up the text a lot. But with an open source contribution,   did everybody really read all that code?  

Not necessarily.   For big projects,   yes. And for very popular projects, yes. But for small projects,   maybe, maybe not.  

[00:07:08] Unknown:

In addition to your work as an author and as a traveling consultant,   you also do some training, I understand, and you've created some of your own projects. So I'm wondering if you can just give a bit more of an outline of your overall experience   both working with and teaching Python.  

[00:07:25] Unknown:

I'm actually not a traveling consultant anymore. I was when I started writing, but I left that as I've done a sailboat for a couple of years. And then I now work for Capital 1   entirely in house. And so the training is very much focused on my colleagues   at Capital 1,   Many of whom are data scientists,   some of whom are DevOps and other more technical people.   And so the training is very focused on needs we have at Capital 1 for specific kinds of Python skills.   And in a lot of cases,   there's a a sort of a gap here because I'm not a real data scientist and I'm sometimes not even qualified to talk about the difference between a mean and a median because I'll get those things confused in a room full of real data scientists.   So my focus is on the technical side of programming and algorithms and data structures and Python and those kinds of things, the things I really know well.  

And we have to work collaboratively with the data scientists so that I don't completely mess things up and have them all storm out of the room in a huff because I said something extremely dumb about data science.   Usually, they're polite about it, but occasionally, there'll be a break and they'll say, you know, you really shouldn't   you really shouldn't confuse,   you know, some of these topics that you're not clear on. So that's always been very, very helpful, wonderful advice.   But finding examples   where I can meet my data science   colleagues halfway is occasionally challenging.  

But because I lived on a sailboat, I did a fair number of things that involved   data gathering and data analysis and data reduction.   It was just on a very small personal   scale,   not the scope of the things the data science community does, but tiny things.   And so some of my tiny examples   are not   completely wretched   and they like them. And so that works out really, really well. 1 of the ones that was a lot of fun for me and has been fun for my colleagues   is when I rewired the alternator on the diesel engine.   And what happens is the little pulses that show RPMs   are now at a slightly different rate from the new alternator   than they were from the old alternator.  

So I had to do a little data science thing to model the differences in the pulses.   And it's embarrassing because I only have, like, 6 data points in the dataset, but it does fit a line very elegantly.   And we can use that tiny little dataset to explore   functional   programming topics in Python   where we can focus on the programming   side of it because the data is small,   relatively   neat,   doesn't involve   account numbers or any of the other kinds of protected data that we have at banks. And so it's a fun project for them to deal with also. Although at the time when I was working on it, it was brain scramblingly complicated because   I'm not a data scientist.  

But the functional programming aspect of it worked out beautifully well, and it serves as kind of a nice little example of how to apply Python functional techniques to a small set of data.  

[00:10:53] Unknown:

And that brings us nicely to   our overall topic of   how to find   useful projects and useful motivations   for people who are new to programming or who are acquiring new skills   to help them stay focused and stay dedicated to actually acquiring the information that they're setting out for while also being able to produce something useful to themselves.   So I'm wondering how your overall day to day experience as somebody who is training   other engineers in your work context   helps you to identify   useful ways that newcomers can learn about Python or acquire other technical skills?  

[00:11:33] Unknown:

It is a delightfully difficult problem because people have a variety of passions, different things interest them. The things that are important in the workplace   sometimes aren't terribly motivating.   And so, yes, it's an important project and yes, the company will save money or make money or something, but really frankly, it's can be kind of boring.   And so some of those things can be frustrating for people who are expected to pick up a new skill, and some of it can be frustrating for managers who would like their people to pick up new skills. So it's fun to step outside   the work environment.  

The tricky part about finding a passion project,   1 tricky part is   that some things are just   hard to automate.   It's not so much that the software might be   particularly difficult to write. Maybe the software is not that bad, but the whole concept of automating   something   can be   really difficult.   So because I lived on a boat, 1 of my passions is to limit   agricultural   runoff of pesticides and fertilizers.   You know, that's not really a very automatable thing. What am I gonna do? Go give farmers better software? No. They have pretty good software for managing these things.   What they don't necessarily   have is perhaps the right regulatory   environment   for limiting   where and when they can use pesticides.  

And is that an automation thing?   Maybe it's not. Maybe it's just I need to call a lot more senators and representatives.   So   the passion that you have   may not always fit something that can be automated in the first place.   So that's 1 of the limitations is to   get the sort of language of automation   and the approach to automating things   so that you can have a respectable   doable project.   And the second part, which is no less important   is sometimes   it's just difficult to build good automated solutions.   Software is, well frankly, hard and robust,   scalable, reliable software is   really hard. And so you may have some clever automated small app that runs on your desk top and may help the project that you're passionate about,   but can you turn this into something that will scale and can be run-in the cloud and can be deployed automatically? Oh, gosh.  

There's a whole lot of other considerations   there   outside the language,   outside the value created by your project that can make it just daunting.   And so   you have a, am I doing the right thing,   and am I doing the thing the right way? And there's both of those can be difficult   to discover whether or not you've got the right thing, whether or not you're doing it the right way.   And so when someone is learning technology   for the first time, you know, you're trying to learn the Python language,   oh, gosh,   you kinda have to set both of those things aside and you wind up having to build something that maybe   isn't a great solution, doesn't solve the problem you're passionate about, but it becomes close   and that's important. That way you have something you're interested in.  

Maybe it's not   the best ever solution, but it's better than nothing,   and you learned the Python,   and you learned more about automation, what can be automated, what can't be automated.   And so the final bit of this is   giving yourself   permission   to fail.   It may not work. Things didn't work out right. That's okay. You started again. The second 1 was better than the first 1, and that I believe is where the real secret is, is giving yourself   permission to fail, to try something, to see if it worked. And if it didn't work, try something different. That, I think, is really important.  

[00:15:48] Unknown:

And there are a couple of things that I wanna dig into there. 1 being that   in terms of being able to select a project that you care about and that is motivating for you to go through the pain of learning this new skill,   there's the difference of, as you said, what is possible versus what is practical versus what is not even achievable because of limitations of our current technology.   But then there's also the   learning to fail and fail effectively piece where   there's failure in terms of the overall project, but then there are also the intermediate   failures that happen as you're learning something where you have a syntax error and the project crashes, or   there's a difference in the way that you implemented a particular   function call versus what it's expecting   and being able to parse through those stack traces to understand what went wrong, how to fix it. What are your thoughts on some of the ways that the language itself   and various   ecosystem components such as libraries or   tool chains or editor environments can assist in helping people to overcome those intermediate failures   so that they can keep progressing rather than getting   discouraged and giving up because they feel like they're not able to make forward progress.  



[00:17:06] Unknown:

Fighting the sense of discouragement   from new technology   is potentially quite difficult, and it is sort of daunting.   It's sometimes difficult to figure out how to build up the right level of patience with all of this   because it is, you know, especially when it's new, it is difficult.   What I suspect sometimes   is that folks who seem to struggle a lot, I believe seem to struggle   partly because   I hate to beat this point too heavily, but   I think there are people who don't really feel comfortable   giving themselves   permission to fail.  

They'll try something,   it didn't work and they're not sure what to do next,   and perhaps they need to back off some of their assumptions,   back off some of the things that they realize they didn't know and they guessed at,   but   if you sort of   struggled to type in the code in the first place and it took you hours and hours to write a few lines of code,   you hate to throw them away.   And so you wind up feeling frustrated because it took me all day to write this and it doesn't work. And I legitimately   feel the pain of this, that all of this effort and it's still not right.   But I think there is a deeper level of permission to fail   that is part of being   a   patient technology   explorer   in that you know or you need to be comfortable with   you're not going to get there and you're not going to get there right away and you're gonna spend hours writing that first line of code and it's not gonna work. So you're gonna have to spend another few hours researching that line of code and then understanding   something that you previously didn't understand,   which is   a kind of a failure.  

Learning   involves   unlearning   the mistakes   and unlearning the invalid assumptions, which is again a permission to fail, that there are mistakes that will be made   and you'll make them. And you have to be sort of   somehow   optimistic about making a mistake.   And I don't know where that optimism would come from really, but I kind of feel that that's the thing that is hard to find sometimes is   how do I press on in spite of this   pretty obscure   thing?   Tooling around this. And you had mentioned, is there a way in the ecosystem of tools to address this?   Tooling is a sensitive issue because   you can imagine   having some really slick integrated development environment   that's looking over your shoulder and trying to coach you on what those error messages   really mean.  

And this is a   potentially dangerous area because   somehow or other this looking over your shoulder software tool   is trying to register your intent.   And that can be really tricky because it may not be clear from the code what you were intending to do in the 1st place.   And so the tool in trying to square you away   may wind up misleading you because it made the wrong guess about your intent.   So I worry a little bit about   over tooling in this area. But then on the other hand, under tooling means people look at cryptic error messages and say, gosh, I can't do computer today.   And I don't know where the middle ground would be. Is it possible to have some super clever assistant,   or would you need   some natural language thing   where you talked through the problem   and the solution with some chatbot   before you started coding so that the chatbot had some   context   and some sense of what you think the terminology   means, and maybe that would be helpful. But, gosh, doing sentiment analysis   on some of these technical topics   fraught with difficulty.  

Since I get median and mean confused,   even having me   start a statistical project is gonna be trouble because you know where it's gonna go. Nowhere good.   And so I would need to talk to a real data scientist before I got started down something that involves statistics.   So tooling in that area,   maybe not so helpful.   You maybe need   a tutor or somebody that you can oh, wait. That's what Stack Overflow is.   You ping your question, somebody tutors you.  

[00:21:44] Unknown:

And that goes nicely too into the idea of encouraging people to select a project that they're interested in, that they want to be able to work through,   but then figuring out how you actually   explain to them that wonderful website or that super cool robot that they wanna build   isn't really practical. It's actually going to require a decade and a whole team of engineers to be able to actually get anywhere near success.   Why don't you set your sights a little lower?   And so just being able to help   illustrate   what types of projects are actually   reasonable and within scope and achievable   in a short amount of time for them to be able to actually acquire the skills.  

But then also, if they are looking to take on a somewhat larger project,   understanding   what are the   components that the overall project can be decomposed into, and what are the dividing lines, and how are you going to   go   from 0 to   complete, and what are the steps along the way?  

[00:22:48] Unknown:

Oh, yeah. That is, I believe,   sort of the gold standard   in the long run for how you understand   the technology.   It is being able to discuss it at a reasonably high level   with a certain amount of clarity as to what the objectives are, what the information   sources are,   what the information   target is, what the transformations   are. This is all   not obvious   that it has to fit together this way. There's a lot of things where it's not clear that it's an information based   operation   in the first place.   You know, your robot example,   I want a clever robot to do a better vacuuming pattern in my apartment.  

That's actually an information thing. What is the source of data for the robot?   And it's an algorithm thing. None of this is clear at first. It takes   sometimes, I think, years of experience to figure out what the sort of road map through the intellectual   space is. How do we talk about this and what are we talking about? I think that can be difficult for a person to sort of come to grips with. And 1 of the most important   things that I think is   not obvious at first   is a great many pieces of automation are really supporting   a person   making a decision.  

It's not doing the thing. It's helping a person decide   if the thing was done correctly   or should the thing be done at all?   So   when you look at like ride sharing, like Lyft or something like that,   a car pulls up. Do I get in? Do I not get in? These are questions   that have to be addressed by providing a great deal of information   to both parties in the transaction   so that they're comfortable   making a decision   and then taking action.   And so the fact that it's really information that helps a person decide what to do,   it's sometimes hard to even   frame the problem that way so that you can then figure out what information they need, what transformations have to be performed, and how do I get it in a form that people can use it.  



[00:25:07] Unknown:

There's also the question of   what the different levels of detail and guidance are that are needed for people as they progress along different stages of acquiring   experience   and understanding of these problem spaces where   if you have somebody who is completely new to programming technology,   how do you keep them interested past the point of this is a function, this is a variable, this is how data flows through the program   because all they care about is being able to make a shiny new website to be able to impress all their friends or build a video game that they can play. And they don't wanna know what the core building blocks are, but they have to be able to understand that. And then once they've gained enough experience to be able to say, okay, I've built, you know, this Pac Man clone,   and now I wanna be able to go on to building some shiny   3 d, you know, platformer game,   acquiring that next level of capability.  

What are the differences in terms of how we need to provide guidance and   provide motivation through those changes, or is there a difference between the different stages in terms of how you keep people interested?  

[00:26:17] Unknown:

The question of is there a difference, that really hits   at it because I think a lot of these things are more of the same   kind of things that it's that very   first step that's the hardest.   Once the very first sort of glimmer of understanding of how this all works together   is achieved,   the rest of it, it may not flow at the pace you want, but it kinda flows.   It's that first glimmer of   what is the data in this problem,   what is the processing in this problem,   and who is the consumer of the data.   These are hard, hard things to reason about sometimes.   And once you're sort of over the hump there as far as what is the data, who needs it, and what action are they gonna take   based on that data,   then   after that, it begins to become more   clear how automation works and where automation fits into our life. The first few steps there of   what is information and how do people use the information to make decisions,   some of that is hard to get a grip on because so many things are   so delightfully automatic   and have been well thought out.  

You glance at your stove and you see the time.   Somebody thought that all the way through. Like, what is the use case for an idle stove?   And you as the user   don't often think about   why did somebody decide that the stove should show me the time?   That connection   between what is the stove doing when it's idle and what is the stove doing when it's working.   These are not obvious things, and it takes a bit of thinking about   the problem space and the technology   and what people do and why they do it. And this is difficult,   but I think the very first step is just of a core understanding   of how does a person use a device.  

They supply some input, the device takes an action,   but it's the person initiating and confirming and acknowledging,   understanding how that works, I believe is a pretty big deal.  

[00:28:38] Unknown:

1 of the other things   to think about too in terms of helping people gain understanding of how complex pieces of software work and how they can go from 0 to complete   is the question of   starting from the inside out versus the outside in, where do you start with functions and variables and data flows?   Or do you start with the complete application   and then guide people through   decomposing it and figuring out how things wire together at successfully deeper levels?  

[00:29:09] Unknown:

That's a huge question because having a goal directed activity,   looking at the total application is how you keep people motivated.   But as a practical matter, if you're gonna learn the technology, you're gonna have to start out with tiny little baby steps   of defining variables and defining functions and figuring out how the Python width statement works and those sorts of things. And having the 2 meet in the middle is, of course, the goal,   but, oh my gosh, it's so challenging   to keep your eye on the prize when   you're still trying to figure out what an elif   clause does in a Python if statement.  

And your real goal may be environmental   cleanup of the Chesapeake Bay, but you're still having trouble with elif clauses.   So, yes, there's a big gap there, and it's a difficult gap.   And it is   difficult to see how big problems are solved by lots of little bits of software.   It's very much an art form,   and I don't have great advice.   All I know is that I start my books, almost all of them with really very, very simple stuff before moving on to more advanced things   in the hope that   people will get started on the right foot. They'll come to the foundations of the language sensibly, and   eventually see how to bridge   the problem that they'd like to solve   into this technology   world that doesn't fit their problem very well at all.  

1 of the fun problems that I found along the way was   the   carbon dioxide   measurements   from the top of Mauna Kea volcano in Hawaii.   Years years years of weather data,   fabulous data set to analyze,   reasonably   clean so that you don't need to spend a lot of time fooling around with it, but you can see this dramatic uptick in c02 levels,   and you can take out seasonal variations. You can do lots of very clever,   not very difficult statistics with that dataset.   It's a lot of fun for learning,   you know, but then there's this next question of I wanna solve a bigger environmental problem,   and I'm kinda stuck looking at a small sample of data. I don't know. I don't have great advice there except   keep pressing forward, keep pushing the envelope on the technology,   keep trying to master new things.  



[00:31:48] Unknown:

As an author who is trying to help impart these skills,   there's also the challenge of providing a structured approach to being able to understand what's happening,   but also trying to present it in a way that is   interesting   and motivating for people who are reading,   who might have different backgrounds, where your example of   how to replicate   the decision making behavior of the sorting hat from Harry Potter   isn't interesting at all. They care much more about something completely orthogonal to that. So how do you provide   room for creativity   and exploration while also   providing enough of a structured approach to help guide people through   understanding   the technology that will actually help them solve the problems that they care about.  



[00:32:37] Unknown:

It's difficult to reach outside yourself. That is for sure. And so   I'm sort of fortunate that I was a traveling consultant for a long time, so I I saw a fairly large number of interesting problems.   But the other side of that is some of those problems are really cryptically weird   and, you know, the customer enterprise   caused their own problem by doing some dumb thing 15 years ago, and we're still paying the prices for that.   And,   that doesn't really translate well to a book on Python.   It was fun. I learned a lot from it. I learned some Python skills, but you know, the problems kind of rarefied.   So that was the downside of being a traveling consultant.  

Similarly,   working as I do now for Capital 1,   some of the banking problems are things that are   highly technical banking problems and some are highly   bank marketing   problems. They don't translate terribly well except to the tiny little community   that's wrestling with it.   But some of the sailboat problems are kind of general. And so they kind of be expanded   into something that other people might find interesting.   So I've sort of leveraged a bunch of those   sailboat hobby problems and they've been   a lot of fun   because   I have to tease out   the little nugget of Python programming   goodness that's in there   and leave behind a bunch of the other ephemeral things that collect along beside it.  

So that I think forces me to find something that's   kinda recreational,   not so serious,   not so enterprise   business stuff,   but still has enough technical merit that it illustrates a Python programming principle   reasonably well.   1 of the ones that I was looking at the other day as part of a second   edition rewrite   was   this question of how far away 2 things are   given latitudes and longitudes.   There's like 3 different ways to compute that depending on exactly how much accuracy you need.   And so   that set of formulas is a thing that I have   sitting on a shelf that I pull out periodically   because   if you wanna do floating point math, it's kind of fun.  

If you wanna do some analysis   of, you know, 3 d vector space,   Some of it can be fun.   If you're gonna do some statistical   aggregation   of the data,   sometimes it can be, you know, fun.   You hate to overuse the example, but on the other hand,   it's an easy thing for people to visualize because, you know, you look out over the water and say, how far away is that?   That's an interesting question, and let's explore it.  

[00:35:43] Unknown:

This episode of podcast.net   is sponsored by Datadog, the premier monitoring solution for modern environments.   Datadog's latest features help teams visualize granular application data for more effective troubleshooting and optimization.   Datadog Continuous Profiler analyzes your production level code and collects different profile types, such as CPU, memory allocation, IO, and more,   enabling you to search, analyze, and debug code level performance in real time.   Correlate and pivot between profiles and distributed traces to find slow or resource   requests.  

In addition, Datadog's application performance monitoring live search lets you search across a real time stream of all ingested traces from your services.   For even more detail, filter individual traces by infrastructure,   application, and custom tags.   Datadog has a special offer for podcast.init   listeners.   Sign up for a free 14 day trial at pythonpodcast.com/datadog.   Install the Datadog agent and receive 1 of Datadog's famously cozy t shirts for free.   As somebody who is working in technology and has   a lot of history   in being able to address these various problems and solve them and understand what is possible and what is practical,   What are the shortcomings and the ways that we   build and design technology   that make that difficult to understand as to what is possible,   and what are some of the ways that as technologists,   we can make that more approachable for somebody who does have some wonderful idea for how to solve something and require some technological component to it, but then they hit this brick wall of not even knowing where to begin.  



[00:37:29] Unknown:

I feel that pain on a fairly regular basis   because   there are some of these bits of sailboat   technology that I really   parts of it I just do not understand   at all. And some of the more technical parts of   understanding how the boat is put together.   Stuff   like fiberglass.   Like, I lived in a fiberglass house for 2 years and I understand   zilch   about fiberglass.   So I very much feel the pain of somebody who's coming to an information   centric problem   and wonders how all this information   technology   works. Because I'm happen to be living in information technology space, I kinda get it as it's second nature to me. But when I come to fiberglass   space,   I have to call a professional and say, listen, I need this thing in my hall fixed. What are you gonna do?  

And then they talk a bunch of fiberglass mumbo jumbo to me. I'm slowly   getting a better feel for how that   plastic technology of fiberglass works, but it's an uphill grind   and it gives me a sense of how other people feel about software. How do I get there? What are the fundamentals?   So I try to use   things that are foreign to me that I've had to learn on the boat   as a way to help me understand   how someone can be   completely lost   about something as simple as floating point numbers.   It always amazes me that people are shocked   by adding together 1 third and 1 third and getting an answer that the right most decimal place is not 0.66666.  

It's 0.66668.   Where did that 8 come from?   It seems obvious to me.   It's not obvious to them, and all I have to do is step out of my comfort zone with the computer and think about my discomfort zone with fiberglass   and say, oh, yeah.   Really. There are a lot of questions here that need to be answered to make this floating point thing   feel more comfortable to someone who's as lost   around floating point as I'm lost around fiberglass.  

[00:39:53] Unknown:

Continuing on that, in terms of your own experiences   of gaining new capabilities and new skills, particularly   in the technical sector, what are some of the projects that have kept you motivated, and how have you overcome the hurdles in understanding to be able to decompose those skill acquisitions effectively?  

[00:40:12] Unknown:

1 of the ones that I struggled with for a while and continue to struggle with, and I also use it as a kind of a lever for understanding other people's discomfort   is processing images.   You know, I take a picture with my phone and I upload it to my computer and I'm kinda done with it. There's tools on the phone that will do things, you know, expanding a section or contracting a section or whatever. But I had a picture that   part of it was almost   unviewable   and I really wanted to look at it more closely.   So I had to kinda teach myself about   photo filtering   using some of the Python packages that are out there to manipulate images.  

So that   helped me   also to understand   where knowledge gaps arise because I would kind of assume that pictures work this way. And then when you actually look at the data structure and look at the libraries available, it's like, oh,   pictures   don't actually work the way I think they do. What I think of as contrast in a picture isn't really exactly what's going on in there. So the coming to grips with the terminology   is part of it. And so I try to   write   in that way   for people who are   reasonably knowledgeable about some things, but don't know about how this   particular thing   works   inside the programming   language,   programming world,   computer environment in general, but really   how it's visible inside the programming language. What are the data structures and what are the algorithms.  

These are   not   obvious things   and I try to take my struggles   and project them on things that I'm perfectly comfortable with.   How would someone struggle with this?   What do they need to know?   What's the best way to expose it? It makes some of my books kinda long. We'd had an argument with 1 of the editors about 1 of these things that's 400 and some odd pages.   But in the long run, I kinda win some of those arguments because it's difficult to find stuff that you can clearly   cut out   because for the person who's not already an expert, you need a little bit of background. And so the little bit of background expands to another example, which expands to an example that motivates that example so that you can then come to   the real problem.  

So I'm comfortable more comfortable with that over the years and, you know, now that I'm in book number 9 or something   with providing   sort of a lengthy buildup to   more detailed,   more practical kinds of things.  

[00:43:03] Unknown:

Going back to your point about getting comfortable with failure,   for somebody who is writing a book, what are some of the ways that you can help convey that practice to somebody of here's something that's broken, here's how you actually go about troubleshooting it and finding a solution?  

[00:43:21] Unknown:

That is sometimes difficult. This harkens back to the newbie   who is very first wanting to learn to program because they think they have a good problem they wanna solve, but this computer thing is kind of opaque to them. Some of these things can be   challenging   because   it's not always   easy to see how it's all going to fit together, where the person's role is and   what actions the person takes, what decision the person makes,   and what the response of the software needs to be to that. Some of that is   right awful difficult,   And I don't know that I really have   a grip on that   as a writer,   because   I know that there are times when I have   really banged my head against the wall and written and written and written and torn it up and deleted it and written it all again.  

And still   the technical   editors and the reviewers   at PACT will look at it and say,   you know, Steve,   this really does not make any sense.   And they're absolutely right. Some of these things are hard   and   you need to throttle back   and say that, yes,   I have a lofty goal,   but I'm not gonna be able to get there. So let me find a less lofty goal   that might be more achievable,   and perhaps I can cut that back down to a baby step that I can take and just totter forward   a few steps and get something to work.   And I think that's probably   the only useful advice is to, you know, when confronted with something that's really, really difficult,   find ways to decompose it into the little baby steps.  

Automate   the littlest baby step first and see if you can expand from there.   Knowing full well   that at some point, you may wind up walking into a corner in all those baby steps and have to go back and say, well, what choice did I make? What choice did I make before that?   Oh,   wait. Before that,   I made a bad choice to use the wrong data structure. So let's   delete that code and start again using this other data structure.   Frustrating to delete all those things,   but it's how you learn. You walk down a variety of paths that lead to dead ends, and then have to go back and try other paths that maybe don't lead to dead ends.   But if you limit your goals to something very, very small,   then each success   is its own reward,   and it makes it a little easier to move forward.  



[00:46:11] Unknown:

Yeah. Definitely having those small wins at different stages can help keep people on track where if they don't have any path forward to understand how to even achieve some small success, then they're going to be completely discouraged and give up and go learn painting instead.   Not that there's anything wrong with that.  

[00:46:32] Unknown:

No. There isn't. In fact, in many cases,   the mental break is a good thing. So between technology   and sailboats,   there's a giant gap because there's very little technology on sailboats. It's wind and water and a big Decron fabric sail.  

[00:46:49] Unknown:

For anybody who is considering   writing a book to impart some knowledge or skill to somebody or for somebody who is looking to acquire some new technical capability? Is there any particular advice that you have for them?  

[00:47:03] Unknown:

Giving yourself the freedom to explore, I think, is 1 of the biggest.   I know some folks who   struggle   into   dead ends and then don't know what to do.   And I don't know, maybe they've imposed a schedule on themselves or they've decided   early on   on some constraints that are perhaps a bad idea   for instance that it has to run on this laptop.   Well, yeah, but it maybe it's a big machine learning thing and maybe you need to spend some money at a place like Google or or Amazon or something for a big server for a few hours to do this project that would take a month on your home computer.   You know, some of those decisions are hard decisions to make and it can be hard to unwind   a previously made decision. So   the advice that I have for almost everybody   is to try to maintain   as much flexibility   as you possibly can.  

Commit to very little   and make sure that almost everything that you decide you can undecided   quickly   and go in a different direction.   And I think the ability to undecide   and change direction   is the secret to mastering a lot of technologies.   I believe that   we stumble into these things with assumptions,   and our assumptions aren't sometimes   terribly helpful.   What little I know about the fiberglass hull of my boat is probably   all   wrong assumptions.   And each time that I talk to a contractor about some particular job,   they improve   my understanding a little bit because they basically   invalidate 1 of my assumptions and cause me to have to learn something new.  

And I think that's true for any technology,   particularly software technology, that some of it is difficult to visualize. And so you head into it thinking you know what you're talking about,   thinking you know what you're gonna build, and some of it is bad assumptions and   you need to be flexible.   You need to be forgiving   of yourself   and try again   later   differently   without   cursing your idiocy.   No. Forgive yourself.   You didn't know. You tried something. Let's try something different.  

[00:49:34] Unknown:

Reflecting back on your experience of working with Python   over the past couple of decades.   What are some of the ways that it has improved   in your experience   in terms of being more welcoming to newcomers or being more forgiving to failure?  

[00:49:51] Unknown:

This is a tough 1. But Python has grown   so dramatically.   By some metrics it is the most popular programming language. And so when I started   in the previous millennium   looking at Python, it was kind of a nothing.   The question back in the day was you should maybe be looking at Ruby because it's a better language.   I didn't agree at the time and I don't agree now, but Python has swept up in popularity   to a huge degree.   So the availability   of tutorials and the availability of exercises and things like that has just   shot through the roof. And   what I think   people need to do   as we've allowing themselves freedom to make mistakes,   you need to allow yourself freedom to   look at tutorials, look at documents, look at advice people have, and recognize that there's a lot of it out there,   not all of which is addressed   to your specific need. And so if you find something that seems unhelpful,   discard it, move on, get the next thing. Because of the huge volume of tutorial material and the huge volume of training material on Python,   it should be possible to find something that is   appropriate   for where you are   as a learner   or as a deep expert even   Because while I may be a deep expert in the language, I know squat about statistics.  

And daily, I am reminded about how little I know about the fundamentals of data science   by my peers   in the data science community. I mean, they're peers in the company, But data science wise, they're not my peers, they're my mentors.   And recognizing   that gap is helpful because it shows me what I need to learn.   And conversely, there are things they don't know about Python, so I can show them the things they need to learn. But I believe it's very important to be forgiving of yourself and to allow yourself the space   to find your mistakes,   switch over, do something different.  



[00:52:02] Unknown:

And are there any other aspects   of this topic of staying motivated and acquiring new skills and helping other people to learn new things that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:52:15] Unknown:

No. You have been super, super helpful and super thorough. You know, this is a deep topic. I've been doing it for a number of years, but I think this has really been a fabulous   conversation   on   acquiring   and perfecting   skills,   which I think is, you know, probably 1 of the most important things we can do as human beings.  

[00:52:38] Unknown:

Well, for anybody who wants to get in touch with you or follow along with the work that you are doing, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks. This week, I'm going to choose the combined trilogies of The Hobbit and The Lord of the Rings, both of which I just recently watched in the extended edition.   So it's always fun to revisit those movies. And watching the extended edition and seeing the little scenes that weren't in the theatrical releases was fun to try and pick them out and just a lot of good fun and really well made movies. So if you're looking for something to keep you entertained for a few hours, definitely worth sitting down with 1 of those. And so with that, I'll pass it to you, Steven. Do you have any picks this week?  

[00:53:19] Unknown:

I have 2 picks that are near and dear to my heart, and these are sometimes hard to find because these are kind of obscure old movies.   Doctor Strangelove or How I Learned to Stop Worrying and Love the Bomb, which is the full title, which is just in 1 sense an extremely depressing story about nuclear war.   But in another sense, it's just a hilarious   comedy of errors on the part of government officials.   I absolutely love that movie because of that that gross   conflict between the fact that it's a comedy and it's it's a tragedy all in 1 package.   I also like the movie because   it's shot in a bizarro   square format   like it was originally a 16 millimeter   film or something   made for, well, when I was a little kid for school use.  

The sort of obscure weirdness of it offsets   the black comedy   as well as the epic tragedy   that is all 1 thing in that movie   with just a fabulous performance by everybody involved.   The other 1 is the movie The General   by Buster Keaton,   and it is also black and white, but if that's just a coincidence, it just happens to be really, really   old,   like 1915   or something like that.   It was a   sort of a tragedy   about the civil war, but because it's Buster Keaton,   it's filled with these insane   physical comedy things that only he could do.   So that I believe is perhaps 1 of the funniest movies I think I've ever seen.  

But   interestingly, also a tragedy because a lot of people do wind up getting hurt when the train blows up at the end. Spoiler alert, the train blows up at the end. The physical comedy of it and all of Buster Keaton's physical comedy is just the most amazing thing.  

[00:55:19] Unknown:

Thank you very much for those recommendations.   Definitely enjoyed doctor Strangelove when I watched it. I'll have to take a look at The General.   And I also appreciate you taking the time today to join me and share your experience as an author and a trainer in helping people to   acquire and perfect new skills, particularly in the technology space. So thank you again for all of your effort on that front, and I hope you enjoy the rest of your day.  

[00:55:44] Unknown:

Thank you.  

[00:55:48] Unknown:

Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at data engineering podcast dot com for the latest on modern data management.   And visit the site of pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us it. Email host@podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.