The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to Podcast Thought 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 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 platform, it's easy to get started with the 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,   that's l I n o d e, today and get a $100 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show.   Your host as usual is Tobias Macy. And today, I'm interviewing Adam Johnson about optimizing your developer experience. So, Adam, can you start by introducing yourself?  

[00:01:05] Unknown:

I'm Adam Johnson. As he said, I'm a Django, Python developer. I'm on the Django technical board since version 2.2.   So that's the group of people who have the final say on any technical decisions around the framework. Although, mostly, we aren't called upon because   contributions are pretty obvious. And I have written a couple of books about Django and Python.  

[00:01:26] Unknown:

Do you remember how you first got introduced to Python?  

[00:01:29] Unknown:

I used HTML and CSS to develop my first websites as a teenager   and, like, got a few small contracts then, and I started using PHP to do the dynamic parts of my site.   After university, I got, my first full time job in 2012,   and I used Django and Python. That was my introduction to it. And I've been with it ever since. I really love the language.   I I kind of regularly try other languages   to try them out. I have a kind of idea that I try 1 new language each each year just to see what's out there, But I I keep going back to Python. I've not seen anything that   provides such good experience.  



[00:02:07] Unknown:

In terms of the other languages that you've experimented with, I'm curious if there are any that have kind of struck your fancy or any particular features or capabilities that you'd like to see brought back into Python?  

[00:02:18] Unknown:

Yeah. Rust is obviously, like, hot stuff these days. And I went through the Rust book at least, and I've had to poke around some of the Python extensions that are out there built with Rust. I really like it. It seems to   not only be, like, a great language with a lot of ideas around   making things fast, but also a community that's dedicated to, like, building tools in it that are quality. So I use some of these Rust based alternatives now. Like, there's a version of grep called ripgrep   that's a lot faster.   And it'll be interesting to see   how much of CPython   could be, like,   Rust friendly or use some Rust for critical parts  

[00:03:00] Unknown:

like some other c projects are doing. In terms of the topic at hand, as you mentioned, you've written a few books. 1 of the books that we're kind of focusing slightly on with for today is recent 1 that you finished about increasing your   developer experience when working with Django projects, but we're talking kind of more broadly about developer experience. And I'm wondering if you can   give your definition of that term and kind of the  

[00:03:29] Unknown:

concepts and goals that are encompassed by it? It's very kind of broad term, so I definitely focus on what what that is to me. And it's definitely a term that I've seen popular in the JavaScript community.   That's where it originated, and it's less popular in the Python world. But I think it's useful   way of encapsulating   certain things in the development practice.   When I was writing my book, I actually did a Twitter survey, and, about 50% of the respondents had actually heard of DX, standing for developer experience.   I searched for other titles, but none really captured the kind of things I wanted to talk about. Like broadly, it could mean anything when you're experiencing   development. So things like the physical nature, like what kind of chair are you sitting on or standing   desk or your keyboard layout,   or it could mean things like software tools that are helping you write the codes, test it, or deploy it. I think DX mostly applies to making these tools that you use in your development environment   to directly build the code, like, better   and faster,   hopefully streamline that process   and the related processes.  



[00:04:40] Unknown:

In terms   of the   kind of ideas of developer experience, 1 of the   most obvious analogies would be the idea of user experience design, where you're focused on the way that your end users are interacting with a given product or service that you're building. And I'm wondering   how the ideas   of developer experience map to the concepts of user experience design and some of the kind of areas of focus that might be common between the 2 and some of the areas where developer experiences its own kind of unique   exercise?  

[00:05:13] Unknown:

It's almost the same thing as user experience. It's just looking at the system a different way because we're all users of the systems we build just from the angle of we've got to change the system   rather than we're using the functionality the system implements.   And as such, we're also users of many of these tools.   So in UX, you might focus on, like, building the right UI. For many development tools, we've got a terminal   application, and you might be trying to build the right terminal   user interface. Like, what are the flags on the command line, or does it pop up with some nice graphics in your terminal?   And does it use color to make things clear? So, yeah, I'd say it's kind of the same topic with a different angle.  



