It's where the proof is.
In this episode, we talk about creating beautiful data-driven essays with Michelle McGhee and Russell Goldenberg, Journalist-Engineers at The Pudding.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Julianna Tetreault is a published writer turned software engineer with an insatiable desire to learn. On any given day, you can find her putting her full-stack Ruby and Rails skills to work (if she's not traveling!) or head-down in a book.
Russell Goldenberg is a Scorpio. He makes stories with data and code at The Pudding. Nowadays coding mostly in Svelte.
Michelle McGhee makes visual stories at The Pudding. She also enjoys making delicious food and 3-pointers at pickup basketball.
[00:00:00] RG: I just love that one because it could have totally not worked at all, and it was just exciting to see that as it came in, it actually worked and like proved the concept.
[00:00:21] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem.
[00:00:29] JT: And I’m Julianna Tetreault, Software Engineer at Forem. And today, we’re talking about creating beautiful data-driven essays with Michelle McGhee and Russell Goldenberg, Journalist-Engineers at The Pudding. Thank you so much for being here.
[00:00:43] RG: Thanks for having us.
[00:00:44] MM: Yeah, thank you.
[00:00:45] BH: So before we get into the exciting world of journalist engineering or engineered journalism and dig into The Pudding itself, can we get to know a little bit about both of your career backgrounds? Michelle, can you start us off?
[00:01:00] MM: I studied computer science in college and undergrad and did various software engineering internships and sort of thought that’s what I was going to do. Although I always kind of felt like it was pretty interesting, but I had other interests as well that were sort of more creative and it didn’t really feel like a perfect fit. I worked at several tech companies after college, but learned a lot. Then I quit tech and swung all the way to working at a radio station and teaching storytelling classes. And then I found this kind of beautiful mashup of both of those sides of my interests in doing sort of visual graphic storytelling on the web.
[00:01:47] JT: And Russell, could you tell us a little bit about your background?
[00:01:52] RG: I also did computer science in undergrad, but it was also paired with visual arts. And I learned to program by way of processing alpha. So that kind of dates me a little bit, I suppose. And then I kind of did a meandering path to where I am now starting with doing some interactive documentary. My first foray into that was through a project called Hollow back in 2012, I believe. And then through that, I kind of got into data journalism and worked at The Boston Globe for a little while doing we call like news app development. And then after that, I joined Matt and Ilia at Polygraph as it was called at the time. And we turned that into what is now known as The Pudding.
[00:02:34] BH: Can we the first talk about just like what each of your jobs are at The Pudding before we get a little deeper?
[00:02:42] MM: So our jobs are kind of similar, but kind of wrestled just as more, but I’m a journalist-engineer, which means I produce these data-driven essays sort of from end to end from the idea apart to the research, to the data collection analysis, whatever’s necessary for the project, and then the front-end development is usually the last step. So I do all those things. Therefore, I am kind of a journalist, kind of an engineer, and my job involves both making essays like that from my own brain that I produce. But we also work with a lot of freelancers who pitch us ideas and maybe need assistance on the project in certain areas. And so I’ll also sort of partner with people like that and help them bring their ideas to life.
[00:03:40] BH: Since you mentioned front-end development there, what is that part of the journey like, like tools that The Pudding has this kind of touch on that? What does it take to get that final thing looking good? And do you redo a lot of stuff? Are there good abstractions, like libraries that the team uses? Maybe tap on that a little bit.
[00:04:01] RG: We kind of take an approach of rethinking each project from scratch, both from a creative and technical standpoint. We do have some scaffolding built in to get people up and running with different templates in terms of like our front-end workflows. So specifically, we have like a Svelte starter template. We’re big into Svelte on the team. So we do have some of those things in place, but pretty much every one of our projects is just a static deploy. So we really let anyone working on projects use any tools they want, whether that’s a tech stack or design tools or libraries, et cetera. It’s really flexible depending on the experience of the person creating the project and what the project needs.
[00:04:46] JT: I’m curious. How did The Pudding come to be what it is today and where does the name The Pudding come from? I need to know.
[00:04:56] RG: The Pudding started out as just a single person, Matt Daniels. It was actually just technically called Polygraph then and he was just doing some work for fun and for some clients. It started getting bigger than he could manage so he brought on Ilia and myself to kind of work on some of that stuff with him and then it turned into a more formal company, so to speak. And we separated out the two kinds of sides of the business, The Pudding, which is our editorial publication, where we just do everything in house. There’s no monetization of it. And then Polygraph, which is just more your typical studio where we’re doing work for hire. And the name, The Pudding, came about because we were trying to think of a new name to run with for this editorial publication. We’re looking to call it The Proof because we thought that was cool and related to proving things with data. And we found that that was going to be a conflict from a trademark standpoint. And then someone along the lines mentioned, “The proof is in the pudding.” And we jokingly started calling it The Pudding and it’s stuck.
[00:05:58] JT: I love it.
[00:05:59] BH: What drew each of you to this kind of work?
[00:06:02] MM: So like I mentioned before, I studied computer science, but also had sort of these other interests, specifically storytelling. And I was really into podcasts and making stories sort of in that medium and also teaching. And both of those things, the sort of storytelling and the teaching parts of me, were really attracted to this, when I discovered The Pudding and started reading their pieces, just thought it was so cool to use these technical skills towards an aim of explaining complex topics, bringing people into these things in like a different way, sort of through a story that’s like really engaging and interactive and all those things. So basically as soon as I saw The Pudding’s work, I felt like it was a big aha moment for how I could sort of combine those passions that I’d always seen as sort of very separate and not necessarily possible to combine.
[00:06:57] RG: So for me, what drew me to this type of work, I think it’s when I was still probably in undergraduate school. I was big into the creative coding scene. So like the likes of Aaron Koblin and Robert Hodgin, those types of computational artists. And as I started getting closer to needing to get a job, I was trying to figure out like, “What would be like a day job version of doing some of that code?” I was at OpenVis Conf and I saw a talk by Gabriel Florit, who is a graphics developer at the Boston Globe at the time, and I thought it was just really fascinating, the kind of intersection of kind of the art side of things, but also like the really serious data journalism side. And that was like a nice way to find something that was practical, but also still in the realm of creative coding.
[00:07:48] JT: So I would like to start talking about some of the work that you and your team has done here at The Pudding. So I think that The Pudding really took off, at least in my eyes, when your team created the AI tool that judges people’s taste in music from Spotify or Apple Music. And to this day, I distinctly remember logging on to Instagram and just seeing a flood of stories about how bad people’s taste in music was, which was really exciting for me because I’ve been a big fan of The Pudding for a while. And so naturally, I too had to use the tool and find out how bad my music was. And it was hilariously bad. Can you talk a little bit about how your team came up with this idea?
[00:08:41] RG: So this was a project by Matt Daniels and he really just wanted to do a Spotify wrapped ask project, but with like a different spin. And he experimented with like a few different approaches and ended up with this snarkier chat interface approach. And it was actually a really quick turnaround. I don’t think there was like a lot of iteration. It just kind of stuck and it obviously worked and resonated with a lot of people. And I feel like I would draw the parallel actually a bit to the Wordle phenomenon that’s been going on for the last couple of weeks because there’s like this nice combination of it’s easy to use, but also shareable in a way that you want to share something about yourself with other people, but it’s not like in this over-the-top intense way. So I think it just kind of found the right balance of personalization and shareability. I guess people like getting made fun of as well. That’s like another thing I took away from that.
[00:09:42] JT: I definitely got a kick out of it.
[00:09:45] BH: What went into making the Spotify critique tool in general? And is that kind of thing, just the whole different type of process then maybe some of the like visualization stuff I’m seeing on the Polygraph and stuff? It seemed like maybe different disciplines.
[00:10:08] MM: Well, I can’t speak too well to what went into making it because I didn’t make it and I wasn’t on the team when he made it. But I mean, Russell mentioned earlier that every project kind of starts from scratch and the goal is to serve the project with the way that you tell it. And I do think you’re right that our projects, they sometimes fall into these categories of like different vibes and different types and will often reference things like, “Oh, it’s kind of got the flavor of the book cover’s thing.” Or like, “Oh, it’s kind of like the Ali Wong piece,” or it’s that kind of thing. So I think that there are several buckets of sort of different types of things. So I would say the Spotify piece is, like I don’t think there’s a single chart in that piece. So that’s the thing that makes it different from some other ones. It’s highly interactive. You’re kind of doing this very interactive experience and it’s sort of satirical. So those big components, they make it different from other things, but we’ve done other things that are highly interactive. We’ve done other things that are more satirical. So every project kind of has its own flavor. I wouldn’t say like there’s all the regular projects and then there’s Spotify, but I do think you’re right that it’s unique in those ways. The work was probably mostly in like hooking up the Spotify stuff to work and then writing a bunch of funny, mean things, figuring out how you’re going to tell those to people. So there wasn’t necessarily like data analysis or things like that, and also probably the design of it. So those are probably the main focuses of that project, which is different from other ones.
[00:11:37] RG: It definitely fell into this category of personalization. We definitely have quite a few stories where we try to orient the story around the user in some way, whether that’s basing it off their location or if they give us some input around their age or something. We’ve done a lot of personalization-type stories. This one took it to another level because literally the whole story was crafted around your personal data, which is very much a risky thing to do because you have to handle all sorts of different edge cases, something that we haven’t done a lot of because there’s just like a lot more risks and then like, “Oh, is this person’s data actually going to be interesting when we put it through our process?” So I think that was probably the more unique part of that, and definitely most of the time, if I recall, was probably spent on actually hooking up the API and doing testing on all that stuff.
[00:12:32] JT: Could you both talk a little bit about some of what your favorite things you’ve created for The Pudding have been and what went into that creation?
[00:12:42] MM: I had this idea to look at representation in crossword puzzles, like, “Who is in the Crossword?” That’s the title of the piece, and looking at like how many women are in the crossword, how many people of color are in the crossroad over time, over different publications, which I was curious about because I had read all these pieces about sort of a growing movement of like making crossroads more inclusive and how they’ve historically have maybe catered to a specific like worldview or like set of things you’re expected to know. And the biggest part of that project was collecting the data. So I would say another bucket of putting stories is like handmade datasets, very like custom datasets that take kind of a long time to create and are serving a very specific question. So we looked at thousands of crossword puzzles and clues and tagged the ones that had people in them because that’s what we’re specifically measuring and then researched those people to find sort of demographic information about them. That took months, which was the hardest part. We had some people helping us out there too. So then once I did that, did some data exploration to see what’s interesting here, what exactly am I trying to say about this. I think I made some sort of outline maybe in Figma or maybe in Google Docs or something like that, and then went into developing it, which involved making some cross wordy looking charts and graphs and writing the piece start to finish, all of that, and that was kind of the process for that one.
[00:14:19] JT: Would you say that on average a typical story that has that amount of data will take a few months just for data collection alone? Like for the crackers one that you worked on, would that be the same sort of data collection and time commitment would you say?
[00:14:36] MM: Similarly, that was I think the longest portion of that project. I don’t remember how long that took us. Maybe a month.
[00:14:44] JT: Okay.
[00:14:44] MM: It was similarly sort of manual, we called people and stuff like that. But yeah. In my experience, when you’re collecting a dataset that requires a lot of manual research and there’s no way around that, that usually takes longer than you want it to.
[00:14:59] RG: So in the past few minutes, I’ve been reflecting on my favorites, which always change. And I think I would point to something that’s actually on the other end of the data spectrum, which is stories where I don’t have the data at the start and I rely on the user for the data. So I’ve done a couple of these what I call like experiments. Specifically, one I’m thinking about is “The Birthday Paradox Experiment”. And that was to explain the Birthday Paradox, the chance that two people in a room have the same birthday, this math phenomenon. And I did that by actually having real people into their birthdays and comparing it to the previous people that have visited the site. And so it’s just constantly running this experiment. And I just love that one because. It could have totally not worked at all, and it was just exciting to see that as the data came in, it actually worked and like proved the concept. So that one is definitely top of the list for me. And then another one in a similar vein was The Gyllenhaal Experiment, which was testing user’s ability to spell really difficult names and make these cool, sync-y diagrams out of it. And I just love the fact that I think it was like Matthew McConaughey. There were 400 different permutations of spelling his last name, which I was just like blown away by. And they were like more than one attempt. It wasn’t just like one person entering random stuff. It was like legitimate attempts. So that was my kind of favorite story, I think.
[00:16:41] BH: What’s the most challenging part of the work in general and then what are some of the most challenging things that have ever happened doing the work, even if it was just one-off like awful bug or some really difficult problems? So what’s challenging in general and then what really challenged you?
[00:17:00] MM: I feel like what’s challenging for me right now is the uncertainty in between having like an idea of something that could be cool and then a finished product or even like getting close to a finished product. When you’re like, “Oh yeah, this is going to be cool. This is going to work,” the space in between like ideas and, “Oh yeah, this is going to work,” that is challenging. I feel like there’s a lot of uncertainty there and the feeling of like, “Oh, I’m not sure if this is going to work, but I’m trying different things. I’m experimenting with different options. I’m getting feedback from people I’m seeing if it still feels interesting to me. I think that is a challenge, especially when you’re making things that can take a long time to make to get to sort of the final product. To collect the data, maybe you need to do weeks of work to even see if the idea you had is interesting. So like sitting in that uncertainty for me is challenging, but I’m working on it.
[00:17:54] RG: I think the biggest challenge for me is when you get to the story presentation layer, there is quite literally hundreds or thousands of different directions you could go in and it’s really hard to be like, “Oh, I’m going to go down this road and abandon all the other roads.” And you don’t want to have FOMO of your own possible choices and that it always sticks with you even until you’re done. So I think that’s the hardest part is like forcing yourself to decide to go down one path, knowing that you could’ve chosen another one.
[00:18:31] JT: Agreed. Well put, the FOMO.
[00:18:35] RG: Self-inflicted FOMO.
[00:18:36] JT: Yeah.
[00:18:38] RG: I wish I had a specific one. I feel like every project I’ve run into something that is like a very specific, weird little bug, I feel like something that’s a theme I’ve noticed is less like a specific bug and more of something that happens with every single time I’m doing some sort of data processing or analysis, which is you find some really strange little quirk about a dataset that you thought was going to be perfectly normal. And you’re like, “Oh, now I have to consider this little edge case.” Like I was thinking about the story about Wikipedia page views we did, I was like, “Well, we didn’t factor in this little thing because of this effect.” So there’s just always these really tiny little details that probably take up like 80% of the time when doing some of this data scraping or cleaning, and I feel like it happens without fail on every project, even the ones you think it’s going to be super straightforward.
[00:19:32] BH: Do you have a sense in doing that that you have to overcome the edge case or the problem and rethink it or like you’ve put a footnote in the project, like, “Hey, this didn’t get accounted”? Is there a no looking back point where you discover a problem too late, but it should still probably see the light of day?
[00:19:51] RG: Oh, for sure. It happens both ways. I’m dealing with a story right now. It’s about basketball data, which is usually my favorite to work with because it’s so “easy” because it’s just statistics about basketball players, but then you’re like, “Oh, well, this person set out the first year. So even though their team name was supposed to be this one, it actually says nothing.” And I am at the point now where I’m like, “I wish I thought about this beforehand, but now I’m just going to make a footnote.”
[00:20:18] BH: Yeah.
[00:20:19] RG: It depends on the topic. If it’s a more playful or less serious topic, then that’s okay. But if it’s something that’s really crucial on a more serious story, then we would double back and rethink the data.
[00:20:32] JT: So I’m curious about the editorial process that your team has. How do you all decide what stories to do and what stories go on the dreaded chopping block or maybe not so dreaded?
[00:20:48] MM: Well, I feel like the chopping block maybe isn’t dreaded because it’s just used very often. I feel like we are constantly kind of picking up or maybe putting down ideas and it doesn’t have to have a bad connotation to it, but some elements of our process. And then Russell can fill in if I forget any. On Mondays, we meet and we kind of discuss pitches that we’ve gotten that week. So people can email us and send in pitches for ideas and we’ll look at them. We’ll see if we think they’re strong or if someone on the team has a particular interest in helping that person make it happen. That’s where we get some ideas and kind of decide whether we feel like it’s good. We also weekly or another day have a meeting we call story time where people bring anything from like a thought they had in the shower to like a fully formed pitch with like data to kind of discuss and throw around. And I think the purpose of that, at least as it currently exists, is just to get a lot of eyes on the idea and get all the millions of directions that you’re going to be sad you can’t pursue that from all your friends’ opinions, which is usually really useful at a very early stage where you’re like, “I want to do something about like, Wordle.” I don’t know what. Let’s just talk about it for 15 minutes or something like that. That can be kind of a good idea generation process. And then if you’ve got an idea and you’re feeling good about it and you’ve explored it and you’ve kind of reached a point where you feel like you want to put some time into it, we kind of just decide you’re doing it and you carve out time to do it. And maybe it comes to a point you finish it and you actually decide, “Oh, I don’t want to publish this,” or, “I actually want to put this down,” I don’t know. At any point in the process, things can change, especially on The Pudding side because we’re just putting out things that we think are good and cool and no one’s like forcing us to. So there’s a lot of autonomy on whether you think your idea is good and you want to go work on it or maybe you want to put it down or maybe you want to work on something else.
[00:22:59] RG: Yeah. We’ve iterated a lot on process. We tried really formal things where you have to present something every so often and get sign-off or feedback from people on the team. We’ve also just said, “Go do what you want and tell us if you want to publish it or not.” And I think we found that the sweet spot is kind of in-between where people get to start working on things and we just lean into working in public as much as possible. So Michelle was playing around with an idea last week and she just like sent along her mock-up or her little prototype that she put together and we responded to it. And I think the more you get feedback at the start when you’re just thinking of the idea or doing data collection or even seeing if the data’s available, that gives you a strong sense of it’s something that has legs or it’s something that you should just abandon. And I think the funnel is we abandoned a lot of stuff in the first week of exploring it. And once you kind of get past that, it’s very seldom that I feel like we will put those out or not publish. I feel like if I put a number on it, once we get past that initial data exploration, maybe like 90-95% of the projects we end up publishing. And I think it does come down to just doing some due diligence at the start before being like fully committed. And that’s I feel like typically our approach.
[00:24:26] JT: So I want to talk about one of your team’s more recent projects. And I feel like this was less data collection and more AI driven. And it’s the New Yorker Caption Contest. And I was hoping you could speak a little bit about this project. I found the captions to be extremely entertaining. And I think Russell, you worked on that project. So yeah. Could you speak a little bit about that? And do either of you think that comedians will be replaced by computers anytime soon?
[00:25:03] RG: That was a very fun little project. We actually decided to work on that because, well, Matt and I, we’re like, “Let’s do something with AI and comedy.” And that was like the initial. We had like a whole bunch of different ideas and we ended up thinking to do something with the caption contest because we’re like, “Okay, let’s just start small. See if it’s even interesting.” Because just generating a single one-line caption is a lot lower of a bar than like writing a whole screenplay and doing that well. So that’s kind of how we ended up on the caption contest. And we ended up partnering with Pamela Mishkin who had previously done a piece with us a few months before love in AI, which was really an interesting approach to kind of co-writing with AI. And so she kind of joined us because she works at OpenAI. So she has a very intimate understanding of how that whole thing works. And it was intentionally set up to be this open-ended experiment where we just wanted to, I think after we decided to actually go ahead with that idea, we put something out the next week. We want it to start really small and see where it went. So there wasn’t a lot of planning. It was like, “Let’s just each week come with a new idea and see what happens.” And I think Matt actually did a lot more of the conceptual stuff, like how we’re going to interface with OpenAI. But I think it was fun because we got to have a few other people kind of bring us their ideas of how we could wield it. We got in touch with the former editor of the caption contest to talk through how jokes are evaluated and set up and structured. And it was just really fascinating to get some of that behind the scenes. I’m not optimistic, but it will be useful for comedy in the near future. I just think there’s so much about comedy that is situational, and I don’t know. I feel like I’m always so impressed by comedians and how smart and witty they are in putting together the right things at the right time with the right cadence. So I think it’s a good place as like a starting point or to be like a copilot, but I don’t see it just uniformly replacing comedy. That’s my take.
[00:27:42] BH: What are the most visually stunning things that you’ve ever produced as an organization, not necessarily you two as individuals?
[00:27:49] MM: One is a project by Matt Daniels, which we’re referencing often, of like human terrain map. I don’t remember what he called it exactly, but basically mapping population as mountains, basically. I think it’s very beautiful. It’s a very vast and epic feeling and a cool, very simple concept that is just very visual. You don’t even need words, basically. You can just get lost in exploring it, which I think is cool. And then another one that comes to mind for the word beautiful, Shirley Wu did a thing on Hamilton, sort of mapping all the themes and the characters and different lyrics and it’s really cool looking. At the beginning, there’s this big star and it’s a big galaxy of basically themes and concepts. And I thought she just made a very visually beautiful rendition of that data.
[00:28:47] RG: I’ll pick two on the Polygraph side for some parody. One is a physical installation we did with UMG. We got to create an up-to-date visualization of all their streaming music data. It’s an in-person installation in a couple of their lobbies and it’s just like on this massive screen and it kind of taps into some WebGL. And I think it’s just very pretty. It’s got like the flying pixels and a lot of flash. So that one’s very pretty and is music that goes along with it, which is always a nice enhancement to a visualization. And then another one on the Polygraph side I would bring up is a project we did it in collaboration with the Washington Post. It was on the George Floyd protests. And I thought it was just a really compelling, but unique way to do a timeline and it just integrated multimedia in a nice way. And it was just nice to bring something more, I guess, unique to a very serious topic like that. And I thought it just was really just a nice composition.
[00:29:54] BH: Yeah. When I was scrolling through some of the stuff on both sides, that one also stood out to me. That’s just like a fascinating webpage.
[00:30:03] JT: I really loved the spades essay. I thought that one was really beautiful and engaging.
[00:30:10] BH: Our listeners should definitely just go to these websites, kind of pluck out some of this. Maybe some of these will specifically get into the show notes, but there’s a lot here. You’re not going to be disappointed by kind of getting on some of these landing pages and just clicking around.
[00:30:22] RG: We only have 149 stories across five years. So you can go through all of them.
[00:30:29] BH: Any advice if I wanted to do my best effort personally in often web dev and data to be dangerous? What advice would you give me? Where should I get started with if I really want to do something like this effectively?
[00:30:46] MM: I think the top one I can think of would be to do something on something that you’re like really excited about, that you really like, and that you could spend months thinking about and feel very happy about that. I feel like that’s fun, especially if you’re learning and it’s going to be a longer process or you’re trying to figure things out. It’s nice if the subject matter is personally exciting and interesting. In terms of tools, if you want to make things that are very similar to what The Pudding makes, we use a lot of D3, which is a library, that you might need to learn some things about. Those are the first two that come to mind.
[00:31:25] RG: From like a story standpoint, tell someone what you’re trying to make. If you have to talk it out and explain it, you’d be surprised like how you explain it or what you emit or what the person asks about instead of you just thinking about it in your head. That really is a fantastic exercise for making it clear what you’re making and why. And then yeah, in the technical lines, I may go to our GitHub repo, github.com/the-pudding. We have two different flavors of starter templates, which we have a Svelte starter and not a Svelte starter, I guess, I’ll call it Vanilla.js. And we definitely have some reusable components in there, but that’s one thing. We have a GitHub repo of datasets of like, “Oh, let me just try to make a better version of your story about NBA stuff,” then there’s a dataset for you, and all the whole Makeover Monday thing is a community. So that’s a viable path. And yeah, I would definitely echo, if you want to do bespoke charts, D3. If you just want to make some simpler charts, there’s obviously lots of great libraries like DataWrapper and Flourish. You can start to do a lot of really interactive things that are super customizable. Those are my suggestions.
[00:32:40] MM: We have, on our website, there’s like a resources section where we have some how-to things. You can watch Russell code a whole project, start to finish, and stuff like that of sort of tutorials and blog posts on how to do similar stuff.
[00:32:56] JT: I’ve actually watched some of those videos of Russell coding in the past. You're an awesome resource.
[00:33:04] RG: It’s most of me just saying, “This is supposed to work. Why isn't it working?” I just stare at the screen for a few minutes.
[00:33:11] JT: Any final thoughts as we wrap up?
[00:33:14] RG: I would just encourage anyone that’s listening to this and thinks they have story ideas or likes to make stories. If you have like any hint of wanting to pitch us an idea to work on, do it. We respond to every single email pitch or give feedback. We love talking to people about story ideas. So don’t hesitate.
[00:33:35] MM: Echoing that, pudding.cool/pitch, head there today. We outline kind of what we’re looking for in a story and kind of give some pointers on how to make your pitch as awesome as possible. We’ll respond to you and we’d love to hear from you.
[00:33:51] JT: Thank you so much for joining us today, Michelle and Russell.
[00:33:55] RG: Thank you for having us.
[00:33:56] MM: Yeah. This was fun.
[00:34:06] BH: This show is produced and mixed by Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join us for our DevDiscuss Twitter chats every Tuesday at 9:00 PM US Eastern Time. Or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.