The Python Podcast.__init__

Share on social media:

[00:00:12] 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 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 200 gigabit private networking, scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new API, you've got everything you need to scale up.   And for your tasks that need fast computations, such as training machine learning models, they just launched dedicated CPU instances.   And they also have a new object storage service to make storing data for your apps even easier.  

Go to python podcast.com/linode,   that's l I n o d e, today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show.   Having all of your logs and event data in 1 place makes your life easier when something breaks, unless that something is your Elasticsearch cluster because it's storing too much data.   ChaosSearch frees you from having to worry about data retention, unexpected failures, and expanding operating costs.   They give you a fully managed service to search and analyze all of your logs from s 3 entirely under your control, all for half the cost of running your own Elasticsearch cluster or using a hosted platform.   Try it out for yourself at pythonpodcast.com/chaossearch,   and don't forget to thank them for supporting the show.  

And 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 even more opportunities to meet, listen, and learn from your peers, you don't want to miss out on this year's conference season.   We have partnered with organizations such as O'Reilly Media, Corinium Global Intelligence, Alexio, and Data Council.   Upcoming events include the data orchestration summit and Data Council in New York City.   Go to pythonpodcast.com/conferences   to learn more about these and other events, and take advantage of our partner discounts to save money when you register today.  

Your host as usual is Tobias Macy. And today, I'm interviewing Jonathan Biddle about his work to encourage and empower Wayfair engineers and their use of Python. So, Jonathan, can you start by introducing yourself? Sure. My name is Jonathan Biddle. I lead the team at Wayfair called developer acceleration.  

[00:02:28] Unknown:

You can think of our team as essentially trying to help other teams become more effective. So I I consider us a bit of a a meta team in that regard,   and a large part of that would be how we kind of drove a lot of Python adoption over the past,  

[00:02:41] Unknown:

I'd say about 2 and a half years at this point. And do you remember how you first got introduced to Python?  

[00:02:46] Unknown:

Yeah. Pretty clearly, actually. So,   I'm a bit of a I call my definitely call myself a self taught programmer, and the first part of my programming career was essentially taking over maintenance of some Perl scripts in,   for a newspaper company.   And I just taught myself that organically   for a while,   and eventually got introduced to Python by Zope who we were using for our,   data product called z4m. It was powering a bunch of our websites, and I started to get interest in Python about 2, 006   and then really, really got into it in 2007,   when I discovered Django, and I just fell in love with Python at that point. I think 1 of the things that stands out to me with Python is its emphasis on readability.  

And especially with Django, I could almost, like, intuit the API in a lot of cases. It it seems so easy to get into and guide you towards best practices.  

[00:03:35] Unknown:

And you mentioned that now you're working in the team to help other engineers and teams at Wayfair   discover and use Python for their particular projects. I'm wondering if you can start by describing a bit about the overall mission statement for you and your team at Wayfair and some of the origin story about how your group got started. Sure. Yeah. Definitely.   So, over  

[00:03:56] Unknown:

2   over 2, 000 of it Wayfair and growing.   If they're focused on actually delivering,   like, business value and focus on their their the the task at hand and not fighting   with, like, standing up logging or figuring out how to get a project running in production   or anything along those lines. We wanna get them, as quickly as possible onto, like, the meat of their problems   and and pave those roads.   So that's, like, really what we're trying to do is reduce friction and, get people adopting best practices to be really effective. And how we got into that is it's kind of interesting. It's a little happenstantial.   So maybe I should describe the scene at the time. This is a just shy of 3 years ago. Python had 12 apps running at Wayfair   and give or take.  

And it was getting to a point where those applications   really didn't have, like, a dedicated   team behind them. And I happen to be in the meeting. We were talking about this. And as we were describing, like, what this team would be, I at the time, I was leading a a a very Java centric team. I heard what they were asking for, and I'm like, oh my god. This sounds like my dream job to, like, figure out how to support and grow this Python ecosystem at Wayfair. So a friend of mine at the organization who came from, the same start up as me, we got together. We talked about, like, how we could actually do this, and, we we just got into it and had to figure out, like, how to create an actual, like, Python platform team from essentially absolutely nothing   and and try and grow adoption.  



[00:05:21] Unknown:

