It's all about trying to prevent bugs, work a little bit smarter, and make sure that you also take on that mindset that, like, why am I typing this git command out the long way over and over? Maybe I can add an alias. Why is it so hard for me to find these branches? There must be a way to write a little one liner that will filter these branches that I need every week or something. Hello and welcome to the PY Bytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Eldebos. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Welcome back, everybody, to the PY Bytes podcast. This is Bob Baldwoss, and this week I have a very special guest. With me is Adam Chu Johnson. Hello. Welcome to the show. Thank you for having me. Yeah, I'm very happy to have you on, based on the work you've been putting out and most recently your new git book. Very excited about that. Before we dive in, maybe for people not just familiar with you and your background, do you want to give a quick intro to our audience? Sure. I'm a Python developer working mostly with Django. I've been using Django since 2012 and I've been contributing to it since 2014. I'm now on what's called the steering council or what was the technical board, which is like the final say on whether something gets added to Django, but our powers are rarely used. Mostly there's a community consensus, and I'm quite an active participant on that, I think. Nice. Yeah. And you also do consulting, right? Yes. I work as like a Django specific consultant. I help companies find ways to improve their projects or tackle hard problems or scaling problems. Nice. Yeah. To kick this off, do you have a win of the week? My win of the week would be Django con us. I didn't attend. I did have a remote ticket so I could drop in on some talks and watch them. Here, it's just finished, but with the sprints at the end, there's always many great developments and ideas that get pushed because people have been able to talk in person and there's been some great questions and topics discussed on the mailing list and forum where most activity is now. Yeah. So I'm really excited to see where this takes takes things. There hopefully be some more hands pulling on the ropes that keep Django moving forwards and interesting directions that are finally going to be taken? Yeah. Was there anything specifically you want to highlight? Yeah. The one thing that I'm quite interested in that I haven't had time myself for is the server reloader, Django's development server. It needs to reload whenever you make a code change. So you can see the new version of whatever you wrote in your browser, the built in one. It works by polling your file system, so it just checks which files have changed. And that's very expensive. Django has an option to use this thing called Watchman, which is a tool from Facebook that asks your operating system for notifications when files change. And so it's very efficient. It doesn't use any cpu when nothing's happening. And that just stopped working with Python 310. Facebook haven't been able to fix this watchman library. I wrote in my Django DX book about how to use Watchman, and that was mostly written on Python 3.9. And then I was like, they'll fix it for 310 soon, I'll just publish the book. And they haven't. So we need to find an alternative. And yeah, someone has come across this and posted on the forum. So I've replied today with like, where I think things are at and where I think we can hopefully proceed. That's awesome. Didn't you also have a plugin about reloading? If I remember correctly, it's experimental. Yeah, there's Django watch files, because watch files is an alternative to watchman, developed by Samuel Colvin, very prolific developer. So hopefully Django can use that. We've got an alpha version and it would be good if we could clean it up. Nice. Cool. Well, my win would be coming out of a two week Spain road trip with Julian, and Coach Robin was here as well. So we did a lot of planning and we even recorded shorts and all that. So it was great fun. That sounds amazing. Yeah, yeah. You have to get together sometimes, you know, that's kind of similar to your win. Right? Like, although it was remote, it was really good to, to be active in the community and meet people and be close to the development. Yeah. Maybe we can just dive into, straight into your latest book. It's boost your git DX and it's, I think, your twelve plus years of git experience. And I think you're ready at 1300 repos by now. A lot of experience distilled in a concise set of tips. Right. So do you want, want to highlight the book, why you wrote it, and maybe some highlights? Yeah, sure. Boost your git DX is the second of my boost your DX series. I don't know if there'll be another one. We'll see. Following boost your Django DX. Yeah, maybe twelve years of git experience, maybe eleven, however much it is. I've used git a lot. I've contributed to a lot of open source repos and that's why I have 1300 apparently on my git profile now. I don't check the account. Most of those are when I'm reading up on a project. I'll spot something in the docs or some small fix and I just get in there and make it. I think that's one of the great things about open source and GitHub, the community. It's just everything is available. It's not fixed like it used to be when I was programming growing up. Like you had the thing, you had the docs, and that was it, and now you have this massive community. Yeah. So the book is all of these tips for using git better. I would say git as a tool has evolved very organically, and there are a bunch of bits of configuration and stuff that could be on by default for a better experience or would be better for most developers who are using a workflow with GitHub. So I've tried to collect all of these that I've learned about and added to my git config over the years and put them in a book and also explain some of the more advanced commands that I've seen other developers struggle with. Because also the git docs are very high level, abstract, and filled with ancient technical details that make it a bit hard to understand what's going on just from them. Yeah, I'm really impressed with the amount of stuff you put in the book. I have not finished it yet, I'm 44% in on the Kindle. But yeah, as some of the reviews are saying as well, after chapter one or two, you already get key insights you didn't know about. And that's definitely the case. I'm learning new things all over the place, even after ten plus years of git usage. And also, yeah, surprising things that I might have been saying or doing wrong, like having a git keep file. And I think you recommended to have a gitignore file in certain directories and stuff like that, right? Yeah, there's a lot of little things that there isn't an official document on, like what about these git keep files? And there's just some better ways to do it that haven't spread throughout the the tutorials and whatever. Specifically the git keep files for listeners. That's this practice of making sure git keeps a directory inside a repo because it doesn't track directories by default. So you make a little file and a convention has arisen from I don't know where to call that file gitkeep. So just empty file. But actually if you use the git ignore mechanism, you can create a Gitignore file in that directory with a couple entries. Let's say ignore everything in this directory except the Gitignore, and then that directory will be tracked and it's an official way used by git and it's clearer to people in the future reading what is this file? It's documented, you can look up and figure out what it does. But I also like about your books and that gets into the DX part of it. I think you call the books DX for developer experience, and I think that's inspired by UX of user experience. It's way more than just the topic at hand. It's not only git you talk about related tools. For example, you challenged me on using AG or the silver surgery I think you recommended. What was it? Rip grab, rip crep. Yeah, so I definitely. And on the Django book I think you go with the dot go browser. And so it's really cool that you address all these related tools as well, all with the goal, I guess, to make your experience as a developer more efficient. So can I talk a bit about the choice of DX in the book titles and your overall view or strategy with that? Yeah, I try to embody the mindset of kaizen, which is a japanese word from manufacturing lines that means continuous improvement of the working environment. And the idea is like at a construction line like Toyotas, everyone will try and make a few improvements each week to their specific area, and over time that leads to them producing better cars more efficiently with fewer errors and a little bit at a time, you get this compound interest of big gains. I'm trying to embody that kind of thinking for developing. I know that the term DX has gained a kind of bad rap from web frameworks that prioritize the DX, the developer experience over the UX, the user experience, making it very easy to churn out pages that are megabytes in size and don't work well on a low end device and exclude people from reading those websites, especially if they're like necessary government websites. It's terrible. I don't promote that. I would say I'm always in the goal of getting a better ux. And that means let's try and avoid making this stupid bug again. So maybe we need a lint rule. Let's try and be a little bit faster at browsing the code base. Use a tool like Ripgrep or AG, the silver searcher. I mean, it's also a good tool, don't get me wrong, but it's just maybe a little bit old now. Yeah, yeah. So it's all about trying to prevent bugs, work a little bit smarter and make sure that you also take on that mindset that like why am I typing this git command out the long way over and over? Maybe I can add an alias. Why is it so hard for me to find these branches? There must be a way to write a little one liner that will filter these branches that I need every week or something. Must be a better way. Yeah, I can definitely test how all these little tweaks can just compound over time and make you ten x faster combination with good command line tools, proficient git usage, in my case the vim editor or whatever editor you use. That all adds up again, going from that, yeah, Kaisen philosophy and very practical tips, as opposed to these linear tutorials that can waste a lot of time. I think your books are really, really spot on. Another thing that really comes out is code quality and tooling. So pre commit was early in the book. So the automation of tools like black isert and flake, I think you often call those out, and you have also contributed or built a lot of related plugins. What do you think of the current state of python tooling these days? I think it's very positive. There's this good set of established tools, like you said, black flak eight isort pre commit as a framework for running them all, which is language agnostic, of course. And then that's new player, roughly, which has massively increased in popularity after it was invented like a year and a bit ago. I think it's not that old. So yeah, there's people thinking about it. There's good tools, there's a lot of things you can add to. Just check on your project, we'll see if rough wins out. For me, the python compatibility thing is key, and I know they don't have a way of making a plugin in python right now. Maybe I could just pick up rust to write some limp rules, but it seems like a bit of a high cost for me to start maintaining something in rust, which I won't use that often. And the speed of flake eight has never really been a concern. I know it is at larger companies, and I'm sure it makes sense to use rough there. Yeah, I'd say it's pretty good. It's good. There are more and more people thinking about it type hints as well. They're just growing in popularity. My PI is getting better with every release and yeah, I'd like to see where things go. Yeah, it's exciting times. I'm really happy with the tooling we have available. I've not really used rough a lot myself, but I hear increasingly people switching to it. So it's interesting because of the performance. Yeah, quickly. I also wanted to highlight your extensive work on Django projects. How do you envision the future of the Django ecosystem and its role in modern web development? For example, one trend we picked up with the coaching Python developers are often not that eager to write JavaScript, so we have HDMX now. And I think you also have a Django HDMI plugin, so maybe that's one thing you want to highlight. Yeah, and anything else on the Django side? Yeah, I'd say Django is like the big and dependable framework. It's over, it's 18 years old this year, and it's still continuing to develop at a good pace, like not too fast. It never introduces that much churn to your projects, but it gains new features for your database, for generating your forms and that kind of thing. I'd say despite all the technological churn, the core of the web, HTML and CSS, are still fundamentally the same, and they're also getting better. There are so many things you can do in CSS that you couldn't a couple years ago, even, that your need for a bit of JavaScript to make that flashy animation or whatever is decreasing. And I think that's why HTMX is getting popular, because we're realizing that the core of the web without JavaScript is more and more capable. So those extra bits of interactivity, we can do those without needing something running on the front end to fetch that extra content. We can get HTMX to be the thing running on the front end, which isn't very large, and then write some more HTML attributes and it will fetch extra content when needed, when a user presses a button or whatever. So we can have that kind of interactive experience without heavy framework. I like it, and I think Django fits in well then. Yeah. And are you mostly back end? I mean, I guess you are, but for front end, do you mostly exclusively use HDMX or also Alpine JS, or maybe even a framework like react or vue versus just front end. It's not really. You don't do that much with it. I do a bit of a front end, especially for my blog or if I'm building a little side project, but that is mostly getting the HTML and CSS right. I try to avoid writing JavaScript if I can, because it's a bit harder to maintain long term, especially if you jump into one of these frameworks. I don't want to have to be fixing NPM install in a year's time. I've seen that happen before. Oh, this thing is now gone. That thing has to be upgraded. I don't have the time for that. In terms of my client work. I have touched on Alpine J's over the last year and a half with a client who's using that in combination with HTMX. I like its approach. It's similar to HTMX, add a few attributes on some elements and enhance its interactivity, but I can't say I use it too much. So you maintain a lot of open source projects? Yeah. What motivates you to keep building them and maintaining them? And what are some advice you can give for budding maintainers? Yeah, sure. The open source projects, I have maybe 34 of them that are live right now. They're mostly relatively small. I like to build something that solves a targeted problem and mostly glues together, like Django and HTMX, for example. So the package is called Django HTMX. Straightforward. Yeah. I see building open source projects as kind of like a flywheel effect for many of these things. One person needs to build it once and maintain it, and then everyone gains from it. Then that also feeds into me gaining some knowledge that I can share in my blog and books, and also some things I can add to client projects when consulting, and also when I work on a client project, I can maybe solve a problem for them and turn that solution into a plugin that I then share. For example, I recently created a flakate logging plugin with a bunch of rules for misuse of the logging module in Python, and that doesn't need to be closed source at all. That can be shared openly, and now everyone can install it and have these protections against misusing the login library and their log messages don't come through, which was the case I found there. Nice. Yeah, I saw your article on that, I think also on Twitter we had a conversation at some point about freezing daytimes freeze gun, which I think you made an alternative for yes, freeze gun is incredibly slow once you have a large amount of code because it iterates over every imported module. So I built an alternative called time machine that is actually using the C API to patch out the functions inside the date time module, because mock mock doesn't work to patch them. And that's why Freezegun does this very slow approach. So the time machine library, you can speed up your tests by like several minutes, which you might not even realize that freeze gun is the slow thing until you profile. Cool. As for advice for budding maintainers, as you asked, I said just get into it and dive into a project like Django that has very good contribution guide. It might not be easy to find a ticket, but you can probably find some small change to the docs or some improvement. I say it might not be easy just because there's so many people looking for Django tickets that they get snapped up very quickly. Then go out and look in the community at other things that you've got in your requirements. See if they need some improvements like testing on the latest python, and just figure away from there. Yeah, I think that's what gets people is that they think about contributions, like making some changes, how function based views were, or something from big. You can often just start small with documentation fixes and stuff like that are not necessarily heavy code related, just to get familiar with the project and the guidelines in the community. Right? Yeah, and I've had that experience recently because I contributed to git as part of writing boost your git DX. And it's a bit of an interesting one because it does not use GitHub or any other code hosting platform. It uses git as originally envisaged over email. So you're emailing the patch files back and forth. There is a little bit of a widget that you can make a pull request on GitHub and it sends the email for you, which I used. But apart from that you get all your feedback over email and yeah, that's a bit of a different workflow change, but the community was very welcoming and very helpful at feeding back and I hadn't written any proper c code in a couple years, but it was pretty easy and readable and fixed. Debugging git made a docs changing git and some others are in progress and it feels pretty good to have like worked on that tool that maybe a few million people use. That's pretty amazing. Yeah, and it also comes from, you know, you constantly putting content out there, so you run into these type of scenarios, right because if budding maintainers or contributors are looking for a problem, you might just not know what to fix. But by, you know, building a lot of tools and projects and even writing books, you just naturally run into these type of issues, right? Yeah, exactly. The bug I found was actually, I, I was listing out the ways of using. I think it was git stash. I was like, yeah, that would be the most recent bug. Yeah, git stash. I was like, if you do git stash with this flag and you have a binary file and then you unstash it, it doesn't work. And that's purely because I was trying to tabulate all the ways to use git stash in the book. And I was like, huh? Why does this one not work? And when you're looking at it like that, you're not like trying to get a piece of work done. When you're looking at, it's just like, this is git stash. This is how it's meant to work. This one doesn't work, then you can realize a bit more clearly, perhaps, that there's a bug and you can get involved with figuring out if you can reproduce that bug, send an email, and now I know where to look to fix it. That's work in progress. Nice. Into the trenches. Love it. So with pybytes, we aim to shape well rounded developers. What are your top recommendations for developer looking to diversify their skillset and to contribute more effectively to the community? A bit related to the last question, of course, with the open source, but maybe you have a couple of tips on top of that. Open source aside, I'd say the most effective thing I found is to start a blog. I'm always writing. Not everything makes it into a post, but it does mean that when I'm working on something, I make a note in my Evernote. I'm like, here are some bullet points on the thing I learned today, and that little bit of reflection, a little bit of writing down those commands so I might be able to reproduce that thing in the future. I think it really boosts my learning. And yeah, if you do get any posts out there, it doesn't really matter about the, the high level quality. You can start with this very easy today I learned format where you just paste a few commands and outputs and be like, this is what I did today and this is what happened. I think it really can help you learn and also share your learning. The less obvious things that you encounter that you then share. It's great. In Python, there's a tool called Pelican that can generate a blog. That's the one I use. I don't know what you use, but I find it very effective. We started there. Yeah, as well. Python keep it. Python keep it in Python. Write a few templates and then you can write your blog posts and mark down or restructure text and away you go. That's literally how we started spy bytes with a pelican block. There was nothing more. Just sharing knowledge, just learning and writing it up. Also, I was going to ask you about the notes as well, because writing a book that's so dense in tips, you must have pretty good note taking system. So you just use evernote. I have a chaotic note taking system, but I think the more you write down, the better. I mean, sometimes I look back through my notes, I'm like, huh, I wrote this thing a year ago and then I wrote a very similar note this week and I'm like, huh, maybe this is an important problem to look into writing up properly or solving and whatever. So, yeah, just storing things and finding what works for your brain is the best. Yeah. Cool. So open source starter blog, maybe one tip more. Well, have you believe in yourself? I think a lot of. Yeah. As you always promoting, a lot of people coming into open source think that it's like big and scary. And as long as you're in a good community like the Python and Django one, you'll get a decent response on the other end. If you're willing to put in the work to communicate what you're trying to do, the full error that you're seeing or the full problem you're trying to solve. Yeah. Just believe in yourself and you can do it and you'll find a lot of positive rewards. But there must be sometimes a bit of impostor syndrome, right. With these efforts, especially when you get a lot of eyes on a repo or a contribution or a book launching book, that can be scary, right? Oh yeah, yeah. That's like. It can be crushing. Is anyone reading the book? I don't know. Is it good? Is it? Have I just wasted a year? But yeah, the only way to get over is to get out there, right? Yeah, just carry on. Some things are hits and some things aren't. My most popular blog post is about Pip install from git. I thought it was a quick. Today I learned style posts. Now it's the one that people rely on from Google results, apparently. So that's a bit of a maintenance responsibility. Yeah. Well, our top article, I think is how to make a subclass in Python, and we would never have expected that to be a top hitter. Exactly. Awesome. Yeah. Thanks for sharing. Anything else you wanted to share around recent developments with the git book? What you're doing or think we're good? I would like to promote. The pricing of the book is regional dependent, so if you're in a low income country, then the price will scale down so you get up to a 60% discount based upon purchasing power parity. And also there is a bundle deal. So if you want to buy boost your Django DX and get DX at once, you get a $10 discount. Nice. And it's all on Gumroad, right? It's all on Gumroad. Yeah, we'll link that in the show notes. And I highly recommend people getting all three books because you have the testing, Django and the git. So it's a really wide skill set. And again, the tips, the bite size approach we really like at pivots as well. Lastly, goes with our style. Yeah. Lastly. Yeah, what are you currently reading? Have not got much time to read book, actually. Writing has consumed some of that time, but I do have some time in the day to listen to podcasts. So like this one, I actually quite enjoyed the Jim Hadop I think was his name. Yeah, it made me feel a bit warmer towards rust, another non programming podcast. If people want a bit of a recommendation, there would be if books could kill. It's very enjoyable tour through books that were popular over the last few decades and the kind of bad ideas they injected into the discourse and why they were wrong. But why did people go for them and what were their effects? They call it the kind of airport books, the ones that you pick up at the airport because you forgot what you really wanted to read at home. And then you're suddenly reading some like pop psychology thing about how if you don't eat the marshmallows, then you're going to be the CEO. Nice. Cool. Yeah, I'm obviously still reading your book, and I'm also reading the new Arnold Sportsnegger. Be useful. Kind of a nice mindset book that looks good. I might be able to find that on audiobook. Yeah. Well, Adam, I much enjoyed this conversation finally getting to meet you, and thanks for all. You do put tremendous value out there for the community and for our python fellow developers. So keep it up and thanks for sharing on the podcast today. Oh, thank you for having me, Bob. We hope you enjoyed this episode. To hear more from us, go to Pybite friends. That is Pybit es friends and receive a free, free gift just for being a friend of the show. And to join our thriving community of python programmers, go to Pibytes community. That's Pibit es forward slash community. We hope to see you there and catch you in the next episode.