[00:05:55] Unknown:

As far as the   kind of   categories   of   focus on how to   improve the developer experience,   I I guess, what are some of the types of things that you're trying to optimize for and some of the areas of focus that you can   work on to actually   increase the overall experience or capacity or sort of what are the main goals of improving developer experience   more broadly?  

[00:06:22] Unknown:

The concrete goals, the ones that you can tell your boss why you're doing   something that's not feature development, will be that you are trying to make it faster to develop features in future   and make it more accurate, preventing   the bugs that might creep in. It generally saves time by automating.   But there's also the more abstract,   less obvious   aspects. Like, if you can make it more pleasant to work   on your project or your framework or whatever you're looking at, that will then feed back into, like, people enjoying doing the development and   making contributions faster or team members sticking around and not quitting because it's very horrible environment to work in, just technically.  

Another level is that you're really trying to embed your learning back into the system. So you might learn that some feature of your database should not be used   for the current data you have. So you   disable that rather than leave it around so that you could just,   again, encounter it and try it, or someone you could try it without realizing   all the learning that you've accumulated.  

[00:07:31] Unknown:

As to some of the concrete activities that a developer can   engage with, what are some of the ways that they can   optimize their overall developer experience? And what are some of the considerations   that they should have,   particularly in the event that they're working in a team environment, as to   what types of changes to make, how to make those changes, and how to kind of popularize them or help the rest of the team understand where those benefits come from.  

[00:08:02] Unknown:

Absolutely. There's a goal like a educational aspect. You can't just throw in a bunch of tools and expect everyone to be happy with the way the workflow has changed.   I definitely recommend an iterative approach where you try and add 1 tool at a time   and get everyone on the same page and understanding   depending upon how you can do it, more documentation   or,   pair programming or small talks internally.   The problems we've encountered, this is why we're adding this tool. I hope it will help,   a setup process here. Who's in charge? Who's owning, adding such a tool? Very good question.  

[00:08:38] Unknown:

As far as the   kind of specific   recommendations   that you have settled on in terms of your own work? What are some of the   tools or practices or improvements that you've been able to make to your   workflow or your development environment to kind of improve the   experience of actually working on a given project and some of the ways that that might be specific to a certain project or a certain kind of developer ecosystem and some of the ones that are maybe more   globally applicable regardless of what type of software you're  

[00:09:13] Unknown:

doing? Yeah. There's definitely, like, a basic level that some of these kind of software engineering best practices that are always good to have there.   So source control is   easily something that you could claim fits into having a good developer experience because it allows you to make changes   without worrying about coordinating with people on files   or losing historical versions.   I guess most people do that. I deliberately didn't even cover that in the book. Then you've got the other kind of practices like writing tests,   automating   common processes like running the tests on CI or automatic deployment.  

These definitely all make the whole development life cycle better. The tools that I'm really talking about in the book are more like code quality tools and ways of writing your own,   to be like formatters and linters.   They exist for, like, every popular language, including Python. It's really good to get those in place.  

[00:10:09] Unknown:

As far as the book itself,   what was your   motivation for taking the time to write this down and codify it and sort of the overall goals that you had in actually   embarking on that exercise?  

[00:10:24] Unknown:

It was   a multipronged, I'd say. 1 was, like, for my own improvement. So I've been using a lot of these tools, but perhaps I haven't, like, explored them fully and, like, come up with, do I really believe that this is the best way to do it? Should this option be used there?   What are the good plugins that most   projects could use?   That kind of thing. And it's kind of stemmed out from my work. So when I've dropped I do consulting, I drop into a bunch of different projects and see what people are doing   and,   try and help them make improvements   on their DX or perhaps something more particular to   the Django problems they're facing.  

So I've seen a lot of different setups at this point.   I wanted to   accumulate all the knowledge I've seen from all these different projects and think, okay. What's probably   the best set of tools that are out there right now that I know of at least that kind of work together well to provide a, mean Python development environment.  

[00:11:26] Unknown:

In terms of the   Python ecosystem,   1 of the interesting elements of kind of developer experience is that what somebody considers   optimum   is going to change and evolve along with the capabilities of the language and the capabilities of the frameworks that they're working with and the available tools in the ecosystem.   And I'm wondering what you have seen as some of the changes   or evolutions in your own preferences  

[00:11:54] Unknown:

and workflows and development style as the language and the ecosystem have evolved around it. That's 1 of the hard things about writing a book is you're gonna spend ages writing down 1 way of doing things, and then tomorrow someone's come up with a new tool, and you're like, oh, well, this is definitely   raised chapter 3.   As I've aged, my preferences have definitely shifted from, like, using cutting edge new things to more well maintained tools,   especially as I see projects had, like, struggled to keep up with the change in the newer stuff. Naturally, this has come a bit from the JavaScript framework land rather than Python.   This is 1 of the reasons I like Django's because it's   pretty steady.  

It it's outlasted many smaller Python web frameworks, and it's got, like, good backing for maintenance   with, funding and   full time employees working on it. I would say DX is an area where we can actually afford to experiment a bit more, though. So I'm always open to see new tools. Some of the tools are recommended in the book were created last year.   Like there's a Django template formatter, which nobody had really tackled before.   And I think it's somewhere we can experiment a bit more because,   you know, these tools aren't running in production.   If they stop working for whatever reason,   you can just stop using them, and you're back to your code, like, writing the code slightly slower way.  

Yeah.  

[00:13:16] Unknown:

As far as the   kind of types of tweaks, there are going to be things where it's useful because it saves you time on doing repetitive tasks. There'll be things that help with   the experience of somebody who's onboarding to a given project.   Wondering what you have found to be some of the most high impact or   most important types of changes to make in a given project and   sort of some of the ways to   maybe standardize   project   structure to make it easier to bring new people in?  

[00:13:52] Unknown:

Yeah. Standardization   is very good for this.   I guess there's 2 processes that I'd focus on. Like, how long does it take to set up a project and how long does it take to, like, make a complete change, like, writing the code, making a pull request, and then getting out to your production environment,   whether that's a web server or or hardware or whatever.   And anything you can do to improve these 2 processes is the key parts of the development life cycle, and you might have many sub steps between them.   1 thing I really   like to see is a good setup process because it kind of sets the tone for new contributors.  

People join the project   can tell whether it'd be pleasant to work there just from their first day.   Also, the setup process,   if it's easy enough, then it's something that existing developers   can get into the habit of repeating more often. Perhaps they don't worry about   moving their local database when they upgrade the operating system or change computer or or things like that. And,   yeah, I would just use a kind of docs driven approach to   improving this. So first, have a, like, a well written list of steps that you need to take to set up your project. And then from the dots, you can see, okay. Well, we've got 3 steps here to build the database. Can we turn that into   1 step? We've got a step here that takes a long data download. Can we instead improve things there? Yeah. That's the kind of approach I would definitely recommend.  



[00:15:19] Unknown:

You were hinting at 1 of the kind of common pain points, particularly in web application projects, of being able to seed the development database.   I'm wondering if you can kind of enumerate some of the common pain points that people run into or some of the kind of Stockholm syndrome that developers might be subject to where they don't know how much kind of   pain and wasted effort they're going through until they find a better way to do it.  

[00:15:47] Unknown:

Stockholm syndrome is definitely a good term for this.   Yeah. There's certainly companies where there's just, like, the golden database file that someone created several years ago and has updated for new features, and that's the thing you're meant to go   download and run on, add add to your computer. And it's very hard to update this. Maybe there's only 1 person who knows how.   That's something I've focused on on several Django projects.   A pretty good way of doing it within Django that you can extend to any other framework, and that's to have a single command   that loads data using a library called factory BOIN and use that to generate random data that fits in your various use cases.  