And you mentioned that at the time you first started, there were roughly 12 apps being built and maintained at Wayfair that were using Python. I'm wondering if you can characterize some of the different ways that it was being used   and some of the other primary languages that have been common throughout Wayfair.  

[00:05:37] Unknown:

So there's a lot of PHP at Wayfair.   There's also,   I'd say, Java, obviously, javascript.net,   and Python was a bit of an edge case at the time. It was used predominantly to productionize a data science model of some type. It   it came in, I believe, the the very first Python app at Wayfair was essentially   a way of serving a a data science model to   the ecommerce experience.   So you can imagine, like, you're in a PHP app on the front end, and then in behind the scenes, it's proxying that to a, a Python service. It goes a Flask a Flask service in the background.   So that was, like, how Python first came to the organization.  

It's grown quite a bit since then, since we started to, like, really,   make it easier and easier to use. But, yeah, at the beginning, it was really about serving, data science models,   to various types of systems.  

[00:06:27] Unknown:

And for   programs and projects that are   engineering focused at Wayfair,   what's involved in the overall selection process   selection process is? Is that something that is sort of designed by committee or is each team left to their own devices to figure out what works? Is there sort of an approved list of technologies that can be used? I'm just curious how that manifests at Wayfair specifically.  

[00:06:53] Unknown:

Yeah. So I'd say it it's a bit of some of those, maybe the latter 2.   Generally, teams have a fair degree of freedom to figure out what has the best fit to purpose. You know, we encourage everyone to be very pragmatic about that. Some languages have different, say,   characteristics and and strengths and and drawbacks.   Maybe really strong open source libraries that would be a good fit. But, really, we wanna trust teams to kinda use their best judgment, but we do have, like, a   kind of a list of technologies,   a bit of a tech radar, if you will, of things that are,   paved and and battle tested, and we know we're gonna, like, productionize fine. And we tend to, like, ask people to choose from that list, which, you know, ideally, that list is ever changing as we,   adapt new technologies and figure out,   you know, what is  

[00:07:41] Unknown:

something to lean more into or maybe lean away from. And then in terms of how you engage with the different groups and engineering teams throughout Wayfair, I'm wondering if you're focused primarily on greenfield projects, or do you also embed with existing product teams to figure out whether to   either incorporate Python for bits of tooling or to replace bits of their application? I'm just wondering if you can sort of   characterize some of the   decision factors that go into  

[00:08:09] Unknown:

who you work with and for what particular end goals. Yeah. Maybe actually, if it's helpful, maybe I can walk that back a little bit. The, so we we engage with teams in a in a variety of ways, which we got into a little happened substantially. So when we created when we first got the the platform team off the ground, we I you know, as all my Python experience   as it may be,   I actually hadn't worked on a Python team at the company before, so I didn't really know, like, what the the pain points were, what problems we actually needed to solve to be really effective.   So we had this idea of, like, well, what if we just spent a decent amount of time, you know, just working with teams on their projects?  

So you can imagine, like, 1 person on the back end trying to, like, smooth out points of friction and and 1 person going out and just, like, pairing with teams on, what their problems are, seeing where the friction is, and then bringing that knowledge back to the team while also maybe, like, giving someone some, you know, expertise on their project to learn from. And, so we ended up, like, leaning into that pretty hard. It worked really well,   and we developed a program out of it called auxiliary engineering.   So you can imagine   half of the platform team roughly,   spending   between like 2 3 quarters a year,   working with teams on projects as part of those teams. So   that's that's probably our largest investment,   where we we we we tend to spend a lot of times, like, planning that out, setting expectations, and those those engagements last about a quarter. And then we walk you can walk all the way back to light touch things such as,   ad hoc support, office hours where we encourage people to come up and and chat with us or just digging in with the team on a on a random question. The auxiliary engineering 1, though, in particular, we've   we've gotten a lot of value and mileage out of that, and it's become a pretty integral part of how we,   how we run our platform teams internally.  



[00:10:00] Unknown:

And are there any   analogous groups throughout Wayfair that are serving to support other technology stacks or languages, or is this something that's unique to Python?  

[00:10:10] Unknown:

Well, it used to be unique to Python.   It was something that was going well enough that they you know, it's we decided to apply the same exact model to other languages. So, I think about a year and a half, if I'm remembering this correctly, after starting Python platform, we spun up PHP platform, and we have been trying to build out largely the same type of, team and we're all at the same model in that ecosystem. And we're about, I think, just about a year into,  

[00:10:35] Unknown:

building out a similar ecosystem over there. And for the groups that you work with closely,   can you talk about some of the just overall day to day of how your team works with the other engineers   and some of the sort of of the length of a typical engagement and maybe some of the common points of friction or confusion that exist with people who are familiar with other languages trying to adopt Python? Yeah. Definitely. So maybe I should start by I'll just say here here's what the general life cycle of, 1 of these engagements looks like. We spend about a I think about  

[00:11:10] Unknown:

3 or 4 weeks trying to find a a good group to engage with. We we ask we ask teams to basically solicit us for 1 of these. So it's generally a team approaching us saying, hey. We'd like you to come and partner with us on this MVP or this or this critical project. They would do that because you essentially you as a team asking for that get a very experienced software engineer on your team to help you with a with a project, so that's very attractive. And we we tend to look at these in 3 dimensions,   business impact, technical impact, and team culture fit. So we're   essentially trying to hopefully get like a a little over what we can take on in terms of bandwidth and choose the 1 that is highest   leverage or or impact across those dimensions. Once we find that we do a, a round of expectation and goal setting where we just make sure that we're well aligned. We know what success looks like. We know what pitfalls we're gonna we wanna avoid. And then the engagement lasts about,   a quarter, give or take a few weeks. And during that time,   we we do weekly retros. We do a project retro at the end. It's pretty intense and and ambitious, and we're we're trying to bring a lot of change into the team while we're also trying to achieve these really ambitious business goals.  

And during that entire time, we're also learning a ton firsthand about our own platform.   My favorite example of this would be if you go and work with a team and they have a new engineer that just joined the company, maybe a junior engineer, they're seeing your your ecosystem for the first time. You see them struggle on something, and it's really hard to feel that pain, like, as maybe someone who's very familiar with Python or specifically Python at Wayfair.   You see that and you say that's an opportunity for improvement. We make sure that Auxiliary engineers have, like, 20%   time to just jump on those things without having to go through any process. And, you know, if you fix it that week and you get back to the person and say, hey. So you struggle with this, with the with this maybe documentation or automation of help that   feels great. And that person sees that, you know, hey. I you know, being vocal and just like sharing my,   the pains I'm going through with the team   led to actual meaningful change very quickly.  

In terms of failure modes that we try to avoid,   or where we've seen where we struggled,   the   there's really, I think of, like, 3 projects that come to mind.   1 was more or less on us. We, we undersized pretty significantly the the challenge of migrating something from 2 to 3,   and   we still had a really big impact. It was just that that process took up a lot more time than we thought it would mainly because there was a lot of dependencies that also had to be brought over in that migration to get over the finish line.   And the other 2 challenges we've faced were largely, I would say, externalities.  

1 team lost a few key sponsors on their side of things right after the project got off. And the other 1, the engineers that was supposed to work with us on the project had to stay on a previous project because it was having some issues getting over the finish line and, you know, you wouldn't wanna sabotage that project to to just to get the new 1 up and running. That probably wouldn't be the right thing to do. So   some of those are we we have lessons learned in general. The the main takeaway we've had is if we do see an issue with being able to engage the team effectively and and some of the failure modes hit the surface, we wanna be pretty aggressive about calling it early on to the engagement. So because at the end of the day, our team isn't super large. It's, I think it's like 5 or 6 people. So   you wanna be very thoughtful about where you're where you're spending your time. And if you don't have that full buy in from the team, you you know, calling it early generally is the right thing to do.  



[00:14:43] Unknown:

And in terms   of identifying people who would be strong candidates to work in your team to help   proselytize   and and educate people on proper uses of Python and how to engineer it appropriately.   What's the sort of selection criteria for figuring out if they would be a good fit   and some of the overall skill set, either technical or otherwise, that you found to be most effective? Yeah. Definitely. So  

[00:15:10] Unknown:

it's   I would say it's a it's a pretty interesting team to be a part of.   We deal with a lot of ambiguity. It's a lot oftentimes not as clear cut as, you   know, make this change to hopefully make, you know, the product more effective. Sometimes you really have to figure out where the points of friction is or the ambiguity in your own platform.   So we like people who, like, are are feeling really comfortable just figuring it figure out that that,   ambiguity space and and are okay navigating it.   Also, we found that it's it's,   like, obviously, someone that enjoys   helping someone else either through education or training or pairing to become more effective because we are a meta team, like, people who really feel a sense of reward   and seeing others become more effective and successful, that that tends to   pair really well with with these types of with our platform team and these types of engagements in general.  

I'd say our team generally skews pretty senior as a whole, and   we,   we we try to attract the best Python engineers in the organization to this team so that we can figure out how to,   replicate their knowledge as effectively as possible across the entire organization.  

[00:16:25] Unknown:

And then within your team, I'm wondering if you have found that there are some either useful   training materials   or sort of project scaffolds that you can use to   hit the ground running when you're working with other groups or,   useful tools or libraries that you've been able to leverage either within projects that are helpful for you internally to  

[00:16:49] Unknown:

have sort of reusable patterns or tools that have been particularly helpful for some of the other teams that you've worked with? So that's that's I'm glad you asked that because this is this is 1 of those funny stories where very early on, we had this,   example project that we had written for, like, hey. Here's how you can structure Flask and, you know, use blueprints and,   get the get the best, like, project structure versus, like, maybe, you know, throwing everything into a couple files unstructured, like,   you know, which is almost like, I think, by default, if someone's coming into Flask, they they tended to create, like, these,   like,   what would you say, monolithic files that just had everything in it. That's what we were seeing, some of. So as we as we helped give some guidance there, we then realized, well, people are, like, copying and copying this template or not template, but example project. They're just, like, replacing their own stuff in it. The cookiecutter is an awesome framework for this. Why don't we just build some cookie cutter project templates for people to use?  

And at the same time, we were thinking, oh, everyone has to figure out logging and metrics. Why don't we write some libraries   and write them really well so they're extremely intuitive to use? We'll call those, like, core libraries and   that'll mean like, oh, if you're creating your project, like, here's a logging library. It just make solves it all for you. You can get up and running, and, you know, logging is kind of just good to go, same with metrics,   and a few others.   So the combination of those 2 ended up incredibly   powerful. Teams are just like clone a cookie cutter project and, you know, as we spin up Docker or whatever it was that we started to add into the the the template, like, they just get all that for free and that cut through so much boilerplate for the teams that,   they really became a core strategy for the platform where we're also building that up in other ecosystems now as well, just like core libraries plus a cookie cutter template.  

And and I think it, like, you can really see the mark that it left on the organization because generally, if you walk around and you ask someone about project templates, they get called cookie cutters just because that's the framework that we happen to use. And I think not a lot of people realize that that was the name of the framework versus, like, what we were just calling the project templates. So cookiecutter is quite a quite a well used   templating system at Wayfair these  

[00:19:05] Unknown:

days. Yeah. So it's, it's got the Band Aid problem where the brand name has become synonymous with the actual technology. Exactly.   And then as far as   some of the   particular types of projects that you've been engaged with, I'm wondering if there are any sort of common patterns or categories of things that you have found that other teams have been asking for help with or if it's sort of all across the map and just some of the interesting or   unexpected types of projects that you've been engaged with there? There's there's really been a lot.  

[00:19:38] Unknown:

We don't we typically,   don't use Python, like, in in in the the customer facing experience, like the the ecommerce experience. That's that's very much like a a very massive PHP application.   But behind the scenes, it's used all over the place. And oftentimes, what you'll you'll end up seeing is a team is maybe a seen another team be really effective, say, standing up a,   a a a Python application to consume and leverage like Kafka queues, for example, and,   they see that go really well. And they are   they're interested in that,   but they might not have the existing experience on the team to just like go and take it on themselves. So that's 1 thing that we've definitely supported a lot where   there seems to be like Python is a great use for this problem,   but we don't have people today who really understand the language. It it'd be awesome to have someone come from the platform team and just, like, partner with us for a quarter to get up to speed.  

I think a lot of our big success stories look something like that.  

[00:20:42] Unknown:

And then you mentioned that at this point, you're up around 5 or 6 engineers. When you started, it was yourself and 1 other individual. So I'm wondering how the overall scale and scope of your work has changed and some of the   evolution   of your stated mission and some of the ways that you're trying to make yourself known within the organization so that people are even aware that you exist as a resource for them? Yeah. Yes. We actually got started with 3 people  

[00:21:10] Unknown:

and,   early on, it was very much like, you can imagine you inherit this platform that's kind of been   more or   less built out over,   volunteer time from other teams. And   we we pretty much start in, like   like,   behind the curve   underwater   stage.   And we had to figure out how to, you know, put out some existing fires, but also looking at, like, what do we what do we think this platform can be in the future.   So right out the gate, what we did was we we lean it to, like, 20% time. So every Friday was pretty much like self directed, forward looking. So no matter more or less how underwater we felt like we were, we were at least carving out a day a week to to really look at the future.   And then we tried to strike a balance between,   I would say, you know, just just kinda like pushing the platform forward   and making sure, like, what we're doing is actually providing values to teams.  

And it it feel like for   about a   a year or so,   it was a lot of iteration on that.   We we started to grow the team.   We had another person join who helped us get   the Auxiliary Engineering program off the ground, really, where we started to, like, form, formalize it.   And   it felt like   the the value we're providing teams and and the leverage we were giving them was started to become more and more recognized. And within a year and a half, actually, like, the team had developed a brand. You saw, like, auxiliary engineering become something that not just engineers are talking about, but product people were talking about because they're like, wow. You know, this this platform team came over with our and they work with our team and I suddenly, like, saw a lot of really strong outcomes. They were moving so fast and and some of it was because we were bringing expertise, but also being close to infrastructure, we could help them cut straight through,   maybe some of the stuff that might be confusing if the first time you have to interact with it. And today,   I would say it's it's actually a pretty   integral part of,   Wayfair's technical strategy is to figure out how to how to grow this platform   focused effort in a way that really, really maximizes   how much time engineers spend on delivering,   you know, or focusing on their their core projects and minimizing how much time they spend on   toil,   to to to use a word,   and and things that are ultimately, like,   not directly related but generally are, like, have to be done.  

Again, like, maybe standing up or figuring out how to, like, get, like, the logging stuff integrated.   We just wanna keep people focused on the the the real the meat of our problems. And I think that's, at this point, just really widely recognized and the the the branding and marketing side of it internally   is, like I I felt like we've kinda grown past that being an issue at this point.  

[00:23:55] Unknown:

And then for the teams that you're working with,   particularly those who don't have any in house   using Python. I'm wondering what you have found to be some of the common stumbling blocks or points of confusion or pain points that they've encountered while trying to adopt Python   and,   build things with it or incorporate it into their exist existing infrastructure and products? Yeah. Totally.  

[00:24:19] Unknown:

I think   Python has a pretty good testing culture these days, and I I actually didn't recognize this   until I had a chance to compare it. But,   you know, I've I was kind of 1 of those 1 of those Python engineers that really lagged in in in kind of, like, looking at, type annotations and, you know, kind of embracing them. So I'm like really I I kinda stuck it out for, like, no. I like my my dynamic systems. And,   and what I didn't realize is that I was relying on very strong test suites to give me some of the same assurances that, you know, like a static retyped compiled language would give you. So   when people are coming from, like, Java or dot net or a similar language, they, you know, they've kind of squint at Python a little bit and go like,   well, like, what do you yeah. There's a there I think we've all been engaged in this conversation before, but getting them to understand, like, yeah. Right. You know, you Python has type annotations now. You can you can or should lean into those in in my opinion,   But your test suite is also like, Python has an amazing set of tools for for writing some really, really, like, high value tests, Not not tests that just give you, like,   an uptick in your coverage, but actually, like, hopefully break at some point and save your butt at some point.  

So that's 1 that we we really try to, like like, help people figure out. Code review is just a pure, you know, has nothing to do with Python, but we've noticed, like, spreading some code review best practices is a pretty big lift for teams.   We tend to advocate that, like, code review should like like, if you if you have good linting pipelines, like, you pull style feedback out of code reviews.   If you,   treat code reviews as, like, really urgent, like even more important than writing your own work, then, like, you don't have things getting bottlenecked in code review and and, like, teams are generally amazed at how fast they start to move once they remove that bottleneck.   And I would say   1 1 thing I'd shout out,   to,   Jack,   Diederich is the his stop running classes   talk. That's that's 1 of my personal favorite Python talks. It changed the way I write Python.  

