NerdOut@Spotify

We’ve seen generative AI and large language models do some amazing things in the past year — but how do you go from a tech demo to a real shipping product? In this Release Notes episode of the NerdOut@Spotify podcast, we’ll hear about what it took to ship our Voice Translation pilot, which takes podcasts recorded in English and uses AI to generate the original podcaster’s voice speaking in Spanish (with German and French coming next). Host Dave Zolotusky talks with senior machine learning engineering manager Sandeep Ghael about how we brought expertise from across the company in order to go from a weekend prototype to releasing fully translated episodes of Lex Fridman, Armchair Expert, and other podcasts — in just six weeks. Read more about Voice Translation for podcasts: Spotify’s AI Voice Translation Pilot Means Your Favorite Podcasters Might Be Heard in Your Native Language Hear the results on Spotify: Lex Fridman Podcast — “Interview with Yuval Noah Harari” Armchair Expert — “Kristen Bell, by the grace of god, returns” The Diary of a CEO with Steven Bartlett — “Interview with Dr. Mindy Pelz” More episodes on the Voice Translation Hub Read what else we’re nerding out about on the Spotify Engineering Blog: engineering.atspotify.com You should follow us on Twitter @SpotifyEng and on LinkedIn!

How do you get a machine to find a song that’s similar to another song? What properties of the song should it look for? And then does it just compare each track to every other track, one by one, until it finds the closest match? When you have a catalog of 100 million different music tracks, like we do at Spotify, that would take a long time. So, for these kinds of problems, we use a technique known as nearest neighbor search (NNS). This past summer at Spotify, we built a new library for nearest neighbor search: It’s called Voyager — and we open sourced it. Host and principal engineer Dave Zolotusky talks with Peter Sobot and Mark Koh, two of the machine learning engineers who developed Voyager. They discuss using nearest neighbor search for recommendations and personalization, how to go from searching for vectors in a 2D space to searching for them in a space with thousands of dimensions, the relative funkiness and danceability of Mozart and Bach, how to find a place on a map when you don’t have the exact coordinates, tricky acronyms (Annoy: “Approximate Nearest Neighbor Oh Yeah”) and initialisms (HNSW: “Hierarchical Navigable Small World”), why we stopped using our old NNS library, why we open sourced the new one, how it works for use cases beyond music (like LLMs), and looking for ducks in grass. Learn more about Spotify Voyager: About Voyager Voyager on GitHub Voyager documentation for Python Voyager documentation for Java Read what else we’re nerding out about on the Spotify Engineering Blog: engineering.atspotify.comYou should follow us on Twitter @SpotifyEng and on LinkedIn!

Last episode, we talked about ABBA, our first A/B testing tool. We used it to test UI changes, new features, content recommendations — anything and everything we could think of. ABBA was so good and worked so well for so long…that we decided to get rid of it. Years of using ABBA taught us what makes for good experimentation, and we eventually realized we needed a better tool, built from scratch. Listen to find out why we pulled the plug on ABBA and how Spotify’s Experimentation Platform was born. And in case you missed it, a version of our internal platform will be available to the public as Confidence, a new enterprise product for developer teams — read today’s announcement: “Coming Soon: Confidence — An Experimentation Platform from Spotify”. But first, let’s talk buttons. Everyone always has so many questions about buttons. How do you know which color they should be? Or how big they should be? Or whether the corners should be round or square? The easy answer: an A/B test! But if only all product experimentation was as simple as testing buttons. Senior staff engineer Mark Grey returns to talk with host Dave Zolotusky, along with senior engineer Dima Kunin — he helped build Spotify’s Experimentation Platform and was the guy who had the honor of finally retiring ABBA. They discuss the ins and outs of enabling experimentation at scale, including targeting criteria, controlling eligibility, the importance of measuring exposure, using properties instead of feature flags, the advantages of separating your app configuration from your experiments, fallback states, sample ratio mismatches — and all the other questions you have to answer about your experimentation process before you can even ask something as simple as “what color should a button be” — let alone “will this machine learning model consistently provide recommendations users appreciate over the next year”. Plus, did you definitely, positively, absolutely eat the bread? Or did you just buy the bread? And a bonus trick question: What’s the difference between “treatments”, “variants”, and “groups” — and why is it always so hard to name things? Learn more about ABBA and its successor, Spotify’s Experimentation Platform: 20: The Rise and Fall of ABBA: Listen to our previous episode with Mark Grey talking about our very first A/B testing tool, ABBA. Spotify’s New Experimentation Platform (Part 1): How we went from ABBA to building EP, the internal experimentation platform we use today and that Confidence is based on. Spotify’s New Experimentation Platform (Part 2): More features of EP, including our custom “salt machine” and more. Plus, find out lots more about how we do experimentation at Spotify on our engineering blog — including a little light reading on automated salting and bucket reuse, choosing sequential testing frameworks, comparing quantiles at scale, and how we scale other scientific best practices across the org. Read what else we’re nerding out about on the Spotify Engineering Blog: engineering.atspotify.com You should follow us on Twitter @SpotifyEng and on LinkedIn!