There's a reason for using, like, generated data rather than copying down your production data. And that'd be the privacy laws like GDPR in the u EU. And I know that's like the California 1 in the US where   you're restricted to using data where it's only necessary for business requirement.   I'm definitely not a lawyer, but it doesn't sound necessary to me to load   customer data onto developer machines when they could develop features   with appropriate random data instead.   So, yeah, Factory Boy is the way to do it, and the way that I found to do it, at least. Build factories   for each of your models, if they're like Django models or SQLAlchemy   models, or, indeed, they could be any Python class it can work with.  

And it can fill them in with random appropriate data. You can specify the parameters,   and then you can also write a script that will create an admin user with a given username, create several   random   non admin users. Don't worry about the username. Just randomly generate them. Set up users in other data in different scenarios that you need. And if you have that as a script, then every time you develop a feature,   like, say, there's a new moderator level, just plug in a new line in that script, and then there'll always be a moderator in everyone's development databases.  

[00:17:44] Unknown:

Yeah. There's another project that I've looked at before. I haven't done much work with it personally, but similar to Factory Boy's Mimesis   that has the same approach of being able to do sort of random data generation.   But 1 of the other common things that I've run into with the kind of database seed script is the issue of the way you kind of alluded to a bit getting out of date with the reality of the actual database schema where as you evolve the models, you need to make sure that you're also evolving   the seed script to make sure that the database is in a appropriate state. And I'm curious if there are any   kind of strategies or development practices that you've seen to help with either   automating that workflow or just kind of process checks that help to ensure that as you are evolving the data model, that you're   keeping the   seed script up to date so that newcomers to the project are able to get up and running and don't have to fight that every time?  



[00:18:39] Unknown:

Yeah. In the book for the specific Django example, I give also a a test that checks that running the seed script on an empty database   gives data and that for every single 1 of your database tables, it has populated 1 row or that table is marked as, oh, we can't populate this logically.   Yeah. This is actually a practice. I really wanna extract that section from the book and make a blog post so everyone can read it. So maybe if I do that before the podcast is up, they'll be early.  

[00:19:08] Unknown:

And some of the other types of improvements that developers will often spend time on is things like tweaking the configuration for their editor or   modifying their shell environment   to handle some of the automated tasks there. And I'm curious if there have been any   useful practices or tools, particularly for Python developers, to kind of ease that process? I know that personally, I use Emax, and so I've been pretty happy with the introduction of the language server protocol as a way to get just better language support  

[00:19:39] Unknown:

for Python and other languages, but curious if there have been any kind of tools or practices in that avenue that you've settled on. Yeah. The language server thing is pretty cool. I use Sublime Text, and I think I've got 1 of those plugins that swaps with I set it up a while ago, so I can't remember the name. In the book, I deliberately didn't write about editors or command lines because they're so diverse. And if you wanted to cover them, probably it'd be, like, 1 book editor   or   there's some general purpose tools, though, that I did make notes of.   So in the editor, you know, if you're using   blank to format your code, very good idea to get the plug in for your editor so that reformats.  

There's a tool called editor config, to which there's a plug in for every editor, and this checks that everyone's   kind of on the same page with regards to encoding all your files as utf8,   indenting with spaces,   always leaving a new line at the end of files,   etcetera.   And then on the command line,   using aliases is a great way. It's very hard to share those, though. They tend to become quite personal.   Using a a nice prompt, and 1 that's actually written in Rust is called Starship. That's what I've started using.   Definitely worth checking out. I think Starship dotrs.  

And that's 1 of these   well written,   nice looking projects that has a good default config.   So you don't need to tweak it very much. Maybe you change   the characters and change how the Git plug in displays itself, but it gives you, like, very good, fast, out of the box   prompt. Yeah. Those are the ones on the top of my mind.  

[00:21:11] Unknown:

In terms   of   the kind of Python tooling or   specifics of,   like, development style. I know that 1 of the things that can be   contentious but also potentially beneficial is things like type hints. But in terms of, like, the language capabilities   or specific packages, what are some of the ones that you found to be helpful to improve the experience of developers, both in terms of the actual project maintenance, but also in terms of actually   writing the code and making it legible and sort of easy to follow the logic?  

[00:21:45] Unknown:

1 of the most useful tools that I've started using in the past couple years is pre commit.   So the git has a hook called pre commit that can run any scripts, but it's very hard to write these scripts   to work with at least more than 1 tool. Pre commit is a framework named after the hook, and this lets you run a bunch of tools.   It's very universal, actually. It's not restricted to Python. It can run tools in, like, 15 languages at this point. But it's, a very logical place for me   to run code formatting   and lint checking   on just the files that have changed. And then on your CI, you would have it running against every file to check everything's   in sync. It's a very good framework for   adding all these tools, updating them, targeting them at only the appropriate files, and making sure they always run with a consistent configuration,   which is always the things you end up messing around with if you try and run them yourselves.  

And it even has a CI service predashcommit.ci   that will   run them for you in the cloud very quickly. Like, within 10 seconds, you can see results on our pull request. The trifecta of tools   that Django uses and which I recommend in the book, and I would say applied to most Python projects,   would be black, the code formatter, isort, which is another formatter that will sort your imports nicely,   And then Flakgate, which is very popular, Linter, and it's got a lot of plugins.  

[00:23:09] Unknown:

You know, another element of   how to approach the developer experience question is dependent on the size of the team who's going to be working on a project or whether it's a sort of internal   private commercial project or something that's open source. And   I'm wondering how you've seen those variations   in team size or project type as   to what kinds   of modifications or   improvements that you need to make in the overall experience,   both for   new team members and ongoing maintenance and just some of the   useful tips or tools or kind of best practices that you found in that regard?  

[00:23:50] Unknown:

Yeah. The the size of the team changes a lot of things.   I haven't worked on any massive teams, but thanks to, like, blog posts and talks, we know quite a lot about how Instagram   does Python.   And, you know, they can invest, like,   astronomical amounts of effort that you wouldn't even consider.   So they use Django and Python, but they've forked both.   They call their Python something else, and we we can't see their Django implementation. But their Python 1 is is open source.   And they could improve their import time, how long it takes to, like, restart the project before they can, you know, load the page off the server   by inventing a new   structure inside their their Python implementation called strict modules, which   prevents you from running a loop during import time. You can only define classes and functions. You can't do any strong computation,   which is often the cause of very slow import times. Clearly, something they had a problem with.  

Not something that's really available to the rest of us, though. Back down in, like, most of us land and down to the scale of just being a solo developer, while you have much more limited budget.   Well, thankfully, the Python ecosystem provides many open source tools   that their setup is pretty   easy. If you go with the defaults or the configuration that most people are following,   then you get a a fairly reasonable setup in very little time, and you can kind of leverage the mass knowledge of the ecosystem.   You might have to use double quotes in your strings when you use black, for example.  

Some things you might not agree with, but that's fine. Making a trade off there. Another  

[00:25:26] Unknown:

challenge   is,   as you mentioned,   how to   keep up to date with the available options for tooling or practices,   but also what the evaluation   process looks like for deciding   whether it's worth spending the time to try and bring a tool on board or make a change to your project structure or   make a change to the, you know, local development environment setup. And just curious what your process is for   that evaluation cycle of, you know, at first glance, is this even worth looking further? And then making the decision to actually invest some time in trying to set up, you know, whatever the project or practice might be, and then the determination of how effective that change actually is.  

[00:26:14] Unknown:

Yeah. It can be quite hard to make a kind of cost benefit evaluation without trying something out. 1 of the advantages, I hope, of the book is that it has   a bunch of tools explained in short, easy to understand examples for Django devs,   so that you go, okay. It's probably worth trying this out.   Evaluating a tool is probably worth giving it a run, seeing if it captures anything on your files. You can also work, kind of backwards or forwards.   So   if you're experiencing   a certain class of bug in production or some kind of slowdown on your development cycle, then maybe you can go and find or even build a tool that will address this problem.   And then you can also go forwards and be like, well, what is everyone else doing? What's common in the ecosystem?  

Why aren't we   doing this? Or have we got our own guards against the kind of bugs a certain tool can find? Yeah. To your point of adding in a tool to run checks against your source files or what have you,  