When I first saw it, people, again, coming from, like, a, like, a very Java like language tend to wanna, like, put 1   1 class in 1 file.   And,   you know, if you if you watch that talk, you know, getting teams to think about Python as, like, well, you don't actually need to use a lot of classes. You know, your files are there to help you organize things, not necessarily   using the same way that you see in Java.   Bringing some of those changes,   into the team tends to,   be a contributing point, but 1 that, like, once you get someone to to really see the value of, like, concise code that's very easy to read and contribute to,   it generally takes.  



[00:27:06] Unknown:

And then in terms of the projects that you have   worked on and,   built up, what are some of the notable successes, and what are some of the cases that you've run into where you ended up having to abort the engagement   because of either   issues at the technical level or organizational pushback   or just a poor team fit?  

[00:27:29] Unknown:

Yeah. We've we've had an quite a few wins. We I think that they're certainly done somewhere between 12 or 15 of these engagements.   A number of them have exceeded even exceeded the goals of the engagement, and we were into, like,   stretch goals by the end.   We've worked on systems ranging from,   computer vision,   our our pricing systems,   finance.   We have a lot of our search tech is Python, and we've worked in that space.   You know, there's a there's a pretty interesting problem around, like, how you actually move products,   to customers' houses, and we've we've worked with that. We've recently even,   built out systems that are part of a pretty critical workflow. The the order processing pipeline that actually takes a completed order and,   does all the necessary things with it. So we've we've worked with quite a few. I would say there there's there's actually only been 1 engagement where we   ended early,   and that was that was 1 where, ultimately, like, the the team that was we were supposed to pair with, wasn't,   they they were stuck working on a different project and weren't able to,   to engage.  

And if you wanna think about the priorities of these engagements,   we we explicitly set them as priority number 1 is,   transform the team in some way. So   make them more comfortable working with Python as a technology   or some you imagine, like, some type of behavioral change that we wanna stick past the engagement.   That for us is priority number 1. Priority number 2 is actually, like, effectively,   hitting the project goals. And that's very explicitly order them in that way because if, like, if the if the auxiliary engineer is just taking on all the hard work themselves, that's actually not, like, for us, that's a failure. That's not gonna actually have a lasting impact on the team,   the way we would want. So we we may in this case, like, we it's it's important that we kinda, like, pull the rip cord because we're ultimately not able to hit number 1 if no one's there working with us on the project.  



[00:29:29] Unknown:

Another thing I'm wondering about   is if there have been any common patterns as far as the   groupings of languages that the teams you're working with have been familiar with, and if you have seen any patterns as far as   language camps that have refrained from working with you because they're happy enough with their own feature set and they don't feel the need to explore Python? It's a really interesting question. I haven't I don't think I've actually thought about that before.  

[00:29:56] Unknown:

I don't I I think we see a pretty broad mix.   I think   maybe,   you know, if I had to it's really hard because at the end of the day,   PHP is a very prevalent language at the organization. So we do see a fairly large   number of PHP apps who are like maybe switching to Python for something, but that's that might actually be proportional to how much PHP is used.   So I don't think I have a great answer there, but I I do think it's a general mix. And we haven't actually at least not to the point where we've said, oh, people who are using  

[00:30:28] Unknown:

.net refused to write Python. Not nothing like that has really stood out at any point for us. Another thing that I'm curious about is because of the fact that you're working with people who are familiar with all these other different languages, if there are any design patterns or   lessons that you have brought back into your work in Python and your teams work in Python as a result of working with those other teams and some of the ways that they approach technology   and, system and software design?  

[00:30:56] Unknown:

Yeah. I think   so from a   software and system design perspective,   nothing jumps out. I that doesn't mean that that hasn't happened, but it, nothing's just coming to mind off,   at the moment. But I definitely say we it is a bidirectional,   knowledge share when we're engaged with the team. We we learn a ton from the teams, especially around our own platform,   And I'm sure we, you know, we we consider it,   a goal to absorb best practices from teams. We don't view ourselves as essentially coming into the team as, you know, some elitists.   It's actually there's some attention behind why we call auxiliary engineering,   and avoid some of the names that   tend to imply   supremacy   even if, implicitly.  

