Today I’m joined by Dustin Ingram, a developer advocate at Google focused on supporting the Python community on Google Cloud. He is also a director of the Python Software Foundation (PSF) and a maintainer of PyPI. In this interview, we discuss how Google’s use of Python might differ from your own, what it takes to maintain PyPI, his goals as a PSF director, his love of PyCons, and more.
Ricky: Thanks for joining me, Dustin. I’d like to start with my usual questions: how did you get into programming, and when did you start using Python?
Dustin: Thanks for having me!
I like to say that my first programming experience was when someone decided it was allowed—if not encouraged—for me to carry around a TI-83 calculator throughout high school. I spent far less time in geometry class learning geometry and far more time writing text-based games in BASIC and, later, programs that would do my physics homework for me.
I even released my first open source program: a little animation that made your calculator screen look like the flowing, garbled characters in The Matrix (which I was obsessed with) and published it to Texas Instruments’ third-party software repository.
But my first actual exposure to programming was probably when I was first introduced to Logo, the graphical programming language with the turtle as a cursor. I think it was elementary school, and the task was to try and reproduce some simple shapes, but I distinctly remember being blown away by the endless possibilities. I wasn’t confined to a predetermined path like a lot of the point-and-click computer games I had played before—I could make that turtle do anything.
My dad is a tool designer, and when I was in high school, he ran a machine shop. The shop had a lot of the classic metalworking tools: lathes and milling machines that were operated mostly by hand. But they also had some newer computer numerical control (CNC) machines that were programmed with a language called G-code.
If you’ve never seen G-code before, the best I can describe it is as a mashup of BASIC and Logo, but instead of a cute little turtle moving around, you have a drill bit spinning at several thousand rotations per minute attached to a half-ton machine. All the oldheads who were used to operating the classic, manual machines couldn’t quite wrap their head around this new technology, but it made total sense to me!
Later in high school, I took some computer science classes that taught me some Java and convinced me that the field was worth pursuing. I went to college for computer science and encountered Scheme and other Lisps, some C and C++, but mostly more Java.
Around that time, I started working at a research lab for the university, and while that was all Java too, some of the older, wiser grad students there were really into this new language called Python and were basically trying to sneak it into as many of their projects as they could. Once I was exposed to it, I was hooked too and started trying to write as much of it as I could.
Later, when I discovered the larger open source community around the language, the do-it-yourself ethos that it embodied, and the incredible focus on usability, readability, and beginner-friendliness—not to mention some of the incredible people within it—I was hooked. I got very lucky in the sense that soon after I was exposed to it, it really started to take off. It’s hard for me to imagine where I’d be without Python. I owe a great deal to the community for that.
Ricky: By day, you are a developer advocate at Google whose focus is on supporting Python developers on Google Cloud. I previously talked to Brett Slatkin, who discussed the history of Python at Google, and Google recently became a Visionary Sponsor of the PSF. With Google being a big supporter of Python, what does the current landscape of Python look like at Google, and what’s on the road map for Python and Google Cloud in the future?
Dustin: When folks ask me what Python is like inside Google, I usually say it’s a bit like an alternate universe. All software engineering inside Google sort of exists in this bubble that has its own idioms and tools and patterns that sometimes don’t really exist in the wider ecosystem. So while we have millions of lines of Python code and thousands of engineers writing Python every day, some of our internal experiences around using Python just don’t map to the experiences of the rest of the community.
For example, you might have heard of the Google monorepo, but one side effect of a monorepo is that we don’t really use the Python Package Index (PyPI)—at least not like most users of PyPI use PyPI. So anything I could tell you about how Google uses Python these days probably wouldn’t make much sense without you having a completely different perspective.
That said, I probably couldn’t tell you much more than that! Not because it’s confidential, but because I try to spend as little time “inside” that bubble as I can. I’m an advocate for regular developers that write Python and want to use Google Cloud. I’m not going to be able to develop empathy for their experience if I’m living inside the Google bubble. We have a whole team that’s focused on making Python work for Google’s engineers. I’m focused on everyone else and helping us build good tools for those people.
I think a lot of folks interpret “developer relations” to be how a company does external marketing to developers and evangelism about its products, and while that may be true in many places, at Google it’s really the reverse: it’s a deeply technical role that is about bringing feedback from developers, and an understanding and empathy for those users, to our engineering and product teams.
While you may see me occasionally in a video or on the byline for a blog post, that’s really the tip of a much bigger iceberg that you can’t directly attribute to me, where I’ve advocated for changes to our products, reported bugs, and the product is better for it.
I still consider myself an engineer and do sometimes contribute to our products, but usually it’s the open source parts of it. For example, with Cloud Functions, I authored the Python Functions Framework, which lets you serve a single Python function as a service anywhere, and contributed to the buildpack that powers the runtime. These are built in a way that should make sense to the Python community, not the weird Google alternate universe, and anyone can contribute.
The other part of my work is that I use my experience with and connection to the Python community to help Google manage its relationship with it. This includes a lot of things, including ensuring we’re being good software citizens, publishing idiomatic tools, exerting our leverage in the right places (and not too heavily), managing our presence and conferences and our financial support of the ecosystem, and so on.
Google became a Visionary Sponsor not just because we want the PSF to continue to operate (which we do, of course) but also because we wanted to help ensure that some specific goals of the PSF were able to happen, like hiring a CPython developer-in-residence, who will be the first developer paid full-time for a year by the PSF to work exclusively on CPython.
Ricky: One of the hats you wear is that of a PyPI maintainer. All Python developers have used PyPI at some point when they’ve pip installed a package. But many readers might not know what goes into building and maintaining something like PyPI. In fact, you recently tweeted about the enormous growth PyPI has had. I was wondering if you could shed some light on what keeps PyPI up and running and what impact the growth of Python has had on PyPI.
Dustin: A great question, and perfectly timed! I just published What does it take to power the Python Package Index?, which is an update to a similar post from five years ago and goes into a ton of detail about how much we’ve grown, what it takes from a technical perspective, and how we support that growth. I’d argue that it’s required reading for anyone that wants to use PyPI.
The TL;DR I’d want people to take away from that article is this: PyPI, as a project of the PSF, is a) a non-profit that’s b) almost entirely run by volunteers and is c) dependent on a lot of donated infrastructure.
I think folks coming from other language ecosystems where package indexes have VC funding or multibillion-dollar companies behind them might be surprised by this, but I think the fact that it works is really a testament to the power of the Python community. But it’s important to keep that in mind when something breaks or a feature isn’t being developed as fast as you might expect.
Ricky: Another hat you wear is as one of the directors of the Python Software Foundation. You’ve been on the board for a year. How is it going so far? What goals did you set out with when you started, and how have they changed in the last year?
Dustin: It’s a bit ironic, actually. When I ran for the board in 2019 and lost, one of my goals was to diversify the funding of the PSF. At the time, the PSF derived an insane amount of its revenue—nearly 90 percent—from PyCon US.
It was something that gave me a bit of anxiety about the PSF’s ability to continue to operate, but I think most people didn’t really see this as an important issue at the time or weren’t even aware that the PSF had such a huge dependency on this single point of failure.
So when I ran again in 2020, with the same goal, and we were in the midst of a global pandemic and had just canceled the event that would have been our main source of revenue . . . I think it made more sense to folks. And obviously the PSF didn’t go bankrupt, but it’s not because I’m on the board now.
I think we got very lucky in a number of ways: that the PSF staff had been financially conservative in preparation for a catastrophic event like this, that most of our sponsors and attendees were generous enough to donate their ticket refunds that year, and that the staff was able to work really hard to produce a viable, desirable virtual event for this year’s conference.
My secondary goal was making larger investments in staff and infrastructure, specifically in hiring more specialized roles that help the PSF grow in ways that help future-proof it and help the PSF run and fund projects for the benefit of the community, like new PyPI features, improving docs, UX, accessibility, education, and so on. We’re seeing some of that happen now, with various PyPI improvement projects and the PSF filling some new roles like the director of resource development and a project manager for the packaging ecosystem.
And my final goal was basically “listen to what the community wants and advocate for that inside the PSF”—essentially my day job. This was a big wildcard statement and intentionally so, but fairly quickly after the election, we heard loud and clear that there were improvements that needed to be made, that the board could be more representative of the voting members, and that the membership could be more representative of the wider community.
So for the last year I’ve been working toward that: we’ve founded a new Diversity and Inclusion working group, we’ve proposed some bylaws changes for this upcoming election that add some limits to the director positions, and we’ve got even more coming down the line.
And it should go without saying that I’m not solely responsible for any of these changes. All of this is part of a larger effort by multiple people, but it’s part of my priorities as a director on the board and what I’m specifically focused on.
Ricky: You’re no stranger to Python conferences. Your 2020 PyCon talk had an easter egg that featured more than thirty different T-shirts from regional Python events, and you have also helped organize conferences like PyTexas. So I’m curious as to what your first PyCon was like. Do you have a favorite conference? And in your opinion, what makes a good Python conference?
Dustin: My first Python conference was PyCon 2015 in Montreal. I mostly remember being in awe of how large and friendly the community was. I also remember looking up at the giant projector screen in the plenary hall and seeing all the PSF sponsor logos and thinking, “Okay, these are the companies worth working for” :) My biggest regret is that I didn’t know there were conference T-shirts and never got one!
I’ve been lucky to be able to go to many, many conferences and probably have lost count at this point. Some of my favorite memories include a string quartet at PyCon Taiwan, giving a talk at PyGotham in the United Nations building, and poolside mariachi bands at PyLatam. But there are so many that I haven’t even been to yet that I’m hoping to attend someday, like PyCon Africa, PyCon India, and literally anything in South America!
One thing I’ve learned in the past year, when we’ve been limited to virtual events, is how much I’ve underestimated the importance of the social aspects and in-person relationships that happen at these conferences. I’ve been to some really good virtual conferences, and they’re sort of at a perpetual disadvantage compared to an in-person conference, where all that interaction just happens by default and we take it for granted. It’s really hard to make it happen online!
That said, there are many powerful benefits to virtual conferences as well. The audience can be much wider, and the conferences are far more accessible—no travel necessary, and the costs are generally lower as well. I hope we can still retain some of that once we return to in-person events.
I think there are a lot of features that make a Python conference feel like a Python conference, but in my experience, what makes a really good one is the sheer effort of the volunteers and/or staff that help produce it. I think folks who’ve attended PyCon US may not realize how long the staff has been working on the event (venues are booked multiple years in advance!) or how many unpaid volunteers it takes to deliver the conference and keep it low-cost.
Ricky: Now just a few last questions. What else do you get up to in your spare time? What other hobbies and interests do you have aside from Python and programming?
Dustin: In my spare time I volunteer for the PSF, contribute to some open source projects I care about, and help maintain things like PyPI :) Folks usually think those things are part of my day job, but they’re not.
When I’m able to find time outside of that, I’m usually cooking, tinkering in my garage or wood shop, playing music, out riding a bike, camping in the woods, or just hanging out with my dog.
Ricky: Thank you for joining me for this interview, Dustin. It was great to chat.
If you’d like to get in touch with Dustin about anything we talked about today, then you can contact him via Twitter.
If there’s someone in the Python community that you’d like me to interview, then leave a comment below or reach out to me on Twitter.