[00:27:15] Unknown:

you know, 1 of the potential challenges that comes along with changes that   are going to,   you know, focus   on reducing the   occurrence of bugs or enforce certain formatting rules or what have you, is that occasionally, those tools can actually end up becoming   a hindrance   to development velocity because you're spending all of your time trying to   appease the code checker or the code formatter or,   you know, spending all of your time doing   the maintenance work to keep your   task runner up to date or   making sure that your project conforms to the expectations of your documentation   tool. And I'm wondering, what are some of the ways that you've seen   these   exercises that are intended to improve the overall experience of a development team actually act as a hindrance in some of the ways to either work through that pain because it's worth the benefit or understand when it's not actually going to give you the desired effect and you should just cut bait and run? Yeah. Definitely  

[00:28:19] Unknown:

could be a hard decision.   I think for, like, very common tools, then it's very clear cost benefit in the long run.   Like, say, Flategate is warning you about a particular construct that could cause bugs because it doesn't behave as you might expect in Python,   removing that safety net and because you're annoyed at refactoring your code after it tells you this could cause bugs is probably not a good decision for your project long term.   And that's where I would focus on keeping things going in the long run, but it can slow down your your fast   feature development for   sure. I would also say you can be quite conservative adding these tools and upgrading them, say, only monthly or quarterly if they really are causing a drag, and   there's not they're not so unstable that you do need to worry about weekly updates.  

And on the other hand, the pre commit CI talked about, that will actually   update all the tools it runs every week. It will update them and send you a pull request, and it will run the tools   against your repo. And if there's any reformatting, they will already be committed, so   it can be, like, a a good way of saving time there. Yeah. So using tools that   make it easier to update is a key way of saving some of this cost.  

[00:29:37] Unknown:

In terms   of   the kind of types of   tweaks or improvements   or tools that people have used or   modifications that they've made to their project approach? What are some of the most interesting or innovative or unexpected   ways that you've seen those applied or kind of tools or practices that you've encountered?  

[00:29:57] Unknown:

I think I've got 3.   So 1 would be   DevDocs, although I previously   use a separate tool called Dash. Both work well. They're rapid doc search tools.   You can type the name of, like, a function in Python, and the docs will be in front of your face within milliseconds   because it's using a local database built from the docs.   And this can   save you, like, 3, maybe 10 seconds from going through a search engine and hunting for the result that you're looking for. And that can really add up to hours per week.   So it's kind of mundane, but it's actually   pretty fun once you're using 1 of these tools and you're like, I can just look up these functions real quick, and they're also available to you when you're offline or your Internet isn't working very well.  

2nd tool that I think is pretty cool is called pyUpgrade.   And this will actually rewrite the syntax in your Python files   from old versions to new ones. So it will take old string formatting and rewrite that as an f string. It will take old versions of type hints from Python 3.6   and convert them to the newer versions.   And that just can save a lot of   work and fast around normalizing   on which version of the syntax to use or, you know, which one's more performant even. In the case of f strings, they're always a bit faster than the other options.   So it can really actually reduce the toil because if you as a team want to decide to use   new Python features and you want your old code to be updated,   that's a great tool. I was thinking about a third 1, but I've forgotten it now.  



[00:31:31] Unknown:

In your experience   of writing the book and improving your own   developer setup, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?  

[00:31:43] Unknown:

Yeah. Writing a book is challenging, but I find it very fun in the moment. So that's good.   It definitely forced me to reconsider many things that I thought I knew fairly well, tools that I might have used on a dozen projects even.   I've learned them from scratch in order to kind of present an easy solution.   And it also forced me to go, like, look out in the ecosystem on what's out there. Maybe there's some things that I've seen,   but they'd pass me by. I didn't have time to evaluate them at the time. So I could look deeply at things and decide, oh, well,   I probably wouldn't use this in many situations. This 1 seems to be the better option.  