So, yeah, we're definitely looking for like what we can learn, what we can learn from our platform and then how we can spread those best practices to maybe the next engagement or to ourselves.   And I know that's happened   quite a   bit.   The ones that come to mind are largely around,   you know, we we've identified some, you know, some rough patches that we weren't really fully aware of where, let's say we work with a team and they're like, oh, wow. You know, get it getting up and running with this 1 particular thing was a lot more difficult than we would have hoped and we hear that in a retro.   And we really encourage that type of feedback because,   it's impossible for us to see it for the first time. And so when someone tells us that, we can, like, say, oh, great feedback, and then we can prioritize   smoothing that out. And and we definitely,   that becomes a huge factor in how we set our own priorities and goals.  



[00:32:33] Unknown:

And so given the fact that you have been using and working on building with Python and encouraging the use of Python at Wayfair for a few years now, I'm curious   how changes in the language and ecosystem of Python   have changed the way that you approach it as a team and also how the overall usage of Python at Wayfair has evolved over that same time period?  

[00:32:56] Unknown:

So I think when we first got started,   you know, there was just those handful   of applications   that, you know, we were supporting. They were the they were the 12 or so.   And   1 of the things that we leaned in on very early was Dockerize, like, Docker called Dockerize development environments and Dockerize CI pipelines. The applications themselves ran on a VM in production,   but we we wanted to make it easy for people to develop locally, and and we decided, like, Docker was 1 of the best ways to make that development environment fairly reproducible and easy to engage with. That actually positioned us really well to adopt Kubernetes early on as we started to explore that, and Python was the first,   language   to,   get into Kubernetes. And,   from when we started that to today, we went from being the first to having, over a 115   Python services running in Kubernetes.  

And,   so I'd say, like, we've seen the ecosystem grow tremendously.   I don't remember how many people were in the Python help channel when we got started, but I remember looking at this just the other week, and it was, I think, over 500   people   interested in that channel. And that's a channel used for, like, asking other teams that are using Python help questions in general,   just getting, like, kinda   cross team guidance or opinions on things.   So we've seen quite a bit of growth. It's it's been really exciting personally.  

[00:34:16] Unknown:

For any other organizations   or companies or groups who are interested   in building a similar type of team or   organization   to encourage the use of Python and educate other engineers, what are some of the lessons that you have learned in the process or   tactics that you found to be particularly useful or helpful or any other advice that you might give?  

[00:34:38] Unknown:

Yeah. Totally. This is a great question,   because in retrospect, there was a lot of pitfalls that we tried to avoid that I think could, like, sabotage a team's effort as I try and navigate this.   First of all, I think I I get the impression that there's a lot of companies that have probably had some Python leak into their ecosystem just because of the   the the data science,   traction that Python has. And, like, at some point, you have to, like, figure out how to productionize that. Python becomes, like, maybe a a pretty easy path to go down.   So, like, I'm I'm willing to bet there's a lot of organizations that, like, already have a little bit of Python and similar to Wayfair a few years ago, they figured out, okay. What do we do with this? How do we how do we do this properly?  

I would say this would be by guidance.   Every ecosystem is gonna be different.   And what you wanna do is,   in my opinion,   don't sit on the sidelines and try and think of what the perfect solution would be. Go and just work with the teams firsthand and see where they're struggling.   Take that to heart and try and make that easy.   Figure out how you,   like,   build some advocates both on the engineering but also on the product side when they see, like, Python   being used,   you know, to maximize its strengths, which I would argue if someone were to ask me personally, like, why use Python?   I I think Python has this great story of being,   like sure. It might not be the most performant language and languages view a straight up benchmark, but   Python is so fast to get up and running and iterate on. If you're if, like, speed to market is at all a concern, I think Python becomes an extremely strong option.  