We’re often focused on features that improve the experience for users — letting them do something better, faster, smarter. But if you don’t consider accessibility issues, many users won’t be able to use the feature at all. From color contrast and text size to alt text for enabling screen readers and voice commands, accessibility issues can affect everyone, whether you have a permanent disability or just an armful of groceries. So how do you get developers and designers to adopt an accessibility mindset and make it a fundamental part of the development process? Host Dave Zolotusky talks with Dani Devesa Derksen-Staats, an iOS engineer on Spotify’s accessibility team. We’ll hear how Dani went from a five-year computer science program, where accessibility wasn’t mentioned even once, to becoming so passionate about the topic, he wrote a book on it. They also talk about the basic things we forget to consider when we don’t consider accessibility; how we can all benefit from accessibility improvements, whether that’s getting up a curb in a wheelchair or while pushing a stroller; and ways to address accessibility issues into the development process, from adopting a multimodal approach to UX design to integrating accessibility tests into your CI/CD. Spotify recently introduced an Accessibility Center. Have questions or concerns about accessibility? Contact us: Email: accessibility@spotify.com Write to us at: Spotify USA Inc., 150 Greenwich Street, Floor 62, New York, NY 10007, USA More on accessibility from Dani: His book: Developing Accessible iOS Apps (GitHub) His 2023 talk for Accessibility NYC: Creating Accessible iOS Apps: An Action Plan His 2022 talk at NSSpain X: 365 Days of Accessibility Read what else we’re nerding out about on the Spotify Engineering Blog: engineering.atspotify.com You should follow us on Twitter @SpotifyEng and on LinkedIn!

What happens when the standard tooling for iOS and Android just doesn't cut it anymore? What’s it like to maintain an app when there are literally thousands of commits every week? How do you develop your feature without worrying about everybody else’s feature, when at the end of the day, you’re shipping a single, massive app? In other words, what’s it really like to build apps at Spotify’s scale? Host Dave Zolotusky talks with Patrick Balestra, a staff engineer on our client platform team, whose job is to make sure every Spotify developer has a great experience building, no matter what Spotify app they’re building for. They talk about adopting Bazel, reducing local build times with remote caching, managing multiple monorepos and zillions of dependencies, doing big tech migrations (Objective-C to Swift, Java to Kotlin) without slowing down, open sourcing our tools, and contributing to the Mobile Native Foundation. Learn more about how we build mobile apps at Spotify: Kodeco: Building with Bazel: Online tutorial made in collaboration with Spotify BazelCon 2022: Our BazelCon talk about driving architectural improvements with dependency metrics XCRemoteCache: Open source remote cache tool for Xcode projects that reuses target artifacts generated on a remote machine, served from a simple REST server XCLogParser: Open source tool to parse Xcode and xcodebuild logs stored in the xcactivitylog format 2022 Mobile Ecosystem: Data from the Mobile Native Foundation's first mobile ecosystem survey My Beat: Patrick Balestra Mobile development posts on the Spotify Engineering Blog Read what else we’re nerding out about on the Spotify Engineering Blog: engineering.atspotify.com You should follow us on Twitter @SpotifyEng and on LinkedIn!

There are thousands of developers building great Spotify experiences — who don’t actually work at Spotify. From smart speakers to game consoles to car infotainment systems, how do we support this diverse, creative community building on top of the Spotify platform? Along with providing APIs, SDKs, and other developer tools, it starts with something even more fundamental: listening to and understanding their needs. That’s where our developer advocates come in. Host Dave Zolotusky talks with Serah Kiburu, a Spotify engineer and senior developer advocate. They discuss how and why Spotify supports third-party developers, the value of being “customer zero” for our own developer tools, our most popular APIs, the importance of listening before you start building, Serah’s journey to Spotify in Stockholm, and how she’s preparing for the robot apocalypse. Learn more about the resources we provide third-party developers: Spotify for Developers: Where to find our public APIs, SDKs, libraries, documentation, and community news Serah Njambi Kiburu and Her Hack Week Team: Read more about Serah and her team’s work, including their project from last year’s Hack Week Read what else we’re nerding out about on the Spotify Engineering Blog: engineering.atspotify.com You should follow us on Twitter @SpotifyEng and on LinkedIn!

Recorded live at midnight EST, December 6, 2022, from Boston, Gothenburg, and Stockholm, via the Spotify Live app. In this special Advent of Code episode, we try to solve the Day 6 puzzle the moment it’s released. Host Dave Zolotusky and Spotify’s chief architect, Niklas Gustavsson (aka, ngn), play against Spotify’s reigning champ, the one and only, unstoppable Jimmy Mårdell. Entering today’s challenge behind ngn in the standings, will Jimmy reclaim his rightful place atop the Spotify leaderboard? Play along with us and find out! Plus, Spotify engineers share what makes this friendly, low-stakes coding competition so much fun every year, Jimmy answers questions from the live audience (including offering some speed tips), and more. The Advent of Code season is upon us once again: Advent of Code 2022 — Day 6: The puzzle we’re attempting to solve in this episode. Play along with us — when you hear the boxing bell ring in the episode, click the link above and see how fast you can come up with a solution. Can you beat us to it? 05: Advent of Code: Listen to our previous episode about this annual Spotify tradition and learn more about the community that’s grown up around it. adventofcode.com: It’s never too late to join in the fun. Start on Day 1 and see how far you can go. Special thanks to Eric Wastl for creating such a fun thing. Read what else we’re nerding out about on the Spotify Engineering Blog: engineering.atspotify.com You should follow us on Twitter @SpotifyEng and on LinkedIn!