Of course, I'm still finding things out. I've got, like, sections that I now want to rewrite because I found, like,   a better way of doing things. Like, I described setting up ESLint in the book,   but I've also come across standard JS, which is kind of much more opinionated, and it it doesn't require you to set up plug ins.   Now that I've described how long it can take you to set up ESLint, I'm considering whether I should swap   the book to just say use standard JS because it takes no configuration at all. The other thing is just how slow writing can be. That was, like, something I'm relearning. Like, my first book, I wrote it kind of back to back and got it out quite quickly.   But this time, like, some parts, it was like wading through Treacle, making these decisions about what to recommend,   changing my mind on things, or finding a better way of explaining things,   especially when you, like, start writing   about a tool that builds on top of what another 1 does, and you realize that actually would have been better to describe the first 1 slightly differently.  

So it's a bit of a jigsaw puzzle.  

[00:33:24] Unknown:

Your mention of standard JS also brings up the question of   the kind of cross language   requirements that are occasionally necessary   in various projects or   in setting up a development environment or a project   structure.   And we've mostly been focusing on improvements to experience when working with Python projects. But what are some of the   considerations that go into tool selection when you are working across multiple different languages? Or   maybe you're working in a microservices environment and you're trying to kind of standardize the experience across different languages that live in different repositories.  

[00:34:06] Unknown:

Yeah. It's a challenge. Any web project will probably have 4 languages. Right? HTML, CSS, JavaScript, and then your Python.   Microservices   could be built with anything, so you've got to have something that everyone can set up fairly easily.   This is 1 of the reasons I like Preakmit is that it can manage all these other   tools built in other languages with the universal   command line only interface.   Anyone   using Git can become familiar with it.   It sets up Node for you, for example.   If other languages like Rust, it will need a Rust install, but Rust is pretty easy to set up if you are using any Rust based tools.   Yeah. So pre commit is probably 1 of the ways that I like to set up these tools   larger environments.  

I know that there's   a lot of things out there that can help docker based   tool runners,   but I haven't had to use many of these.  

[00:35:00] Unknown:

And   in terms of   the   ongoing work that you're doing with your client projects and your own projects, what are some of the new tools or practices that you're taking a look at or some of the lessons that you want to bring in from the other languages that you experiment with to improve your just local setup and your kind of standard project structures.  

[00:35:23] Unknown:

Yeah. I've   been learning a lot about type hints in the past couple years. I started blogging quite a lot about them from May, June last year, and so I've been trying to roll those out. I've added them to all of my open source packages.   Certainly, they're not perfect yet, but I think they're providing a reasonable level of type safety for everyone who's using them. I haven't had any complaints, at least.   There's still more to learn. And for adding type hints to client code bases is definitely   a more careful approach is required.   There's so much new stuff and changes to   the typing ecosystem.  

It's   best to, like, target the typing changes to 1 part of the code base and then build from there.   Another thing that I've been looking at over the past week is Cython, which isn't quite a DX tool, but it's kind of cool and secret. I don't know why people aren't using it more, but I'm looking at it again. So Cython lets you write Python code, but compile it to c and becomes a c extension   that you can then use directly from Python as if it was written in Python like a standard library built ins, and it provides, like, really fast speed ups. You can provide a few type hints with the newer versions, and it will use those to optimize the code as well.   So, yeah, I've been playing around with this this past week. I've been like, Why aren't there more of these, like, serialization   libraries and   things that we need to be fast written with it? I found that Pandas and PyAML use Python, but, it still seems   underused.  



[00:37:00] Unknown:

Yeah. I think PyDantic uses it as well.  

[00:37:03] Unknown:

Uh-huh. Right. That's 1 of the ways it stays faster.  

[00:37:06] Unknown:

And as individuals   and teams are starting to   go down the road of optimizing the   developer experience and their local setups, what are some of the potential pitfalls that they should watch out for?  

[00:37:20] Unknown:

Definitely, as we talked about earlier, like, upsetting your team members or at least surprising them with a lot of things that they now have to worry about or messages that they might not understand.   So definitely worth taking it 1 step at a time and coordinating with the rest of the team.   There's also the kind of paradox of automation, as they call it in   the airline industry, which is, you know,   airline pilots.   They do the takeoff, and then they switch over to autopilot,   and then they don't need to do anything until they get to the destination where they start landing the plane. And they found that this is actually, like, very bad for their skills. Like, all those hours   sitting behind the stick, worrying about keeping the plane, you know, level and on course, we're actually very good for them keeping sharp and understanding   what the aircraft is doing.  

And I think there's policies now where   autopilot isn't used all the time. So I think you can get the same kind of thing if you do over rely on automation. You do have to understand what these tools are doing. Something like py upgrade that's rewriting your syntax.   You do still need to understand the old and the new syntax   so that you can accept the change rather than, like, blindly press yes. These tools can have bugs, and these bugs   can translate into bugs in your code if you aren't careful.  

[00:38:36] Unknown:

Are there any   references or resources   that you recommend folks take a look at once they're finished with your book and they wanna dig deeper into some of the optimizations that they can make for themselves and their team?  

[00:38:48] Unknown:

Yeah. There's a section at the back of the book where the things that I didn't manage to fit in, but there's definitely also, like,   a whole literature of things that would be good to understand,   like the phoenix project book, which is a DevOps   kind of fictitious story that shows a company transforming to,   well, basically improve their overall delivery speed and treating things like a factory,   worrying about the different stages of development as units and how new code could keep moving through.   That is, main inspiration for me. So I read it maybe 5 years ago.  

[00:39:22] Unknown:

Are there any other aspects of developer experience improvements   or specific recommendations or your experience of writing the book that we didn't discuss yet that you'd like to cover before we close out the show? There's the things that I skipped from the book I mentioned earlier, like improving  

[00:39:38] Unknown:

your command line, improving your editor, improving   your Git usage, and GitHub as well. There's a lot of little tricks on GitHub, if that's what you're using, that I would have loved to, like, write chapters on or write a dump of links. So maybe I'll write some of that in the future.   But, yeah, those are   areas you should definitely do some research and invest in. There are courses out there for improving your setup with Versus Code or Emax,   where people have assembled what they what they think is the best set of resources. So those are definitely worth checking out. It's just out of scope for a book focused on written by 1 person.  

[00:40:16] Unknown:

Alright. Well, for anybody who wants to get in touch with you and follow along with the work you're 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 movie Eternals that I just watched recently. So it's 1 of the newer   Marvel movies that came out and just a really interesting storyline and an interesting perspective on the   kind of progression of the human race and some of the ways that these supposed celestial beings have influenced it. So just a fun story all around and recommend taking a look at that. And so with that, I'll pass it to you. What do you have for picks this week, Adam? Yeah. I'm a big fan of eternals, actually. I just like to say, I really enjoyed the Neil Gaiman comic books. And then when I heard them make a movie, I was pretty excited, and it's come out well.  

[00:41:02] Unknown:

In general, I'm not, like, a fan of the Marvel Cinematic Universe. I gotta admit, like, with my partner, we watched the whole series of 20 whatever movies in the lockdown in January last year, just putting on, like, a movie every other night. So that got us through, like, COVID lockdowns.   So in that vein, my pick would be the Moon Knight trailer,   the series, which is coming out in a few months.   Moon Knight is 1 of these rarer characters.   It's gonna be an interesting twist on a classic,   superhero   because he's got multiple personalities.   1 of them being the the moon knight, and he's trying to work out what's going on. It looks like it'll be a bit of a kind of fight club memento style thing. He doesn't know what he's doing at night trying to figure out what's going on. So a darker take.  

We're very excited.  

[00:41:51] Unknown:

Well, thank you very much for taking the time today to join me and share the work that you've done on the book and your own experiences   of helping to improve developer experience   for your own projects and your clients. So definitely appreciate all of the time and energy you put into all that, and I hope you enjoy the rest of your day. Thank you very much, Johannes. You too.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at at dataengineeringpodcast.com   for the latest on modern data management.  

And visit the site at 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 about it. Email host at podcastinit.com   with your story.   To help other people find the show, please leave a review on iTunes and tell your friends and coworkers.