In fact, if someone asked me very personally,   I generally say that, like, someone someone has to convince me why not to use Python because it's just so such a good general purpose language, and there are plenty of use cases where it's probably not a good fit. But I wanna see that case made before I personally would jump for it. Granted, I'm biased. I've been, you know,   playing with Python since 2, 006 or so,   but it's a,   it's such a strong language. I I think there's a lot of organizations that will find that very, very appealing. And my final advice would be   make sure you,   view the team as never a dependency or gatekeeping team. You're there to pave roads and help other people figure out how to become more effective.  

In fact, if you become a dependency at any point,   there's a serious risk that you will become swarmed with that   that type of activity, and you actually become incapable of moving forward in the platform. Let's say if,   if you   had everyone come through you before they, like, went out to production or something like that. Like, that backlog could build up really fast potentially, and now you're spending all your time doing those activities instead of actually   automating and and innovating on things.  

[00:37:28] Unknown:

And are there any other aspects of your work on the auxiliary engineering team or your experiences   of helping other groups within Wayfair   learn and use Python that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:37:42] Unknown:

Yeah. So there's I would say there's 1 1 thing that we did that was pretty cool early on.   You can imagine a world where you have dozens and dozens of teams all with maybe a couple of people doing something with Python.   And   early on, we felt it was really important to bring all those teams together, all those people using Python at Wayfair together, and kinda build a sense of community.   I think Python in general, at least if someone's involved in the in the the Python community, it tends to tends to be very welcoming and supportive. And I and I find that that,   that trait also   leaks onto the the people who use Python at work.  

But what we did is we we created an opportunity for teams to just come together and share what they were   working on in Python, and then we gave out a bunch of mugs that were cobranded with, like, a Python logo and a Wayfair logo. A little gimmicky, but, you'd be really surprised, I think, how the those mugs became a pretty sought after item where people would kind of, like,   see it on your desk and know that, like, oh, someone's doing something in Python, and then you go and talk to them. So there's I think there's a lot of times opportunities to build that community,   especially if something is,   really dispersed,   you know, in usage throughout the organization   and and not like there's a, like, a center of excellence already for it. So thinking a little outside the box about stuff like that, I think it matters, and it really helps.  

So we saw it become really successful. We actually saw at 1 point someone, like, trying to figure out where the mugs came from and offering to, like, buy someone for buy it for $10. And   and we just had a rule of, like, if you want a mug, just come to talk to us, and we'll give you 1.   But, yeah, definitely, like, try to find a way to build a sense of community. We did that. It it seems to have really paid a lot of dividends for us, and I and I'm going to let the same sort of play out in pretty much any organization.  

[00:39:27] Unknown:

Alright. Well, for anybody who wants to get in touch with you or follow along with the work that 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.   And this week, I'm going to share a podcast that was started by a listener of this show who contacted me to say that,   through listening to the episodes, it motivated him to start his own thing. So it's a show about learning Bayesian statistics.   So I'll add a link to that to the show notes for anybody who wants to check that out. And with that, I'll pass it to you, Jonathan. Do you have any picks this week?  

[00:39:58] Unknown:

Sure.   I'll throw out 2 that I that that we really like. I'll I'll bucket 2 the first 1 together, which is, like, Pydantic and FastAPI. We really like those.   We have a lot of Flask apps right now, and and for a number of them, I feel like Pydantic and FastAPI might be a bit of an upgrade. So we're trying to,   lean into those and make those a little   easier to adopt internally.   And so far, I I personally really like,   that,   those frameworks. And I I think they they seem like they have some pretty bright features. The other 1 that I would throw out there is MK Docs. If,   anyone hasn't checked it out, we,   you know, personally, it's it's been my favorite,   framework for getting documentation up and running, especially with, like, some of the some of the themes that are out there. Like, we use material a lot. We we made that easy to use, and we found that teams just started, like, gravitating towards it like wildfire because it makes it so easy to get some really, really attractive looking documentation up and running quickly.  



[00:40:59] Unknown:

Alright. Well, thank you very much for taking the time today to join me and share your experiences   of working on the auxiliary engineering team at Wayfair and helping other groups throughout learn and, take advantage of Python. So I appreciate your efforts on that front, and I hope you enjoy the rest of your day. Thanks, Tobias. Thanks for having me. This was awesome.   Thank you for listening. Don't forget to check out our other show, the Data Engineering podcast at dataengineeringpodcast.com   for the latest on modern data management.   And visit the site of python podcast dotcom 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@podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.