Podcasts about Heroku

AI tools are transforming how developers write code, and although it's difficult to pinpoint how much code is now AI-generated code, estimates suggest it's between 20% and 40%, and this figure is poised to grow in the coming years. This evolution has given rise to a new coding paradigm in which developers act as directors, The post Vibe Coding at Heroku with Vish Abrams appeared first on Software Engineering Daily.

Heroku has been undergoing a major transformation, re-platforming its entire Platform as a Service (PaaS) offering over the past year and a half. This ambitious effort, dubbed “Fir,” will soon reach general availability. According to Betty Junod, CMO and SVP at Heroku (owned by Salesforce), the overhaul includes a shift to Kubernetes and OCI standards, reinforcing Heroku's commitment to open source. The platform now features Heroku Cloud Native Buildpacks, which let developers create container images without Dockerfiles. Originally built on Ruby on Rails and predating Docker and AWS, Heroku now supports eight programming languages. The company has also deepened its open source engagement by becoming a platinum member of the Cloud Native Computing Foundation (CNCF), contributing to projects like OpenTelemetry. Additionally, Heroku has open sourced its Twelve-Factor Apps methodology, inviting the community to help modernize it to address evolving needs such as secrets management and workload identity. This signals a broader effort to align Heroku's future with the cloud native ecosystem. Learn more from The New Stack about Heroku's approach to Platform-as-a-Service:Return to PaaS: Building the Platform of Our DreamsHeroku Moved Twelve-Factor Apps to Open Source. What's Next?How Heroku Is Positioned To Help Ops Engineers in the GenAI EraJoin our community of newsletter subscribers to stay on top of the news and at the top of your game.

AI tools are transforming how developers write code, and although it's difficult to pinpoint how much code is now AI-generated code, estimates suggest it's between 20% and 40%, and this figure is poised to grow in the coming years. This evolution has given rise to a new coding paradigm in which developers act as directors, The post Vibe Coding at Heroku with Vish Abrams appeared first on Software Engineering Daily.

Pete Hamilton and Chris Evans are cofounders of Incident.io. Incident is an incident management tool. We discuss:How they think about brand and how it comes from their deep understanding of incident cultureLawrence's article asking for new macbooks that went viralGallows humor in incidents Why incident.io started on Heroku despite being an incident response platform—and why “shipping fast” mattered more than “scaling perfectly.”The benefit of building for users who are just like youHow Incident is using GenAIThis episode is brought to you by WorkOS. If you're thinking about selling to enterprise customers, WorkOS can help you add enterprise features like Single Sign-On and audit logs. Links:Pete Hamilton on Twitter Chris Evans on TwitterIncident Macbook articleThe flight plan that brought UK airspace to its kneesHow Netflix drives reliability across their organizationNote: this was recorded on 13th December 2024.

Hoje o papo é sobre uma engenharia. Neste episódio, conversamos sobre o histórico, as técnicas, as ferramentas e – talvez mais importante – as armadilhas quando o assunto é engenharia de plataformaVem ver quem participou desse papo: André David, o host que quer virar cozinheiro em alto mar. Ou não. Maurício “Balboa” Linhares, engenheiro de software e Hipster de longa data Vinny Neves, Líder de Front-End na Alura Paulo Alves, Coordenador da escola de DevOps da Alura Gui Santos, Fundador da Platform Rocks

It's side project time! Urban talks about moving a project from Heroku to fly.io and Monica starts volunteering her time to stay motivated. Fountain Pen Companion (https://www.fountainpencompanion.com/) FPC Github repository (https://github.com/ujh/fountainpencompanion/) fly.io (fly.io) LiteFS (https://fly.io/docs/litefs/) Pgvector (https://github.com/pgvector/pgvector) Vostel (https://vostel.de/) Freetown Christiania (https://en.wikipedia.org/wiki/Freetown_Christiania) Ask questions via our anonymous feedback form (https://forms.gle/MW8qZFD7RLYriqKj8) You can reach us via email at hosts@expandingbeyond.it (mailto:hosts@expandingbeyond.it). Where to find Monica on the internet: Website: monicag.me (https://monicag.me/) Bluesky: @nirnaeth.bsky.social (https://bsky.app/profile/nirnaeth.bsky.social) Mastodon: @nirnaeth@mastodon.online (https://mastodon.social/@nirnaeth@mastodon.online) Github: @nirnaeth (https://github.com/nirnaeth) Blog: dev.to/nirnaeth (https://dev.to/nirnaeth) Where to find Urban on the internet: Mastodon: @ujh@masto.ai (https://masto.ai/@ujh) Bluesky: @urbanhafner.bsky.social (https://bsky.app/profile/urbanhafner.bsky.social) Github: @ujh (https://github.com/ujh/) Blog: urbanhafner.com (https://urbanhafner.com/) The intro and outro music is Our Big Adventure (https://freemusicarchive.org/music/Scott_Holmes/Happy_Music/Our_Big_Adventure) by Scott Holmes (https://freemusicarchive.org/music/Scott_Holmes). It's licensed under Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) (https://creativecommons.org/licenses/by-nc/4.0/).

Today's guest is Adam Wiggins! Adam is the General Manager of Platform at The Browser Company and co-founder of Heroku. With Adam, we talked about innovating user experience in software and AI, we discussed what Local-first software means and we explored the future of developer tools. (02:49) Introduction (04:01) Adam's journey in tech (06:15) The rise of developer experience (10:03) The constant drive of improving UX (12:07) Dia & The Browser Company (14:49) Using AI to improve UX (20:38) Unlocking potentials through UX (25:18) Local-first software (32:34) Data ownership (34:31) Web development and complexity (38:03) AI and the future of development (40:25) The iteration loop — This episode is brought to you by https://workos.com — You can also find this at: -

News includes upcoming improvements to ex_doc for version navigation, the release of Phoenix Analytics 0.3.0 for plug-and-play application metrics, José Valim's detailed exploration of set-theoretic types for better library compatibility, German Velasco's demonstration of Elixir 1.18's enhanced type system, the beta release of the Ash Framework book on PragProg, and exciting developments in the FLAME ecosystem with AWS EC2 support, and more! Show Notes online - http://podcast.thinkingelixir.com/237 (http://podcast.thinkingelixir.com/237) Elixir Community News https://bsky.app/profile/david.bernheisel.com/post/3lffr6xdvq22r (https://bsky.app/profile/david.bernheisel.com/post/3lffr6xdvq22r?utm_source=thinkingelixir&utm_medium=shownotes) – ex_doc will soon feature a new button to navigate to the latest version's documentation when viewing older versions. https://x.com/mrpopov_com/status/1878817795049488421 (https://x.com/mrpopov_com/status/1878817795049488421?utm_source=thinkingelixir&utm_medium=shownotes) – Phoenix Analytics 0.3.0 released with improved support for Fly.io and Heroku deployments. https://github.com/lalabuy948/PhoenixAnalytics (https://github.com/lalabuy948/PhoenixAnalytics?utm_source=thinkingelixir&utm_medium=shownotes) – Plug and play analytics solution for Phoenix applications, offering embedded dashboard functionality. https://dashbit.co/blog/data-evolution-with-set-theoretic-types (https://dashbit.co/blog/data-evolution-with-set-theoretic-types?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim's article explaining how set-theoretic types will improve library backwards-compatibility in Elixir. https://www.elixirstreams.com/tips/elixir-118-type-system-changes (https://www.elixirstreams.com/tips/elixir-118-type-system-changes?utm_source=thinkingelixir&utm_medium=shownotes) – German Velasco's ElixirStream video demonstrating the improved type system changes in Elixir 1.18. https://pragprog.com/titles/ldash/ash-framework/ (https://pragprog.com/titles/ldash/ash-framework/?utm_source=thinkingelixir&utm_medium=shownotes) – Ash Framework book by Rebecca Le and Zach Daniel released in beta on PragProg, covering LiveView, auth, search, APIs, and notifications. https://github.com/phoenixframework/flame (https://github.com/phoenixframework/flame?utm_source=thinkingelixir&utm_medium=shownotes) – FLAME (Fleeting Lambda Application for Modular Execution) by Chris McCord enables dynamic resource scaling on Fly.io. https://github.com/probably-not/flame-ec2 (https://github.com/probably-not/flame-ec2?utm_source=thinkingelixir&utm_medium=shownotes) – FlameEC2 library extends FLAME functionality to AWS EC2 machines. https://bsky.app/profile/codebeam.bsky.social/post/3lfp4penmik2v (https://bsky.app/profile/codebeam.bsky.social/post/3lfp4penmik2v?utm_source=thinkingelixir&utm_medium=shownotes) – Code BEAM Lite London 2025 is on January 31, featuring Michał Muskała as speaker. https://alchemyconf.com/ (https://alchemyconf.com/?utm_source=thinkingelixir&utm_medium=shownotes) – Alchemy Conf scheduled for March 31 - April 3 in Braga, Portugal. https://membrz.club/alchemyconf/events?tag=workshop (https://membrz.club/alchemyconf/events?tag=workshop?utm_source=thinkingelixir&utm_medium=shownotes) – Alchemy Conf workshops announced featuring Saša Jurić, Zach Daniel, and Andrea Leopardi. https://x.com/Alchemy_Conf/status/1879136370691862929 (https://x.com/Alchemy_Conf/status/1879136370691862929?utm_source=thinkingelixir&utm_medium=shownotes) – Additional announcement about Alchemy Conf workshop details. Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Find us online - Message the show - Bluesky (https://bsky.app/profile/thinkingelixir.com) - Message the show - X (https://x.com/ThinkingElixir) - Message the show on Fediverse - @ThinkingElixir@genserver.social (https://genserver.social/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen on X - @brainlid (https://x.com/brainlid) - Mark Ericksen on Bluesky - @brainlid.bsky.social (https://bsky.app/profile/brainlid.bsky.social) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel on Bluesky - @david.bernheisel.com (https://bsky.app/profile/david.bernheisel.com) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern)

Heroku is a cloud platform-as-a-service that enables developers to build, deploy, and manage applications. It was founded in 2007 and was acquired by Salesforce in 2010. The platform supports multiple programming languages, including Ruby, Python, Node.js, and Java, and has features such as automated scaling, database monitoring tools, and a streamlined deployment workflow. Vish Abrams The post Heroku and the Twelve-Factor App with Vish Abrams appeared first on Software Engineering Daily.

Heroku is a cloud platform-as-a-service that enables developers to build, deploy, and manage applications. It was founded in 2007 and was acquired by Salesforce in 2010. The platform supports multiple programming languages, including Ruby, Python, Node.js, and Java, and has features such as automated scaling, database monitoring tools, and a streamlined deployment workflow. Vish Abrams The post Heroku and the Twelve-Factor App with Vish Abrams appeared first on Software Engineering Daily.

In this episode from AWS re:Invent 2024, Jon Myer sits down with Adam and Chris from Heroku to discuss their major platform transformation. Learn about Heroku's shift to Kubernetes, their commitment to maintaining the beloved developer experience, and how they're revolutionizing cloud-native development while staying true to their roots. Discover how Heroku is evolving to meet modern enterprise needs while keeping their signature simplicity. Key Takeaways:

In this episode from AWS re:Invent 2024, Jon Myer sits down with Adam and Chris from Heroku to discuss their major platform transformation. Learn about Heroku's shift to Kubernetes, their commitment to maintaining the beloved developer experience, and how they're revolutionizing cloud-native development while staying true to their roots. Discover how Heroku is evolving to meet modern enterprise needs while keeping their signature simplicity. Key Takeaways:

Corey Quinn welcomes Adam Zimman back to Screaming in the Cloud for a sponsored episode featuring Heroku by Salesforce. As Head of Product Marketing, Adam discusses after years of stagnation following its Salesforce acquisition. Recent investments and a dedicated team signal a renewed focus on developer experience. The duo explores Heroku's impact on modern app development, its role in popularizing the 12-Factor App model, and the decision to retire its free tier. Adam highlights key updates, including Kubernetes replatforming, .NET support, and AI tools for managed inference and agents. He also teases his upcoming book, Progressive Delivery, set for release next year.Show Highlights(0:00) Intro(1:01) Heroku sponsor read(1:39) How Heroku became resurgent(5:46) Heroku's legacy(9:53) Adam's thoughts on people's response to the free tier going away(10:55) Heroku's target customer(s)(13:51) Heroku sponsor read(14:19) How Heroku saves organizations money and developed over time(20:08) Heroku's re:Invent announcements(24:53) How modern-day developers have reacted to Heroku's resurgence(27:47) Where people can learn more about Heroku About Adam ZimmanAdam Zimman is Technologist and Author currently serving as the Head of Product Marketing at Heroku by SalesForce. Previously, he was a Venture Capital Advisor providing guidance on leadership, platform architecture, product marketing, and GTM strategy. He has over 20 years of experience working in a variety of roles from software engineering to technical sales. He has worked in both enterprise and consumer companies such as VMware, EMC, GitHub, and LaunchDarkly.Adam is driven by a passion for inclusive leadership and solving problems with technology. He is a co-author of Progressive Delivery: Build the right thing, for the right people, at the right time. His perspective has been shaped by a degree (AB) from Bowdoin College with a dual-focus in  Physics and Visual Art, an ongoing adventure as a husband and father, and a childhood career as a fire juggler.LinksHeroku's website: https://www.heroku.com/Adam's Bluesky: https://bsky.app/profile/azimman.bsky.socialAdam's Mastodon: https://hachyderm.io/@azAdam's LinkedIn: https://www.linkedin.com/in/adamzimman/Personal site: https://progressivedelivery.com/SponsorHeroku: http://heroku.com/

Heroku has open-sourced its Twelve-Factor App methodology, initially created in 2011 to help developers build portable, resilient cloud applications. Heroku CTO Gail Frederick announced this shift at KubeCon + CloudNativeCon North America, explaining the move aims to involve the community in modernizing the framework. While the methodology inspired a generation of cloud developers, certain factors are now outdated, such as the focus on logs as event streams. Frederick highlighted the need for updates to address current practices like telemetry and metrics visualization, reflecting the rise of OpenTelemetry.The updated Twelve-Factor methodology will expand to accommodate modern cloud-native realities, such as deploying interconnected systems of apps with diverse backing services. Planned enhancements include supporting documents, reference architectures, and code examples illustrating the principles in action. Success will be measured by its applicability to use cases involving edge computing, IoT, serverless, and distributed systems. Heroku views this open-source effort as an opportunity to redefine best practices for the next era of cloud development.Learn more from The New Stack about Heroku: How Heroku Is Positioned To Help Ops Engineers in the GenAI EraThe Data Stack Journey: Lessons from Architecting Stacks at Heroku and MattermostJoin our community of newsletter subscribers to stay on top of the news and at the top of your game. 

We compiled our favorite clips on developer tools and developer experience (DevX). We discuss why DevX has become essential for developer-focused companies and how it drives adoption to grow your product. Learn what makes developers a unique and discerning customer base, and hear practical strategies for designing exceptional tools and platforms. Our guests also share lessons learned from their own experiences—whether in creating frictionless integrations, maintaining a strong feedback culture, or enabling internal platform adoption. Through compelling stories and actionable advice, this episode is packed with lessons on how to build products that developers love. Playlist of Full Episodes from This Compilation: https://www.youtube.com/playlist?list=PL31JETR9AR0FV-46VR4G_n6xi4WdXEx-2 Inside the episode... The importance of developer experience and why it's a priority for developer-facing companies. Key differences between building developer tools and end-user applications. How DevX differs from DevRel and the synergy between the two. Metrics for measuring the success of developer tools: adoption, satisfaction, and revenue. Insights into abstraction ladders and balancing complexity and power. Customer research strategies for validating assumptions and prioritizing features. Stripe's culture of craftsmanship and creating “surprisingly great” experiences. The importance of dogfooding and feedback loops in building trusted platforms. Balancing enablement and avoiding gatekeeping in internal platform adoption. Maintaining consistency and quality across APIs, CLIs, and other resources. Mentioned in this episode Stripe Doppler Heroku Abstraction ladders Developer feedback loops Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Subscribe to the Convergence podcast wherever you get podcasts including video episodes to get updated on the other crucial conversations that we'll post on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow.   Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence

What if you could scale your SaaS platforms effortlessly across diverse hosting services? Join us as we welcome Adam McCrea, the brilliant mind behind JudoScale, who takes us through his fascinating evolution from being a Rails developer to creating a cutting-edge autoscaling solution. Adam opens up about the technical challenges he faced while adapting JudoScale for platforms like Render, Fly, and Railway, and how Heroku's unique architecture initially shaped his approach. His journey is one of innovation driven by necessity, as JudoScale originated from a need to optimize costs more efficiently than existing solutions.Our conversation doesn't shy away from complexity; in fact, it embraces it. Adam shares his experiences of grappling with AWS integration, navigating the intricate maze of ECS, EC2, Fargate, and IAM, all driven by customer demand. We explore the strategic shift from metered billing to flat-tiered pricing and the hurdles faced while setting up a staging environment on Render, ultimately reaffirming Heroku's smoother experience. This episode promises valuable insights into the strategic decisions and architectural reimaginations that keep JudoScale ahead of the game.Adding a creative flair, we delve into the entertaining world of infomercial production, as Adam recounts his experience crafting a humorous Billy Mays-inspired ad for JudoScale. With the aid of AI tools like ChatGPT and Descript, Adam turned a fun concept into an engaging reality. As we wrap up, Adam shares his excitement for RailsConf in Philadelphia and the significance of fostering connections through digital networking. Whether you're a tech enthusiast or a developer seeking innovative scaling solutions, this episode is brimming with insightful takeaways and creative inspiration.Send us some love.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.

In this episode of DevOps Diaries we cover some of the outstanding moments from DevOps Diaries in 2024. Hear about everything from artificial intelligence and Salesforce Flows, to Heroku and QA testing.You can expect snippets of conversation with: Julián Duque, Steve Fouracre, Alba Rivas, Dave Carroll, Jon Robinson, Todd Halfpenny and Andy Utkan. Thank you to all our guests this year for sharing wonderful insights and knowledge!All episodes from this year can be found on Gearset's YouTube channel as well as audio platforms.Learn more:- Deploy Salesforce Flows easily- Salesforce DevOps for enterprise organizations- Easy backup and restore solutions for Salesforce- How successful are teams using Gearset?About DevOps Diaries: Salesforce DevOps Advocate Jack McCurdy chats to members of the Salesforce community about their experience in the Salesforce ecosystem. Expect to hear and learn from inspirational stories of personal growth and business success, whilst discovering all the trials, tribulations, and joy that comes with delivering Salesforce for companies of all shapes and sizes. New episodes bi-weekly on YouTube as well as on your preferred podcast platform.Podcast produced and sponsored by Gearset. Learn more about Gearset.Subscribe to Gearset's YouTube channel: https://grst.co/4cTAAxmLinkedIn: https://www.linkedin.com/company/gearsetX/Twitter: https://x.com/GearsetHQFacebook: https://www.facebook.com/gearsethqAbout Gearset: Gearset is the leading Salesforce DevOps platform, with powerful solutions for metadata and CPQ deployments, CI/CD, automated testing, sandbox seeding and backups. It helps Salesforce teams apply DevOps best practices to their development and release process, so they can rapidly and securely deliver higher-quality projects. Get full access to all of Gearset's features for free with a 30-day trial.Chapters:00:00 Julián Duque — Heroku and Salesforce03:55 Steve Fouracre — Impact of AI on Salesforce Development08:02 Andy Utkan — Why Salesforce Developers should care about Salesforce Flows 10:58 Todd Halfpenny — The future role of Salesforce Developers15:12 Dave Carroll — The best learning method for Salesforce professionals19:38 Alba Rivas — How does Agentforce work?25:38 Jon Robinson — How to implement a good Salesforce QA strategy

This week, we cover Netflix's streaming hiccups, cloud earnings updates, Red Hat's CNCF donations, and the potential sale of Chrome. Plus, a few thoughts on parenting. Watch the YouTube Live Recording of Episode (https://www.youtube.com/watch?v=7qe9xOqN-Lk) 494 (https://www.youtube.com/watch?v=7qe9xOqN-Lk) Runner-up Titles The dog peed on it. Jamin's favorite Excel macros. Change up the noodles. 0.7 good tips there The tiniest of rebellions Win one for the stockholders Candor A datacenter with a gift shop. VP of Cables has cucumber water with VP of Monitors. You can't open source a monitor. Rundown Netflix Netflix's Boxing Event, Customer Acquisition vs. Churn Mitigation, Accounting for Events (https://stratechery.com/2024/netflixs-boxing-event-customer-acquisition-vs-churn-mitigation-accounting-for-events/?access_token=eyJhbGciOiJSUzI1NiIsImtpZCI6InN0cmF0ZWNoZXJ5LnBhc3Nwb3J0Lm9ubGluZSIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJzdHJhdGVjaGVyeS5wYXNzcG9ydC5vbmxpbmUiLCJhenAiOiJIS0xjUzREd1Nod1AyWURLYmZQV00xIiwiZW50Ijp7InVyaSI6WyJodHRwczovL3N0cmF0ZWNoZXJ5LmNvbS8yMDI0L25ldGZsaXhzLWJveGluZy1ldmVudC1jdXN0b21lci1hY3F1aXNpdGlvbi12cy1jaHVybi1taXRpZ2F0aW9uLWFjY291bnRpbmctZm9yLWV2ZW50cy8iXX0sImV4cCI6MTczNDYxMzIxMiwiaWF0IjoxNzMyMDIxMjEyLCJpc3MiOiJodHRwczovL2FwaS5wYXNzcG9ydC5vbmxpbmUvb2F1dGgiLCJzY29wZSI6ImZlZWQ6cmVhZCBhcnRpY2xlOnJlYWQgYXNzZXQ6cmVhZCBjYXRlZ29yeTpyZWFkIGVudGl0bGVtZW50cyIsInN1YiI6IlRIMzRnVkN5aHhXZ21uQWZ0WEZtdVMiLCJ1c2UiOiJhY2Nlc3MifQ.AyMwbazpm5LR_zhwZiRLStIqxPaGuHbceNMyKVLcX4NNRg24VPow2YD-dCJbLx5RtePzQE87rXOA3LOTlPuRCJ07Z30HjhTordjCFnw8vz2mLtXe-oe4-It-_VoIvCnAutn5g1bP9rvIbWKvVcA0oteGHOEGMuIVZ7YDxghRvj6elT2Pz5fMcrwwjHKC3N5kIrZcxSTZVxFufWHx2FaYh6uelE8aVrzFOp6_VhvusKvvCkLI8rtRJKMyfLGMQRadts_RKnxXUB19eRcJgs1AiLUs2bmuSLUKvudnwpv3EimElaeKHUh9MqUljEGIXe89dgtImlpotzmvU0VKPy9cIg) Disney sets India Cricket Viewership Record for TV, streaming during World Cup (https://www.bmpsportsevents.com/blog-posts/disney-sets-india-cricket-viewership-record-for-tv-streaming-during-world-cup) Netflix Culture (https://jobs.netflix.com/culture) Earnings Amazon Reports Record $15.3 Billion Profit (https://www.nytimes.com/2024/10/31/business/amazon-q3-earnings.html?smid=nytcore-ios-share&referringSource=articleShare) Clouded Judgement 11.1.24 - Amazon, Google, Microsoft & Meta on AI and CapEx (https://cloudedjudgement.substack.com/p/clouded-judgement-11124-amazon-google?utm_source=post-email-title&publication_id=56878&post_id=150968391&utm_campaign=email-post-title&isFreemail=true&r=2l9&triedRedirect=true&utm_medium=email) Amazon Earnings, Robotics and Amazon's Expanding 1P Business (https://stratechery.com/2024/amazon-earnings-robotics-and-amazons-expanding-1p-business/?access_token=eyJhbGciOiJSUzI1NiIsImtpZCI6InN0cmF0ZWNoZXJ5LnBhc3Nwb3J0Lm9ubGluZSIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJzdHJhdGVjaGVyeS5wYXNzcG9ydC5vbmxpbmUiLCJhenAiOiJIS0xjUzREd1Nod1AyWURLYmZQV00xIiwiZW50Ijp7InVyaSI6WyJodHRwczovL3N0cmF0ZWNoZXJ5LmNvbS8yMDI0L2FtYXpvbi1lYXJuaW5ncy1yb2JvdGljcy1hbmQtYW1hem9ucy1leHBhbmRpbmctMXAtYnVzaW5lc3MvIl19LCJleHAiOjE3MzM5MjMzMjUsImlhdCI6MTczMTMzMTMyNSwiaXNzIjoiaHR0cHM6Ly9hcGkucGFzc3BvcnQub25saW5lL29hdXRoIiwic2NvcGUiOiJmZWVkOnJlYWQgYXJ0aWNsZTpyZWFkIGFzc2V0OnJlYWQgY2F0ZWdvcnk6cmVhZCBlbnRpdGxlbWVudHMiLCJzdWIiOiJUSDM0Z1ZDeWh4V2dtbkFmdFhGbXVTIiwidXNlIjoiYWNjZXNzIn0.HO5sxW0eBQFKsqs38nWX6yVSp9OQh-tJNkNI7Nyib6zZxAbAEMMnfy2dJDBTZ4ZqZBXqfo5VqJhrBPhELzTg2M_rOrDWOaotGl1eqYHpBiPVdxuXBoXN6_ME7fut7d32Hr9FfAol8201Q3n6sOvQ7YBYyCDBJosEelNtWKICsg98WJ01Sd2EuZz-3XtA3gSziu7yhVsKX5cw_6sLtUPyyUwLaOqutRaJfvdhQVynvKmrgyX5OtlU60MmcwXrPWXDcptcesUUyAwzClRNIOIrSrPVvawNL66mJL24oyrbDFgUUJT4yVYHiuylb_JO1otCftQNhGkv0iOft8N0NPVpfg) Cloud market share shows vendors eyeing a $1T opportunity (https://siliconangle.com/2024/11/16/cloud-market-share-shows-vendors-eyeing-1t-opportunity/) Windows 365 Link is a $349 mini PC that streams Windows from the cloud (https://www.theverge.com/2024/11/19/24299789/microsoft-windows-365-link-device-cloud-pc) Going Open Source Red Hat to Donate Podman Along With Other Container Tools to CNCF (https://cloudnativenow.com/kubecon-cnc-na-2024/red-hat-to-donate-podman-along-with-other-container-tools-to-cncf/) Salesforce's Heroku platform open-sources Twelve Factor project (https://siliconangle.com/2024/11/15/twelve-factor-project-open-source-salesforce-kubecon/) Twelve-Factor App Methodology is now Open Source (https://12factor.net/blog/open-source-announcement) DOJ Will Push Google to Sell off Chrome to Break Search Monopoly (https://www.bloomberg.com/news/articles/2024-11-18/doj-will-push-google-to-sell-off-chrome-to-break-search-monopoly) Relevant to your Interests These are the passwords you definitely shouldn't be using (https://www.theverge.com/2024/11/13/24295543/most-common-passwords-list-2024) Datacenter Anatomy Part 1: Electrical Systems (https://semianalysis.com/2024/10/14/datacenter-anatomy-part-1-electrical/) New Apple security feature reboots iPhones after 3 days, researchers confirm (https://techcrunch.com/2024/11/14/new-apple-security-feature-reboots-iphones-after-3-days-researchers-confirm/) AI companies hit a scaling wall (https://www.platformer.news/openai-google-scaling-laws-anthropic-ai/) Invisible asymptotes — Remains of the Day (https://www.eugenewei.com/blog/2018/5/21/invisible-asymptotes) Clouded Judgement 11.14.24 - Market Tipping to Growth (https://cloudedjudgement.substack.com/p/clouded-judgement-111424-market-tipping) For the first time in 25 years, the number of software engineers dropped (https://x.com/mjovanc/status/1857720025563439295) The CNCF's plan to crowdfight patent trolls (https://www.runtime.news/the-cncfs-plan-to-crowdfight-patent-trolls/?ref=runtime-newsletter) Maybe Bluesky has “won” (https://anderegg.ca/2024/11/15/maybe-bluesky-has-won) Having 30,000 followers makes you a celebrity, UK advertising watchdog rules (https://www.theverge.com/2019/7/4/20682087/instagram-twitter-celebrity-30000-followers-advertising-standards-authority-uk) The Influence of Bell Labs (https://www.construction-physics.com/p/the-influence-of-bell-labs) Leaked Amazon memos identify critical flaws in the upcoming AI version of Alexa (https://fortune.com/2024/11/18/new-ai-alexa-latency-problems-echo-compatibility-uber-opentable/) RIP to RPA: The Rise of Intelligent Automation | Andreessen Horowitz (https://a16z.com/rip-to-rpa-the-rise-of-intelligent-automation/) Twenty is building an open source alternative to Salesforce (https://techcrunch.com/2024/11/18/twenty-is-building-an-open-source-alternative-to-salesforce/) Chips RISC-V — the CPU you didn't know you already have (https://adrianco.medium.com/risc-v-the-cpu-you-didnt-know-you-already-have-ff2f385f7ec6) Arm to Cancel Qualcomm Chip Design License (https://archive.md/FcXRW) The RVA23 profile is now ratified, so RISC-V gets satisfied (https://www.theregister.com/2024/10/23/rva23_profile_ratified/) Intel losses hit $16.6B as restructuring efforts take a toll (https://www.theregister.com/2024/11/01/intel_q3_2024/) Intel Was Just Dropped From the Dow (https://www.fool.com/investing/2024/11/05/intel-dropped-from-dow-djia-history-happen-next/) How much Apple Silicon improves with each release (https://appleinsider.com/articles/24/11/06/generation-gaps-how-much-faster-apple-silicon-gets-with-each-release) Nonsense Bojangles to install ordering kiosks across its system (https://www.restaurantdive.com/news/bojangles-grubbrr-installation-kiosks/732460/) 'Simpsons'-themed broadcast means Bengals-Cowboys won't be flexed (https://www.nytimes.com/athletic/5932410/2024/11/19/bengals-vs-cowboys-mnf-not-flexed-simpsons-alt-cast/?source=user_shared_article) Listener Feedback Deutsche Börse Cloud Exchange AG (https://en.wikipedia.org/wiki/Deutsche_B%C3%B6rse_Cloud_Exchange_AG) LibreLinkUp Status Bar a VS Code extension to display good glucose level in the status bar (https://marketplace.visualstudio.com/items?itemName=borkod.librelinkup-vs-code-extension) Conferences CfgMgmtCamp (https://cfgmgmtcamp.org/ghent2025/), February 2rd to 5th. DevOpsDayLA (https://www.socallinuxexpo.org/scale/22x/events/devopsday-la) at SCALE22x (https://www.socallinuxexpo.org/scale/22x), March 6-9, 2025, discount code DEVOP SDT News & Community Join our Slack community (https://softwaredefinedtalk.slack.com/join/shared_invite/zt-1hn55iv5d-UTfN7mVX1D9D5ExRt3ZJYQ#/shared-invite/email) Email the show: questions@softwaredefinedtalk.com (mailto:questions@softwaredefinedtalk.com) Free stickers: Email your address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) Follow us on social media: Twitter (https://twitter.com/softwaredeftalk), Threads (https://www.threads.net/@softwaredefinedtalk), Mastodon (https://hachyderm.io/@softwaredefinedtalk), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com) Watch us on: Twitch (https://www.twitch.tv/sdtpodcast), YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured), Instagram (https://www.instagram.com/softwaredefinedtalk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk) Book offer: Use code SDT for $20 off "Digital WTF" by Coté (https://leanpub.com/digitalwtf/c/sdt) Sponsor the show (https://www.softwaredefinedtalk.com/ads): ads@softwaredefinedtalk.com (mailto:ads@softwaredefinedtalk.com) Recommendations Brandon: Silo Season 2 (https://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwiDr7fyuOmJAxX3Sf8BHXDxOLYYABAAGgJtZA&ae=2&co=1&gclid=Cj0KCQiAi_G5BhDXARIsAN5SX7oulKQPevGaYaSaUDENHbWyKOcMu4Fmlc4iCckvLOeL6efJ5O2cjGwaAhrNEALw_wcB&ohost=www.google.com&cid=CAESVeD2KJUTEM8UiN83N5t9ZLDm6pVzs_bp0Nv22irf8c10iQpHCSaeMICL3a5Z0KW71vqjmjtEZN-nmHWD5NzWkGS6PAdJQ7nzZWHjww4Bd4X7JwFb9yk&sig=AOD64_1o6vDN1m33XOCeIfBmYKhiq2cH7Q&q&adurl&ved=2ahUKEwjckLDyuOmJAxUbw_ACHZelJwUQ0Qx6BAgpEAE) Matt: Followup - Spotify Premium limits audiobooks to 10 hours a month

Hi, Spring fans! Happy Spring Boot 3.4.0 release day to those who celebrate! Today I'm joined by both Terence Lee, from Heroku, and my friend DaShaun Carter, and we talk about platforms, buildpacks, and more. #heroku #paas #buildpacks,

Today Laura and Kevin chat with Wesley Beary. Wesley is a tech wizard who has been reshaping the developer experience for over 15 years, turning complex API and open source challenges into solutions loved by developers worldwide. We talk about how do you think organizations can prioritize APIs tools better to enhance internal developer productivity. We hear about Wesley's philosophy on balancing the need for speed, security, with simplicity when building tools and platforms for developers. As an angel investor, Wesley explains how he identifies promising startups that are building for developers or focused on improving the developer experience. We learn the differences between Salesforce and startups approach developer tooling and internal processes. We also learn what's next for developers. Lastly, we find out if Wesley really likes all this. Check this one out!Wesley Beary is currently shaking up the tech world as a Founding Engineer at Anchor, a dev-friendly platform that provides private CAs for internal TLS encryption. It is making HTTPS certificates easy to get on servers, allowing developers to focus on building rather than managing security. Here's a blog Wesley wrote about how Anchor developed a CLI and the tools that helped.Wesley's many career highlights include his maintenance of Ruby's excon gem (over 485 million downloads) and suite of fog gems for cloud services. He also led the design of the Heroku public API and played a key role in publishing the pioneering HTTP API Design Guide. Wesley's insights have guided countless developers in building better APIs.Wesley is more than an open source expert; he's a community builder, having organized dev meetups and delivered keynote addresses at conferences for Upstream, ArrrrCamp, and Ruby.

Sam and Ryan talk about how frameworks and infrastructure evolve with each other, using Next.js as a representative example. They discuss how hosting providers like Heroku have always imposed certain constraints on apps, what features those constraints enable hosting providers to support, how burdensome those constraints are across different frameworks, and how frameworks that add infra-specific APIs can best communicate the costs of those APIs and benefits they enable.Timestamps:0:00 - Intro3:03 - Heroku and the Twelve-Factor App7:39 - GitHub Pages and static sites13:57 - Serverless and JAMstack17:30 - Vercel and CDNs, self-hosting, and Next.js19:00 - How framework APIs can nudge an app towards a particular hosting solution23:09 - What constraints does Next.js impose on your app (e.g. middleware doesn't run node), and what benefits do those constraints give you?36:13 - How Next.js APIs are motivated by wanting to tease apart static and dynamic code, in an attempt to support the needs of any web app with a single stack40:33 - What is the relationship between frameworks and infra?47:37 - How can frameworks that add infra-specific APIs best communicate the costs of those APIs and the benefits they enable?Links:The Twelve-Factor App

Can you feel the festival vibes of Rails World? Brace yourself for an electrifying journey through the upcoming release of Rails 8, where authentication features are creating a buzz like never before. Picture yourself amidst a sea of passionate developers, where hallway interactions often outshine the scheduled talks. We'll also share a heartfelt tribute to Justin Searles, whose potentially final talk left a lasting mark on the Rails community. And guess what? The Rails World spirit isn't just confined to Rails enthusiasts; notable PHP community figures also joined, fostering a beautiful cross-framework camaraderie between Rails and Laravel.Ever felt overwhelmed by deployment options? We've got you covered! This episode is packed with insights on the evolving landscape of Rails deployment tools. We share our mixed emotions about Heroku's discontinued free tier and our newfound appreciation for Hatchbox. The conversation steers towards Kamal and its promise of simplifying deployments, albeit with a learning curve. We discuss the dream of an official Rails playground, which could revolutionize how new developers deploy production apps, and the excitement surrounding default PWA support in Rails 8 that signals a bright future for web applications.Ending on a high note, we dive into diverse deployment strategies by contrasting Laravel Cloud and Kamal, highlighting how Rails accommodates various needs with tools like Hatchbox, AWS, and Kamal. Nadia Odenayu's keynote on migrating from Heroku to Cloud 66 for a more cost-effective B2C app is also not to be missed. We speculate on the game-changing features of Rails 8.1, from action notifier to improved service worker integration, and dream ahead to Rails 9's possibilities. Lastly, hear about the convenience of navigating the event with a bike rental app and the high anticipation for Eileen's keynote, promising even more exciting revelations.Send us some love.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Support the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.

What groundbreaking feature has Rails 8 introduced that has Jason Charns grinning from ear to ear? Join us live from Railsworld 2024 in Toronto as we break down DHH's monumental keynote unveiling the built-in authentication feature that's set to revolutionize Rails development. Jason shares his excitement over the long-awaited feature, drawing hilarious comparisons to his past struggles with Devise and other gems. We also dive into the latest deployment tools—Kamal 2, Thruster, and Propshaft—that promise to smooth out those pesky deployment processes. Jason spills the beans on why Kamal 2's built-in Docker file and SSL updates are game-changers, and how it stacks up against Heroku and AWS.But that's not all! We recount the keynote's most memorable moments, from Drew's amusing standing ovation to the eyebrow-raising comment about the Danish economy. The atmosphere at Railsworld is electric, and Jason tells us what he's most eager to experience next. Whether you're a Rails veteran or just starting your journey, this episode is packed with fresh updates and Jason's insightful commentary on the future of Rails and its deployment tools. Don't miss out on this engaging conversation that captures all the excitement and humor of Railsworld 2024!Send us some love.Support the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.

In this episode of the Convergence podcast, host Ashok Sivanand sits down with Wes Beary from Anchor.dev. Wes shares his journey, from helping shape Heroku's engineering culture to his work today in API design and encryption as a service. Discover how Wes' experience at Heroku and his open-source contributions have shaped his views on building delightful developer experiences and empowering engineering teams. He also talks about the importance of uniformity in API design, fostering a strong engineering culture, and scaling development teams while preserving their core strengths. Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Inside the episode: Wes Beary's transition from game development to cloud infrastructure and open-source contributions The creation of Heroku's command-line interface (CLI) and API development process Best practices in API design and the importance of consistency for developers Insights into fostering engineering culture and maintaining it as teams grow The role of Anchor.dev in simplifying encryption for engineering teams without dedicated security resources Lessons from Heroku's rise to success and what makes a platform as a service valuable Balancing innovation, team culture, and enabling versus gatekeeping in engineering organizations Mentioned in this episode: Anchor.dev – Get started with Anchor.dev at https://lcl.host/ Heroku – Platform as a service, acquired by Salesforce Kobo Readers Fog – Wes Beary's open-source project for cloud API integration Subscribe to the Convergence podcast wherever you get podcasts including video episodes to get updated on the other crucial conversations that we'll post on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow.   Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence  

Bob Wise, CEO of Heroku, discussed the impact of generative AI (GenAI) coding tools on software development in a recent episode of The New Stack Makers. He compared the rise of these tools to adding an "infinite number of interns" to development teams, noting that while they accelerate code writing, they don't yet simplify testing, deployment, or production operations. Wise likened this to the early days of Kubernetes, which focused on improving operations rather than the frontend experience. He emphasized that Kubernetes' success was due to its focus on easing the operational burden, something current GenAI tools have yet to achieve.Heroku, acquired by Salesforce in 2010, is positioned to benefit from these changes by helping teams transition to more automated systems. Wise highlighted Heroku's strategic bet on Postgres, a database technology that's gaining traction, especially for GenAI workloads. He also discussed Heroku's ongoing migration to Kubernetes, aligning with industry standards to enhance its platform.Learn more from The New Stack about HerokuThe Data Stack Journey: Lessons from Architecting Stacks at Heroku and MattermostKubernetes and the Next Generation of PaaS Join our community of newsletter subscribers to stay on top of the news and at the top of your game. 

Julián Duque is Principal Developer Advocate for Heroku at Salesforce. His background in Node.js allows him to think objectively about development on the Salesforce platform and how it scales. His work with Heroku gives him a unique perspective on where traditional software engineering, DevOps, and Salesforce development intersects. In this episode, Julián and Jack discuss the importance of community in software development. Julián dives into how his career has developed in the Developer Relations space, and how sharing knowledge benefits the teacher and the student, building great relationships.Julián teaches Jack what Heroku is, and shares some of the common applications. He explains how Heroku benefits Salesforce teams, and provides the foundation for integrating applications, enabling one source of truth for data so businesses can make data-driven decisions across their tech stacks. Heroku is constantly evolving. Julián sheds light on the future roadmap, why he's excited for the future of Salesforce and what we'll be achieving with new technologies. Learn more Build applications with HerokuWhere to find Gearset at DreamforceHow Gearset integrates with your tech stackSalesforce DevOps for Data CloudAbout DevOps Diaries Salesforce DevOps Advocate Jack McCurdy chats to members of the Salesforce community about their experience in the Salesforce ecosystem. Expect to hear and learn from inspirational stories of personal growth and business success, whilst discovering all the trials, tribulations, and joy that comes with delivering Salesforce for companies of all shapes and sizes. New episodes bi-weekly on YouTube as well as on your preferred podcast platform.Podcast produced and sponsored by Gearset. Learn more about Gearset.Subscribe to Gearset's YouTube channel. LinkedIn: linkedin.com/company/gearsetFacebook: facebook.com/gearsethqAbout Gearset Gearset is the leading Salesforce DevOps platform, with powerful solutions for metadata and CPQ deployments, CI/CD, automated testing, sandbox seeding and backups. It helps Salesforce teams apply DevOps best practices to their development and release process, so they can rapidly and securely deliver higher-quality projects. Get full access to all of Gearset's features for free with a 30-day trial.Chapters:00:00 Get to know Julián09:09 The Importance of Community in Software Development19:38 What is Heroku?24:09 Integrating Salesforce & Heroku32:54 Common Use Cases for Heroku36:25 The Future of Heroku: Next-Generation Platform46:02 Advice for Developers Transitioning to Heroku

In the latest episode of the "Giant Robots On Tour" podcast, hosts Rémy Hannequin and Sami Birnbaum welcome Marc G. Gauthier, a solopreneur and startup coach, who shares his journey from software development to becoming the founder and developer of The Shadow Boxing App. Marc describes how his interest in software engineering began at a young age with QBasic and evolved through various leadership roles at companies like Drivy (now Getaround) and Back Market. His early passion for gaming led him to learn coding, and over time, he naturally transitioned into management roles, finding excitement in organizing and leading teams while maintaining his love for building products. During the episode, Marc discusses the challenges and intricacies of scaling startups, emphasizing the importance of balancing speed and reliability in software development. He recounts his experiences in leadership positions, where he faced the dual task of managing rapid team growth and maintaining software efficiency. Marc also shares insights into the startup ecosystem, noting that most startups struggle to achieve success due to a combination of market timing, team dynamics, and resource management. His own venture, The Shadow Boxing App, represents his attempt to return to hands-on coding while leveraging his extensive experience in startup coaching and advising. Marc also touches on the role of AI in the future of software development, expressing cautious optimism about its potential to augment human workflows and automate repetitive tasks. He advises current and aspiring developers to embrace AI as a tool to enhance their capabilities rather than a replacement for human ingenuity. Marc concludes by highlighting the importance of realistic expectations in the startup world and the need for continuous learning and adaptation in the ever-evolving tech landscape. Getaround (https://getaround.com/) Follow Getaround on LinkedIn (https://www.linkedin.com/company/getaround/), Facebook (https://www.facebook.com/getaround), X (https://twitter.com/getaround), YouTube (https://www.youtube.com/getaround), or Instagram (https://www.instagram.com/getaround/). Back Market (https://www.backmarket.com/en-us) Follow Back Market on LinkedIn (https://www.linkedin.com/company/back-market/), Facebook (https://www.facebook.com/BackMarketCom), X (https://x.com/backmarket), or Instagram (https://www.instagram.com/backmarket). The Shadow Boxing App (https://shadowboxingapp.com/) Follow Marc Gauthier on LinkedIn (https://www.linkedin.com/in/marcggauthier/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Transcript: RÉMY:  This is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Rémy Hannequin. SAMI: And I'm your other host, Sami Birnbaum. RÉMY: If you are wondering who we are, make sure you find the previous podcast where we introduced the Giant Robots on Tour series by throwing random icebreakers at each other. And find out that Jared likes it when someone takes the time to understand someone else's point of view. Joining us today is Marc G Gauthier, a Solopreneur and Startup Coach. Marc, you used to be VP of Engineering at Drivy, now known as Getaround, and also Director of Engineering at Back Market. You also have been a coach and advisor to a startup for over a decade. Currently, your current adventure is being the Founder and Developer of The Shadow Boxing App available on the Apple App Store. We always like to go back to the start with our guests. Everyone has a story, and we are interested in your journey. So, Marc, what led you into the world of software engineering in the first place? MARC: Hello. Well, happy to be here. And, yeah, I started getting into software development quite a long time ago. I actually learned software development with QBasic when I was something like seven. And, from there, I just kept on learning, learning, and learning and got into school for it, then worked in different startups, and then moved into more leadership position management. And I'm now, like, coaching people and building my own product. What do you want to get? Because it's broad. I've been doing it for quite a while. Like, I don't think the QBasic days are that insightful. The only thing I remember from that time is being confused by the print comment that I would expect it to print on my printer or something, but it didn't; it just printed on the screen. That's the only thing I have from back then. SAMI: Why at seven years old? And I'm taking you back too far, but at seven years old, I was probably collecting Pokémon cards and possibly like, you know, those football stickers. I don't know if you had the Panini stickers. MARC: Oh yeah, I was doing that as well. SAMI: But you were doing that as well. But then what drove you at that age? What do you think it was that made you think, I want to start learning to code, or play around with the computer, or get into tech? MARC: [laughs] Yeah. Well, I remember, back then, I really wanted a computer to play games. Like, I had a friend who had a computer. He was playing games, and I wanted to do that. So, I was asking my mom to have a computer, and she told me, "Yeah, you can have one." And she found a really old computer she bought from a neighbor, I think. But she told me like, "I don't know anything about it. So, you have to figure it out and set it up." And she just found someone to kind of help me. And this person told me to, like, take the computer apart. She taught me a bit of software development, and I kind of liked it. And I was always trying to change the games. Back then, it was way easier. You could just edit a sound file, and you would just edit the sound file in the game, so yeah, just learning like this. It wasn't really my intent to learn programming. It just kind of happened because I wanted to play video games really. SAMI: That's really cool. It's really interesting. Rémy, do you remember how...how did you first get...do you remember your first computer, Rémy? RÉMY: My first computer, I think I remember, but the first one I used it was, first, a very long time ago. I discovered that it was an Apple computer way, way later when I discovered what Apple was and what computers were actually. And I just remember playing SimCity 2000 on it, and it was amazing. And we had to, you know, cancel people from making phone calls while we were on the computer because of the internet and all the way we had to connect to the internet back then. And after that, just, I think, Windows 95 at home. Yeah, that's the only thing I can remember actually. Because I think I was lucky, so I got one quite early. And I don't really remember not having one, so I was quite lucky with that. And so, I was always kind of in the computer game without being too much [inaudible 05:02] [laughs]. SAMI: Yeah, I think that's similar to me as well. Like, it's interesting because my initial introduction to computers would have been watching my older brothers kind of play computer games and actually being told to get out the room, or like, you know, "We're busy now. Don't bother us." And then, what actually happened is when they left the room, I managed to play what they were playing, which was the first ever GTA. I don't know if anyone ever played this, but it is so cool if you look back on it. You could probably find emulators online, but it was, like, a bird's eye view, like, way of operating. And it was probably also that drive where you get frustrated on a computer because you want to do something, so, like you were saying, Marc, where you went to edit the sound files because you want to change something. You want to do something. I definitely think that is something which I felt as well is that frustration of I want to change this thing. And then, that kind of gets into well, how does it work? And if I know how it works, then I can probably change it. MARC: Yeah. And once you figure out how things work, it's also really exciting. Like, once you figure out the initialization file on Windows, like, you can edit, like, what level is unlocked right away. It's kind of cheat codes but not really. And there are some really fun ones. Like, I would edit sound files for racing games. And, usually, it's just a base sound file, and then they would pitch shift the sound to make it sound like an engine. So, if you record your voice, it's just really funny. RÉMY: So, Marc, you mentioned moving to management positions quite early. Do you remember what made you do this move? Was it for, like, a natural path in your career, or was it something you really wanted from the first part of your career as a developer? What happened at this moment? MARC: Yeah, that was not completely planned. Like, I don't think I really plan my career precisely. It's just something that happens. So, I joined Drivy after, like, I was already a software engineer for, like, five years at that point. I joined as a lead backend engineer. I did that for three years. And after three years, the company went from...I think there was, like, three software engineers to a dozen. There was a need for more structure, and the CTO, at the time so, Nicolas, wanted to focus more on products. And it was hard to do both, like do the product side, the design, the data, and do the engineering, the software, and so on. So, he wanted to get a bit away from software engineering and more into product. So, there was a gap in the organization. I was there. I was interested to try, and I was already doing some more things on the human side, so talking to people, organizing, internal communication. I kind of liked it. So, I was excited to try, give it a try. It was really interesting. I found that it was a different way to have an impact on the team. I just kept doing it. And my plan was to keep doing it until I'm bored with it. And I'm still not bored with it, even though you kind of miss just actually building the software yourselves, actually coding. So, that's also why I'm trying something different right now with my mobile app adventure. SAMI: Right. So, on the side, you've got this Shadow Boxing App, which, in my dedicated research, I downloaded and had a go with it. MARC: Did you actually try it, or did you just click around? SAMI: I did a proper workout, mate. I did. I put myself as, like, the absolute beginner. I did it on my MacBook Pro. I know it's built for iPad or iPhone, but it still worked amazingly well. And it kind of reminded me why I stopped doing boxing because it's hard work. MARC: [laughs] Yeah, it is. SAMI: It's not a gimmick this thing, right? So, it's like, the best way to describe it is it's essentially replacing if I was to go to the gym and have a trainer who's telling me kind of the moves to make or how to do it, then this kind of replaces that trainer. So, it's something you can do at home. It was really cool. I was surprised, actually. I thought, at the beginning, it's not going to be that interactive, or it won't actually be as hard or difficult as a workout, and it really was. So, it's, yeah, it was really cool, really interesting to try it. And going into that, you say you wanted to get back more into coding, and that's why you are doing this kind of, like, app on the side, or it allowed you to kind of do a bit more coding away from the people management. You've been involved in a lot of startups, and I actually often get...as consultants, when we work at thoughtbot, we get a lot of people who come with different startup ideas. When you look back at all the startups you've been involved with, do you think more startups are successful than those that fail? Or have you seen a lot of startups...actually, people come with these great ideas; they want to build this amazing product, but it's actually really hard to be a successful product? MARC: I think it's [inaudible 10:22] how to have the right idea, be at the right spot at the right time, build the right team, get enough momentum. I think most startups fail, and even startups that are successful often can be the result of a pivot. Like, I know companies that pivoted a bunch of times before finding any success. So, it's really hard actually...if I take my past four companies, only two are still alive. Like, the first two went under. Actually, there's even more companies that went under after I left. Yeah, it's just really hard to get anything off the ground. So, yeah, it's complicated, and I have a lot of respect for all the founders that go through it. For The Shadow Boxing App, I worked on it for the past three years, but I'm only working on it almost full-time for the past two months. And it was way safer. I could check the product-market fit. I could check if I enjoyed working on it. So, I guess it was easier. I had the luxury of having a full-time job. Building the app didn't take that much time. But to answer your question, I think, from my experience, most startups fail. And the ones that succeed it's kind of lightning in a bottle, or, like, there's a lot of factors that get into it. It's hard to replicate. A lot of people try to replicate some science, some ideas. They go, oh, we'll do this, and we'll do that. And we use this technique that Google uses and so on, but it's never that straightforward. SAMI: Yeah, I'm so happy you said that because I think it's a real brutal truth that I'd also say most of the startup projects that I've worked on probably have failed. Like, there's very few that actually make it. It's such a saturated market. And I think, I guess, in your role as advising startups, it's really good to come in with that honesty at the beginning and to say, "It's a big investment if you want to build something. Most people probably aren't successful." And then, when you work from that perspective, you can have, like, way more transparent and open discussions from the get-go. Because when you're outside of tech...and a lot of people have this idea of if I could just get an app to do my idea, I'm going to be the next Facebook. I'm going to be the next, you know, Amazon Marketplace. And it just kind of isn't like that. You've got these massive leaders in Facebook, Amazon, Google, Netflix. But below that, there's a lot of failures and a massively saturated market. So, yeah, just, it's so interesting that you also see it in a similar way. MARC: What I saw evolve in the past 10 years is the fact that people got more realistic with it. So, maybe 10 years ago, I would have people coming to me with just the most ridiculous idea, like, you know, I'll do Airbnb for cats. And really think, yeah, I just need a good idea, and that's it. But now I feel like people kind of understand that it's more complicated. There's way more resources online. People are more educated. They also see way more successes. Failures are also a bit more advertised. We saw a bunch of startups just go under. It feels like every month I get an email from a tool I used in the past saying, "Oh, we're shutting down," and so on. So, I think it's not as bad as 10 years ago where weekly I would have just people asking me, "I want to build this app," and the app would be just the most ridiculous thing or something that would be really smart, but it's really like, "Oh, I want to do, like, food delivery but better than what exists." It's like, yeah, that's a really good idea, but then you need...it's not only software. There's logistics. There's so much behind it that you don't seem to understand just yet. But, as a coach, so, what I'm doing is I'm helping startups that are usually before or after series A but not too large of startups just go to the next stage. And people are really aware of that and really worried. Like, they see money going down, market fit not necessarily being there. And they know, like, their company is at risk. And especially when you talk to founders, they're really aware that, you know, everything could be collapsing really quickly. If they make, like, three really bad decisions in a row, you're basically done. Obviously, it depends on the company, but yeah, people are more aware than before, especially nowadays where money is a bit harder to get. Let's say two years ago, there was infinite money, it felt like. Now it's more tight. People are more looking at the unit economics precisely. So, people need to be more realistic to succeed. RÉMY: What's the kind of recurrent struggle the startups you coach usually face? Apparently, it quite changed in the past decade, but maybe what are the current struggles they face? MARC: It really depends. It's kind of broad. But, usually, it would be, let's say, a startup after their first round of funding, let's say, if you take startups that are looking for funding. So, you usually have a group of founders, two to four, usually two or three, that are really entrepreneurs that want to bootstrap some things. They're builders. They're hacking things together, and they're really excited about the product. And, suddenly, fast forward a few years, they're starting to be successful, and they have to lead a team of, you know, like, 50 people, 100 people, and they weren't prepared for that. They were really prepared to, like, build software. Like, especially the CTOs, they are usually really great hackers. They can, like, create a product really quickly. But, suddenly, they need to manage 30 engineers, and it's completely different, and they're struggling with that. So, that's a common problem for CTOs. And then, it creates a bunch of problems. Like, you would have CEOs and CTOs not agreeing on how to approach the strategy, how to approach building a thing. What should be the methodology? Something that worked with 3 engineers around the table doesn't work with 50 engineers distributed in 5 countries. And if it's your first time being a CTO, and often founders of early-stage startups are first-time CTOs, it can be really hard to figure out. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it's easy for spending creep to sneak in when your team isn't looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. RÉMY: In your past companies, so you've been VP and CTO. So, in your opinion, what's the best a VP or a CTO can bring to a scaling startup? What are your best tips to share? MARC: I guess it depends [laughs], obviously, like, depending on the stage of the company, the size of the company. For instance, when I was at Drivy, at some point, the most important thing was scaling the team hiring, and so on. But, at some point, we got acquired by Getaround, and the priorities got shifted. It was more like, okay, how do you figure out this new setup for the company and the team? Like, what is good? What is bad? How do you communicate with the team? How do you get people to stay motivated when everything is changing? How do you make sure you make the right decisions? And then, when I joined Back Market, Back Market when I joined, I had a team of a bit less than 12 engineers reporting directly to me. And after a bit more than a year, I had 60, and I hired most of them. So, here the challenge was just scaling insanely fast. Like, the company is really successful. Like, Back Market is selling refurbished electronics in a mission to, you know, provide a viable alternative to buying new electronics. So, it's basically, do you want a smartphone that is both cheaper and more ecologically viable? And most people would say yes to that. So, a company is insanely successful, but it's really hard to scale. So, at that point, the role was, okay, how do you make sure you scale as well as possible with a lot of pressure while still leaving the team in a state that they're able to still build software? Because it's just really chaotic. Like, you can't, like, 5X your team without chaos. But how do you minimize that but still go really fast? SAMI: Yeah. So, not only did I try that Shadow App. I actually went on that Backup website. What's it called? It's not called Backup. What's it called again? MARC: Back Market. SAMI: Back Market. Thank you. Yeah, it was really cool. I checked my old iPhone SE from 2020, which I've kept for about...over three years, I've had this iPhone. And they said they would give me $72 for it, which was really cool. So, it sounds like a really cool idea. MARC: That's something we worked on, which is, basically, if you have any old phones in your drawer, it's a really bad spot for them. And so, there's a service. You go on the website. You say, "I have this, I have that; I have this, I have that." And either we buy it from you, or we just take it away from you, and we recycle them, which is much better than just having them collect dust. SAMI: Yeah, no, it's a great idea. What interested me when you were speaking about kind of these different positions that you've been in, I was almost expecting you to talk about maybe, like, a technical challenge or code complexity difficulty. But, actually, what you've described is more people problems. And how do we scale with regards to people, and how do we keep people motivated? So, I guess using that experience, and this might be counterintuitive to what a lot of people think, but what do you think is the hardest thing about software development? I know there could be many things. But if you had to pick something that is the most difficult, and maybe we can all have an answer to what we think this is, but starting with you, Marc, what do you think is the hardest thing about software development then? MARC: What I saw is how do you build something that works for enough time to bring value to the customers? So, it's easy to hack something together pretty quickly and get it in front of people, but then it might not be reliable. It might break down. Or you could decide to build something perfect and spend, like, two years on it and then ship it, and then it's really stable, but maybe it's not what people want. And finding this balance between shipping something fast, but shipping something that is reliable enough for what you're building. Obviously, if you're building a health care system, you will have more, like, the bar will be higher than if you build, like, Airbnb for cats. Finding this balance and adjusting as you go is really hard. So, for instance, when do you introduce caching? Because, obviously, caching is hard to do right. If you don't do it, your site will be slow, which can be okay for a time. But then if you introduce it too late, then it's really hard to just retrofit into whatever you already have. So, finding the right moment to introduce a new practice, introduce a new technology is tricky. And then, like, I talked a lot about the people, and it's also because I spent quite a bit of time in leadership position. But, at the end of the day, it will be the people writing the code that gets the software to exist and run. So, having people aligned and agreeing on the vision is also key because unless I'm the only developer on the project, I can't really make all decisions on things that are going to get built. So, figuring out how to get people motivated, interested in just building in the same direction is really important. It's really easy. Like, one thing with Drivy, when I was there, that was really fun to see, like, many people have this reaction, especially the more senior people joining the company. They would see the engineering team, and they were really, really surprised by how small it was because we were being really, really efficient. Like, we were paying really close attention to what we would work on. So, kind of technology we would introduce would be quite conservative on both to really be able to deliver what is the most important. So, we were able to do a lot with, honestly, not a lot of people. And I think this is a great mark for success. You don't need a thousand people to build your software if you ask the right question, like, "Do I need to build X or Y?" and always having these discussions. RÉMY: What's your opinion on that, Sami? SAMI: Yeah, I guess it changes. Like, for example, today, the hardest thing about software development was just getting Jira to work. That has literally ruined my whole day. But I've found, for me, what I find is the most difficult thing to do is making code resilient to change. What I mean by that is writing code that's easy to change. And a lot of that, I guess, we try to work on at thoughtbot, as consultants, is following kind of design principles and best practices and certain design patterns that really make the code easy to change. Because that, I think, when I'm writing code is the biggest challenge. And where I feel when I'm working with our clients one of the biggest things they can invest in, which is difficult because there's not a lot of visibility around it or metrics, is ensuring that code that's written is easy to change because, at some point, it will. And I've also worked on systems which are bigger, and when you can't change them, conversations start happening about the cost of change. Do we rewrite it from the ground up again? And that opens a whole different can of worms. So, that, for me, I think, is definitely one of the hardest things. How about yourself, Rémy? RÉMY: I don't know about the most difficult. I mean, there are many things difficult. But I remember something that I had to put extra effort, so maybe it was one of the most difficult for me. When I started being a consultant, when I joined thoughtbot was to understand what's the boundary between executing and giving an advice? So, basically, I discovered that when you're a consultant, but it works also when you're a developer in a team, you know, you're not just only the one who is going to write the code. You're supposed to be also someone with expertise, experience to share it and to make the project and the team benefit from it. So, at some point, I discovered that I should not just listen to what the client would say they want. Obviously, that's what they want, but it's more interesting and more difficult to understand why they want it and why they actually need, which could be different from what they want. So, it's a whole different conversation to discover together what is actually the necessary thing to build, and with your expertise and experience, try to find the thing that is going to be the most efficient, reliable, and making both the client and the customers happy. MARC: Yeah. And as software engineers, it's really easy to get excited about a problem and just go, "Oh, I could solve it this way." But then you need to step back and go, "Well, maybe it doesn't need fixing, or we should do something completely different." At some point, I was working with a customer service organization. In their workflows, they had to go on, let's say, five different pages and click on the button to get something to do one action. And so, what they asked for is to have those five buttons on one single page, and so, they could go, click, click, click, click, click. But after looking at it, what they needed is just automation of that, not five buttons on the page. But it's really easy to go, oh, and we could make those buttons, like, kind of generic and have a button creator thing and make it really fancy. When you step back, you go, oh, they shouldn't be clicking that many buttons. SAMI: Yeah, that makes so much sense because just in that example...I can't remember where I read this, but every line of code you write has to be maintained. So, in that example where you've got five buttons, you're kind of maintaining probably a lot more code than when you've got the single button, which goes to, I don't know, a single action or a method that will handle kind of all the automation for you. And that's also, you know, driving at simplicity. So, sometimes, like, you see this really cool problem, and there's a really cool way to solve it. But if you can solve it, you mentioned, like, being conservative with the type of frameworks maybe you used in a previous company, like, solve it in the most simple way, and you'll thank yourself later. Because, at some point, you have to come back to it, and maintain it, change it. Yeah, so it makes a lot of sense. And, Marc, you said you started when you were 7, which is really young. Through that amount of time, you've probably seen massive changes in the way websites look, feel, and how they work. In that time, what's the biggest change you actually think you've seen? MARC: The biggest thing I saw is, when I started, internet didn't exist or at least wasn't available. Like, I remember being at school and the teacher would ask like, "How many people have a computer at home?" And we'd be like, two or three people. So, people didn't have internet until I was like 14, 15, I'd say. So, that's the biggest one. But, let's say, after it started, they just got more complicated. Like, so, the complexity is getting crazy. Like, I remember, at some point, where I saw I think it was called Aviary. It was basically Photoshop in the browser, and I was just insanely impressed by just the fact that you could do this in the browser. And, nowadays, like, you've got Figma, and you've got so many tools that are insanely impressive. Back then, it was just text, images, and that's it. I actually wrote a blog post a few years ago about how I used to build websites just using frames. So, I don't know if you're familiar with just frames, but I didn't really know how to do divs. So, I would just do frames because that's what I understood back then, again, little kid. But it was kind of working. You were dealing with IE 5 or, like, I remember, like, professionally fixing bugs for IE 5.5 or, like, AOL, like, 9, something ridiculous like this. So, building a website just got way easier but also way more complicated, if that makes sense. Like, it's way easier to do most things. For instance, I don't know, like, 20 years ago, you wanted a rounded corner; you would have to create images and kind of overlay them in a weird way. It would break in many cases. Nowadays, you want rounded corners? That's a non-topic. But now you need, like, offline capabilities of your website. And, in a lot of cases, there's really complex features that are expected from users. So, the bar is getting raised to crazy levels. SAMI: Yeah, I always wonder about this. Like, when you look at how the internet used to be and how people develop for the internet, and, like you're saying, now it's more complex but easier to do some things. I don't know if as developers we're making things harder or easier for ourselves. Like, if you look at the amount of technology someone needs to know to get started, it grows constantly. To do this, you have to add this framework, and you need to have this library, and maybe even a different language, and then, to even host something now, the amount of technologies you need to know. Do you think we're making things harder for ourselves, or do you think easier? MARC: Well, I guess there's always back and forth, like, regarding complexity. So, things will get really, really complex, and then someone will go, "Well, let's stop that and simplify." That's why, like, I'm seeing some people not rejecting React and so on, but going a simpler route like Rails has options like this. There's people using HTMX, which is really simple. So, just going back to something simpler. I think a lot of the really complex solutions also come from the fact that now we have massive teams building websites, and you need that complexity to be able to handle the team size. But it's kind of, then you need more people to handle the complexity, and it's just getting crazy. Yeah, honestly, I don't know. I'm seeing a lot of things that feel too complex for...like, the technology feels really complicated to accomplish some things that should be simple or at least feel simple. But, at the same time, there are things that got so simple that it's ridiculous like just accepting payment. I remember, like, if you wanted to accept payment on a site, it would be months of work, and now it takes a minute. You just plug in Stripe, and it works. And it's often cheaper than what it used to be. So, it's kind of...or deploying. You mentioned deploying can be really hard. Well, you don't need to have a physical server in your room just eating your place up to have your website, your personal website running. You just push it to Vercel, or Heroku, or whatever, or just a static page on S3. So, this got simpler, but then, yeah, you can get it to be so much more crazy. So, if you host your static website on S3, fairly simple. But then if you try to understand permissions on S3, then, you know, it's over. RÉMY: I don't know if it's really in the path of our discussion. I just wanted to ask you, so this is the on tour series, where we...so, usually, the Giant Robots podcast used to be a little bit more American-centric, and this on tour is moving back to the other side of the Atlantic with, again, Europe, West Asia, and Africa. You've been part of a company, Drivy, which expanded from France to neighboring countries in Europe. What could you tell our listeners about how to expand a business internationally? MARC: That's a tough question, especially in Europe. Because I know looking from the outside, like, if you're from the U.S. and you look at Europe, it feels like, you know, a uniform continent, but really, it's very different. Like, just payment methods are different. Culture is very different. For instance, when I was working at Back Market in France, one of the branding aspects of Back Market was its humor. Like, we would be making a lot of jokes on the website, and it would work really well in France. Like, people would love the brand. But then you expand to other countries, and they just don't find that funny at all. Like, it's not helping at all, and they're expecting a different tone of voice. So, it's not just, okay, I need to translate my own page; it's I need to internationalize for this market. I guess my advice is do it country by country. Sometimes I see companies going like, oh, we opened in 20 different countries, and you go, how even do you do that? And spend some time understanding how people are using your product or, like, a similar product locally because you would be surprised by what you learn. Sometimes there's different capabilities. For instance, when Drivy went to the UK, there's so much more you can learn. There's the government database that you can look up, and it really helps with managing risk. If people are known to steal cars, you can kind of figure it out. I'm simplifying a bit, but you can use this. You don't have that in France because we just don't have this solution. But if you go to Nordic countries, for instance, they have way more electric vehicles, so maybe the product doesn't work as well. So, it's really understanding what's different locally and being willing to invest, to adapt. Because if you go, okay, I'm going to open in the Netherlands but you don't adopt the payment methods that are used in the Netherlands, you might as well not open at all. So, it's either you do it properly and you kind of figure out what properly means for your product, or you postpone, and you do it well later. Like, right now, I'm struggling a bit with my app because it's open. So, it's on the App Store, so it's open globally. And it's a SaaS, so it's simpler, but I struggle with language. So, it's in French and English. I spoke both of this language, obviously, French better than English. But I think I'm doing okay with both. But I also built it in Spanish because I speak some Spanish fairly poorly, and I wanted to try to hit a different market like the Mexican market that are doing boxing quite a lot. But the quality doesn't seem there. Like, I don't have the specific boxing lingo, so I'm contemplating just rolling it back, like, removing the Spanish language until I get it really well, maybe with a translator dedicated to it that knows boxing in Spanish. Because I work with translators that would translate, but they don't really know that, yeah, like a jab in boxing. In Spanish, they might also say, "Jab." They won't translate it to, like, [inaudible 38:31]. SAMI: Yeah. At thoughtbot, we have one of our clients they wanted to release their app also internationally. And so, we had also kind of a lot of these problems. We even had to handle...so, in some languages, you go from left to right, right to left. So, that kind of also changed a lot of the way you would design things is mainly for people who are going from left to right. I mean, that's thinking kind of more Europe, U.S.-centric. And then, you could be releasing your app into a different country where they read the other direction. So, yeah, a lot of this stuff is really interesting, especially the culture, like you're saying. Do they find this humor funny? And then, how do they translate things? Which, in my head, I think, could you use AI to do that. Which is a nice segue into, like, the mandatory question about AI, which we can't let you go until we ask you. MARC: [laughs] SAMI: So, okay, obviously, I'm going to ask you about your thoughts on AI and where you think we're headed. But I've seen something interesting, which I don't know if this is something that resonates with you as well. I've seen a bit of a trend where the more experienced developers or more senior developers I talk to seem to be a bit more calm and less concerned. Whereas I would consider myself as less experienced, and I feel, like, kind of more anxious, more nervous, more jumping on the bandwagon sort of feeling of keeping an eye on it. So, I guess, with your experience, what are your thoughts on AI? Where do you think we are headed? MARC: That's a big question, and it feels like it's changing month to month. It feels way more interesting than other trends before. Like, I'm way more excited about the capabilities of AI than, like, NFTs or stuff like this. I'm actively using AI tooling in my app. I was using some AI at Back Market. So, it's interesting. There's a bunch of things you can be doing. Personally, I don't think that it's going to, like, make programming irrelevant, for instance. It will just change a bit how you will build things just like...so, we talked about what changed in the past. For instance, at some point, you would need a team of people moving around physical computers and servers and just hooking them up to be able to have a website. But now, most people would just use a cloud provider. So, all those people either they work for the cloud provider, or they're out of a job. But really what happened is most shifted into something different, and then we focused on something different. Instead of learning how to handle a farm of servers, we learned how to, I don't know, handle more concurrency in our models. And I think when I look back, I feel like, technically, maybe, I don't know, 70%, 80% of what I learned is now useless. Like, I spent years getting really good at handling Internet Explorer as a web developer. Now it's just gone, so it's just gone forever. And it feels like there's some practice that we're having right now that will be gone forever thanks to AI or because of AI, depending on how you look at it. But then there'll be new things to do. I'm not sure yet what it will be, but it will create new opportunities. There are some things that look a bit scary, like, or creepy. But I'm not worried about jobs or things like this. I'm a bit concerned about people learning programming right now because, yeah, there's a lot of hand-holding, and there's a lot of tools that you have to pay to get access to this hand-holding. So, if you're a student right now in school learning programming and your school is giving you some AI assistant, like Copilot or whatever, and this assistant is really good, but suddenly it goes away because you're not paying anymore, or, like, the model change, if you don't know how to code anymore, then it's a problem. Or maybe you're not struggling as much. And you're not digging deep enough, and so you're learning slower. And you're being a bit robbed of the opportunity to learn by the AI. So, it's just giving you the solution. But it's just, like, the way I use it right now, so I don't have an assistant enabled, but I usually have, like, a ChatGPT window open somewhere. It's more like a better Stack Overflow or a more precise Stack Overflow. And that helps me a lot, and that's really convenient. Like, right now, I'm building mostly using Swift and Swift UI, but I'm mainly a Ruby and JavaScript developer. So, I'm struggling a lot and being able to ask really simple questions. I had a case just this morning where I asked how to handle loading of images without using the assets folder in Xcode. I just couldn't figure it out, but it's really simple. So, it was able to tell me, like, right away, like, five options on how to do it, and I was able to pick the one that would fit. So, yeah, really interesting, but yeah, I'm not that worried. The only part I would be worried is if people are learning right now and relying way too much on AI. RÉMY: Well, at least it's positive for our job. Thank you for making us believe in a bright future, Marc. MARC: [laughs] RÉMY: All right. Thank you so much, Marc, for joining us. It was a real pleasure. Before we leave, Marc, if you want to be contacted, if people want to get a hold of you, how can you be contacted? MARC: There's two ways: either LinkedIn, look up Marc G Gauthier. Like, the middle initial is important because Marc Gauthier is basically John Smith in France. My website, which is marcgg.com. You can find my blog. You can find a way to hire me as a coach or advisor. That's the best way to reach out to me. RÉMY: Thank you so much. And thank you, Sami, as well. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, you can email us at hosts@giantrobots.fm. You can find me on social media as rhannequin. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.  AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

What groundbreaking features are making waves with Salesforce Data Cloud this summer? Join us for a conversation with Danielle Larregui as she walks us through the latest advancements in the Summer '24 release. We discuss the innovative ability to virtualize data model objects on account records and the extended reach of Enrichments to include more standard and custom objects. Plus, Danielle introduces new connectors like the Heroku Postgres connector for seamless data integration from Heroku to Data Cloud. And that's not all! We also caught up with René to talk about the buzz surrounding the AI Now Tour. These tours are a fantastic opportunity for those eager to get hands-on with Einstein and Data Cloud. Happy listening! Show Highlights: Detailed discussion on Data Cloud's new functionalities, including virtualizing data model objects on account records Expansion of Enrichments to more standard and custom objects New connectors, specifically highlighting the Heroku Postgres connector for seamless data integration Feature Manager in Data Cloud setup, enabling access to beta connectors Links: Data Cloud Connectors Overview - https://help.salesforce.com/s/articleView?id=sf.c360_a_sources_targets.htm&type=5 Why the Heroku PostgreSQL Connector for Data Cloud is Important for Developers - https://developer.salesforce.com/blogs/2024/06/heroku-postgres-connector-for-data-cloud AI NOW Tour - https://developer.salesforce.com/ai-now-tour 

The future of coding. We will discuss the competitive AI landscape, NVIDIA and the hyperscalers, specialized versus generalized models, synthetic data, software that writes itself, and the future of software development. Jason Warner is co-founder and CEO of Poolside. Poolside is an AI startup challenging OpenAI and Anthropic by creating its own models to build the most capable AI for software development. Although less than two years old and launching this summer, Poolside has already raised over $500M from leading investors such as Redpoint, Bain, and DST. Jason was previously the CTO at GitHub, the world's largest developer platform, both before and after Microsoft's $7.5B acquisition, where he helped develop Co-pilot. Prior to that, he was the Head of Engineering at Heroku and a senior technical leader at numerous other companies. In addition to leading top software development teams, Jason served as a General Partner at Redpoint Ventures, who have invested in companies like Snowflake, Stripe, Hashicorp, and Netflix. He also sits on the Operator Board at Bridgewater Associates, helping them innovate at the technology frontier. Subscribe for the latest episodes. Email me on danieldarling@focal.vcSee omnystudio.com/listener for privacy information.

Today Laura and Kevin speak with Francis Lacoste.  Francis is an Engineering Leadership Coach who helps CTOs and VPs of Engineering at scaling tech startups nurture amazing work cultures and high-performance teams that build products and services that delight their customers.Until early 2023, Francis was the Senior Director of Software Engineering, Culture, and Engagement at Salesforce, where he coached top engineering managers to be better leaders as they helped grow the company and build a culture of collaboration and innovation across the Salesforce Platform engineering division with 1200 people.He has spent 25+ years working from home in the open-source and cloud developer tools industry and also previously worked at Heroku and Canonical, where he built successful high-performance remote engineering teams.

What if you could use the power of artificial intelligence (AI) to transform your business operations? In this episode, we welcome Dave Norris to discuss the profound impact of Salesforce's strategic acquisitions — such as ExactTarget, Pardot, Heroku, and Slack — on the developer ecosystem. We cover the intricacies of integrating diversified data systems and emphasize the importance of centralized data management through MuleSoft. We'll explore how Data Cloud handles structured and unstructured data, enhancing AI functionalities with tools like Prompt Builder and the newly released Data Cloud Vector Search. This episode sheds light on how grounding AI with enterprise-specific information can significantly boost productivity and deliver accurate, context-rich responses. Listen in for a detailed description of data and AI within the Salesforce ecosystem! Show Highlights: Centralizing data with MuleSoft and the role of Data Cloud in data ingestion, mapping, and security Using AI capabilities like Einstein AI within the Salesforce ecosystem Integrating structured and unstructured data using Data Cloud for enhanced AI functionality Practical insights and use cases, including predictive AI in animal adoption data General availability of Data Cloud Vector Search and its impact on semantic searching Enhancing enterprise productivity by grounding AI with specific enterprise data for more accurate responses Links: Data Cloud + Einstein AI: The Developer's Pocket Guide - https://developer.salesforce.com/blogs/2024/05/data-cloud-einstein-ai-the-developers-pocket-guide Bring Your Own Large Language Model in Einstein 1 Studio - https://developer.salesforce.com/blogs/2024/03/bring-your-own-large-language-model-in-einstein-1-studio

Editor's note: One of the top reasons we have hundreds of companies and thousands of AI Engineers joining the World's Fair next week is, apart from discussing technology and being present for the big launches planned, to hire and be hired! Listeners loved our previous Elicit episode and were so glad to welcome 2 more members of Elicit back for a guest post (and bonus podcast) on how they think through hiring. Don't miss their AI engineer job description, and template which you can use to create your own hiring plan! How to Hire AI EngineersJames Brady, Head of Engineering @ Elicit (ex Spring, Square, Trigger.io, IBM)Adam Wiggins, Internal Journalist @ Elicit (Cofounder Ink & Switch and Heroku)If you're leading a team that uses AI in your product in some way, you probably need to hire AI engineers. As defined in this article, that's someone with conventional engineering skills in addition to knowledge of language models and prompt engineering, without being a full-fledged Machine Learning expert.But how do you hire someone with this skillset? At Elicit we've been applying machine learning to reasoning tools since 2018, and our technical team is a mix of ML experts and what we can now call AI engineers. This article will cover our process from job description through interviewing. (You can also flip the perspectives here and use it just as easily for how to get hired as an AI engineer!)My own journeyBefore getting into the brass tacks, I want to share my journey to becoming an AI engineer.Up until a few years ago, I was happily working my job as an engineering manager of a big team at a late-stage startup. Like many, I was tracking the rapid increase in AI capabilities stemming from the deep learning revolution, but it was the release of GPT-3 in 2020 which was the watershed moment. At the time, we were all blown away by how the model could string together coherent sentences on demand. (Oh how far we've come since then!)I'd been a professional software engineer for nearly 15 years—enough to have experienced one or two technology cycles—but I could see this was something categorically new. I found this simultaneously exciting and somewhat disconcerting. I knew I wanted to dive into this world, but it seemed like the only path was going back to school for a master's degree in Machine Learning. I started talking with my boss about options for taking a sabbatical or doing a part-time distance learning degree.In 2021, I instead decided to launch a startup focused on productizing new research ideas on ML interpretability. It was through that process that I reached out to Andreas—a leading ML researcher and founder of Elicit—to see if he would be an advisor. Over the next few months, I learned more about Elicit: that they were trying to apply these fascinating technologies to the real-world problems of science, and with a business model that aligned it with safety goals. I realized that I was way more excited about Elicit than I was about my own startup ideas, and wrote about my motivations at the time.Three years later, it's clear this was a seismic shift in my career on the scale of when I chose to leave my comfy engineering job at IBM to go through the Y Combinator program back in 2008. Working with this new breed of technology has been more intellectually stimulating, challenging, and rewarding than I could have imagined.Deep ML expertise not requiredIt's important to note that AI engineers are not ML experts, nor is that their best contribution to a tech team.In our article Living documents as an AI UX pattern, we wrote:It's easy to think that AI advancements are all about training and applying new models, and certainly this is a huge part of our work in the ML team at Elicit. But those of us working in the UX part of the team believe that we have a big contribution to make in how AI is applied to end-user problems.We think of LLMs as a new medium to work with, one that we've barely begun to grasp the contours of. New computing mediums like GUIs in the 1980s, web/cloud in the 90s and 2000s, and multitouch smartphones in the 2000s/2010s opened a whole new era of engineering and design practices. So too will LLMs open new frontiers for our work in the coming decade.To compare to the early era of mobile development: great iOS developers didn't require a detailed understanding of the physics of capacitive touchscreens. But they did need to know the capabilities and limitations of a multi-touch screen, the constrained CPU and storage available, the context in which the user is using it (very different from a webpage or desktop computer), etc.In the same way, an AI engineer needs to work with LLMs as a medium that is fundamentally different from other compute mediums. That means an interest in the ML side of things, whether through their own self-study, tinkering with prompts and model fine-tuning, or following along in #llm-paper-club. But this understanding is so that they can work with the medium effectively versus, say, spending their days training new models.Language models as a chaotic mediumSo if we're not expecting deep ML expertise from AI engineers, what are we expecting? This brings us to what makes LLMs different.We'll assume already that our ideal candidate is already inspired by, and full of ideas about, all the new capabilities AI can bring to software products. But the flip side is all the things that make this new medium difficult to work with. LLM calls are annoying due to high latency (measured in tens of seconds sometimes, rather than milliseconds), extreme variance on latency, high error rates even under normal operation. Not to mention getting extremely different answers to the same prompt provided to the same model on two subsequent calls!The net effect is that an AI engineer, even working at the application development level, needs to have a skillset comparable to distributed systems engineering. Handling errors, retries, asynchronous calls, streaming responses, parallelizing and recombining model calls, the halting problem, and fallbacks are just some of the day-in-the-life of an AI engineer. Chaos engineering gets new life in the era of AI.Skills and qualities in candidatesLet's put together what we don't need (deep ML expertise) with what we do (work with capabilities and limitations of the medium). Thus we start to see what Elicit looks for in AI engineers:* Conventional software engineering skills. Especially back-end engineering on complex, data-intensive applications.* Professional, real-world experience with applications at scale.* Deep, hands-on experience across a few back-end web frameworks.* Light devops and an understanding of infrastructure best practices.* Queues, message buses, event-driven and serverless architectures, … there's no single “correct” approach, but having a deep toolbox to draw from is very important.* A genuine curiosity and enthusiasm for the capabilities of language models.* One or more serious projects (side projects are fine) of using them in interesting ways on a unique domain.* …ideally with some level of factored cognition, e.g. breaking the problem down into chunks, making thoughtful decisions about which things to push to the language model and which stay within the realm of conventional heuristics and compute capabilities.* Personal studying with resources like Elicit's ML reading list. Part of the role is collaborating with the ML engineers and researchers on our team. To do so, the candidate needs to “speak their language” somewhat, just as a mobile engineer needs some familiarity with backends in order to collaborate effectively on API creation with backend engineers.* An understanding of the challenges that come along with working with large models (high latency, variance, etc.) leading to a defensive, fault-first mindset.* Careful and principled handling of error cases, asynchronous code (and ability to reason about and debug it), streaming data, caching, logging and analytics for understanding behavior in production.* This is a similar mindset that one can develop working on conventional apps which are complex, data-intensive, or large-scale apps. The difference is that an AI engineer will need this mindset even when working on relatively small scales!On net, a great AI engineer will combine two seemingly contrasting perspectives: knowledge of, and a sense of wonder for, the capabilities of modern ML models; but also the understanding that this is a difficult and imperfect foundation, and the willingness to build resilient and performant systems on top of it.Here's the resulting AI engineer job description for Elicit. And here's a template that you can borrow from for writing your own JD.Hiring processOnce you know what you're looking for in an AI engineer, the process is not too different from other technical roles. Here's how we do it, broken down into two stages: sourcing and interviewing.SourcingWe're primarily looking for people with (1) a familiarity with and interest in ML, and (2) proven experience building complex systems using web technologies. The former is important for culture fit and as an indication that the candidate will be able to do some light prompt engineering as part of their role. The latter is important because language model APIs are built on top of web standards and—as noted above—aren't always the easiest tools to work with.Only a handful of people have built complex ML-first apps, but fortunately the two qualities listed above are relatively independent. Perhaps they've proven (2) through their professional experience and have some side projects which demonstrate (1).Talking of side projects, evidence of creative and original prototypes is a huge plus as we're evaluating candidates. We've barely scratched the surface of what's possible to build with LLMs—even the current generation of models—so candidates who have been willing to dive into crazy “I wonder if it's possible to…” ideas have a huge advantage.InterviewingThe hard skills we spend most of our time evaluating during our interview process are in the “building complex systems using web technologies” side of things. We will be checking that the candidate is familiar with asynchronous programming, defensive coding, distributed systems concepts and tools, and display an ability to think about scaling and performance. They needn't have 10+ years of experience doing this stuff: even junior candidates can display an aptitude and thirst for learning which gives us confidence they'll be successful tackling the difficult technical challenges we'll put in front of them.One anti-pattern—something which makes my heart sink when I hear it from candidates—is that they have no familiarity with ML, but claim that they're excited to learn about it. The amount of free and easily-accessible resources available is incredible, so a motivated candidate should have already dived into self-study.Putting all that together, here's the interview process that we follow for AI engineer candidates:* 30-minute introductory conversation. Non-technical, explaining the interview process, answering questions, understanding the candidate's career path and goals.* 60-minute technical interview. This is a coding exercise, where we play product manager and the candidate is making changes to a little web app. Here are some examples of topics we might hit upon through that exercise:* Update API endpoints to include extra metadata. Think about appropriate data types. Stub out frontend code to accept the new data.* Convert a synchronous REST API to an asynchronous streaming endpoint.* Cancellation of asynchronous work when a user closes their tab.* Choose an appropriate data structure to represent the pending, active, and completed ML work which is required to service a user request.* 60–90 minute non-technical interview. Walk through the candidate's professional experience, identifying high and low points, getting a grasp of what kinds of challenges and environments they thrive in.* On-site interviews. Half a day in our office in Oakland, meeting as much of the team as possible: more technical and non-technical conversations.The frontier is wide openAlthough Elicit is perhaps further along than other companies on AI engineering, we also acknowledge that this is a brand-new field whose shape and qualities are only just now starting to form. We're looking forward to hearing how other companies do this and being part of the conversation as the role evolves.We're excited for the AI Engineer World's Fair as another next step for this emerging subfield. And of course, check out the Elicit careers page if you're interested in joining our team.Podcast versionTimestamps* [00:00:24] Intros* [00:05:25] Defining the Hiring Process* [00:08:42] Defensive AI Engineering as a chaotic medium* [00:10:26] Tech Choices for Defensive AI Engineering* [00:14:04] How do you Interview for Defensive AI Engineering* [00:19:25] Does Model Shadowing Work?* [00:22:29] Is it too early to standardize Tech stacks?* [00:32:02] Capabilities: Offensive AI Engineering* [00:37:24] AI Engineering Required Knowledge* [00:40:13] ML First Mindset* [00:45:13] AI Engineers and Creativity* [00:47:51] Inside of Me There Are Two Wolves* [00:49:58] Sourcing AI Engineers* [00:58:45] Parting ThoughtsTranscript[00:00:00] swyx: Okay, so welcome to the Latent Space Podcast. This is another remote episode that we're recording. This is the first one that we're doing around a guest post. And I'm very honored to have two of the authors of the post with me, James and Adam from Elicit. Welcome, James. Welcome, Adam.[00:00:22] James Brady: Thank you. Great to be here.[00:00:23] Hey there.[00:00:24] Intros[00:00:24] swyx: Okay, so I think I will do this kind of in order. I think James, you're, you're sort of the primary author. So James, you are head of engineering at Elicit. You also, We're VP Eng at Teespring and Spring as well. And you also , you have a long history in sort of engineering. How did you, , find your way into something like Elicit where, , it's, you, you are basically traditional sort of VP Eng, VP technology type person moving into a more of an AI role.[00:00:53] James Brady: Yeah, that's right. It definitely was something of a Sideways move if not a left turn. So the story there was I'd been doing, as you said, VP technology, CTO type stuff for around about 15 years or so, and Notice that there was this crazy explosion of capability and interesting stuff happening within AI and ML and language models, that kind of thing.[00:01:16] I guess this was in 2019 or so, and decided that I needed to get involved. , this is a kind of generational shift. And Spent maybe a year or so trying to get up to speed on the state of the art, reading papers, reading books, practicing things, that kind of stuff. Was going to found a startup actually in in the space of interpretability and transparency, and through that met Andreas, who has obviously been on the, on the podcast before asked him to be an advisor for my startup, and he countered with, maybe you'd like to come and run the engineering team at Elicit, which it turns out was a much better idea.[00:01:48] And yeah, I kind of quickly changed in that direction. So I think some of the stuff that we're going to be talking about today is how actually a lot of the work when you're building applications with AI and ML looks and smells and feels much more like conventional software engineering with a few key differences rather than really deep ML stuff.[00:02:07] And I think that's one of the reasons why I was able to transfer skills over from one place to the other.[00:02:12] swyx: Yeah, I[00:02:12] James Brady: definitely[00:02:12] swyx: agree with that. I, I do often say that I think AI engineering is about 90 percent software engineering with like the, the 10 percent of like really strong really differentiated AI engineering.[00:02:22] And that might, that obviously that number might change over time. I want to also welcome Adam onto my podcast because you welcomed me onto your podcast two years ago.[00:02:31] Adam Wiggins: Yeah, that was a wonderful episode.[00:02:32] swyx: That was, that was a fun episode. You famously founded Heroku. You just wrapped up a few years working on Muse.[00:02:38] And now you've described yourself as a journalist, internal journalist working on Elicit.[00:02:43] Adam Wiggins: Yeah, well I'm kind of a little bit in a wandering phase here and trying to take this time in between ventures to see what's out there in the world and some of my wandering took me to the Elicit team. And found that they were some of the folks who were doing the most interesting, really deep work in terms of taking the capabilities of language models and applying them to what I feel like are really important problems.[00:03:08] So in this case, science and literature search and, and, and that sort of thing. It fits into my general interest in tools and productivity software. I, I think of it as a tool for thought in many ways, but a tool for science, obviously, if we can accelerate that discovery of new medicines and things like that, that's, that's just so powerful.[00:03:24] But to me, it's a. It's kind of also an opportunity to learn at the feet of some real masters in this space, people who have been working on it since it was, before it was cool, if you want to put it that way. So for me, the last couple of months have been this crash course, and why I sometimes describe myself as an internal journalist is I'm helping to write some, some posts, including Supporting James in this article here we're doing for latent space where I'm just bringing my writing skill and that sort of thing to bear on their very deep domain expertise around language models and applying them to the real world and kind of surface that in a way that's I don't know, accessible, legible, that, that sort of thing.[00:04:03] And so, and the great benefit to me is I get to learn this stuff in a way that I don't think I would, or I haven't, just kind of tinkering with my own side projects.[00:04:12] swyx: I forgot to mention that you also run Ink and Switch, which is one of the leading research labs, in my mind, of the tools for thought productivity space, , whatever people mentioned there, or maybe future of programming even, a little bit of that.[00:04:24] As well. I think you guys definitely started the local first wave. I think there was just the first conference that you guys held. I don't know if you were personally involved.[00:04:31] Adam Wiggins: Yeah, I was one of the co organizers along with a few other folks for, yeah, called Local First Conf here in Berlin.[00:04:36] Huge success from my, my point of view. Local first, obviously, a whole other topic we can talk about on another day. I think there actually is a lot more what would you call it , handshake emoji between kind of language models and the local first data model. And that was part of the topic of the conference here, but yeah, topic for another day.[00:04:55] swyx: Not necessarily. I mean , I, I selected as one of my keynotes, Justine Tunney, working at LlamaFall in Mozilla, because I think there's a lot of people interested in that stuff. But we can, we can focus on the headline topic. And just to not bury the lead, which is we're talking about hire, how to hire AI engineers, this is something that I've been looking for a credible source on for months.[00:05:14] People keep asking me for my opinions. I don't feel qualified to give an opinion and it's not like I have. So that's kind of defined hiring process that I'm super happy with, even though I've worked with a number of AI engineers.[00:05:25] Defining the Hiring Process[00:05:25] swyx: I'll just leave it open to you, James. How was your process of defining your hiring, hiring roles?[00:05:31] James Brady: Yeah. So I think the first thing to say is that we've effectively been hiring for this kind of a role since before you, before you coined the term and tried to kind of build this understanding of what it was.[00:05:42] So, which is not a bad thing. Like it's, it was a, it was a good thing. A concept, a concept that was coming to the fore and effectively needed a name, which is which is what you did. So the reason I mentioned that is I think it was something that we kind of backed into, if you will. We didn't sit down and come up with a brand new role from, from scratch of this is a completely novel set of responsibilities and skills that this person would need.[00:06:06] However, it is a A kind of particular blend of different skills and attitudes and and curiosities interests, which I think makes sense to kind of bundle together. So in the, in the post, the three things that we say are most important for a highly effective AI engineer are first of all, conventional software engineering skills, which is Kind of a given, but definitely worth mentioning.[00:06:30] The second thing is a curiosity and enthusiasm for machine learning and maybe in particular language models. That's certainly true in our case. And then the third thing is to do with basically a fault first mindset, being able to build systems that can handle things going wrong in, in, in some sense.[00:06:49] And yeah, the I think the kind of middle point, the curiosity about ML and language models is probably fairly self evident. They're going to be working with, and prompting, and dealing with the responses from these models, so that's clearly relevant. The last point, though, maybe takes the most explaining.[00:07:07] To do with this fault first mindset and the ability to, to build resilient systems. The reason that is, is so important is because compared to normal APIs, where normal, think of something like a Stripe API or a search API or something like this. The latency when you're working with language models is, is wild, like you can get 10x variation.[00:07:32] I mean, I was looking at the stats before, actually, before, before the podcast. We do often, normally, in fact, see a 10x variation in the P90 latency over the course of, Half an hour, an hour when we're prompting these models, which is way higher than if you're working with a, more kind of conventional conventionally backed API.[00:07:49] And the responses that you get, the actual content and the responses are naturally unpredictable as well. They come back with different formats. Maybe you're expecting JSON. It's not quite JSON. You have to handle this stuff. And also the, the semantics of the messages are unpredictable too, which is, which is a good thing.[00:08:08] Like this is one of the things that you're looking for from these language models, but it all adds up to needing to. Build a resilient, reliable, solid feeling system on top of this fundamentally, well, certainly currently fundamentally shaky foundation. The models do not behave in the way that you would like them to.[00:08:28] And yeah, the ability to structure the code around them such that it does give the user this warm, reassuring, Snappy, solid feeling is is really what we're driving for there.[00:08:42] Defensive AI Engineering as a chaotic medium[00:08:42] Adam Wiggins: What really struck me as we, we dug in on the content for this article was that third point there. The, the language models is this kind of chaotic medium, this, this dragon, this wild horse you're, you're, you're riding and trying to guide in the direction that is going to be useful and reliable to users, because I think.[00:08:58] So much of software engineering is about making things not only high performance and snappy, but really just making it stable, reliable, predictable, which is literally the opposite of what you get from from the language models. And yet, yeah, the output is so useful, and indeed, some of their Creativity, if you want to call it that, which is, is precisely their value.[00:09:19] And so you need to work with this medium. And I guess the nuanced or the thing that came out of Elissa's experience that I thought was so interesting is quite a lot of working with that is things that come from distributed systems engineering. But you have really the AI engineers as we're defining them or, or labeling them on the illicit team is people who are really application developers.[00:09:39] You're building things for end users. You're thinking about, okay, I need to populate this interface with some response to user input. That's useful to the tasks they're trying to do, but you have this. This is the thing, this medium that you're working with that in some ways you need to apply some of this chaos engineering, distributed systems engineering, which typically those people with those engineering skills are not kind of the application level developers with the product mindset or whatever, they're more deep in the guts of a, of a system.[00:10:07] And so it's, those, those skills and, and knowledge do exist throughout the engineering discipline, but sort of putting them together into one person that is That feels like sort of a unique thing and working with the folks on the Elicit team who have that skills I'm quite struck by that unique that unique blend.[00:10:23] I haven't really seen that before in my 30 year career in technology.[00:10:26] Tech Choices for Defensive AI Engineering[00:10:26] swyx: Yeah, that's a Fascinating I like the reference to chaos engineering. I have some appreciation, I think when you had me on your podcast, I was still working at Temporal and that was like a nice Framework, if you live within Temporal's boundaries, you can pretend that all those faults don't exist, and you can, you can code in a sort of very fault tolerant way.[00:10:47] What is, what is you guys solutions around this, actually? Like, I think you're, you're emphasizing having the mindset, but maybe naming some technologies would help? Not saying that you have to adopt these technologies, but they're just, they're just quick vectors into what you're talking about when you're, when you're talking about distributed systems.[00:11:03] Like, that's such a big, chunky word, , like are we talking, are Kubernetes or, and I suspect we're not, , like we're, we're talking something else now.[00:11:10] James Brady: Yeah, that's right. It's more at the application level rather than at the infrastructure level, at least, at least the way that it works for us.[00:11:17] So there's nothing kind of radically novel here. It is more a careful application of existing concepts. So the kinds of tools that we reach for to handle these kind of slightly chaotic objects that Adam was just talking about, are retries and fallbacks and timeouts and careful error handling. And, yeah, the standard stuff, really.[00:11:39] There's also a great degree of dependence. We rely heavily on parallelization because, , these language models are not innately very snappy, and , there's just a lot of I. O. going back and forth. So All these things I'm talking about when I was in my earlier stages of a career, these are kind of the things that are the difficult parts that most senior software engineers will be better at.[00:12:01] It is careful error handling, and concurrency, and fallbacks, and distributed systems, and, , eventual consistency, and all this kind of stuff and As Adam was saying, the kind of person that is deep in the guts of some kind of distributed systems, a really high, high scale backend kind of a problem would probably naturally have these kinds of skills.[00:12:21] But you'll find them on, on day one, if you're building a, , an ML powered app, even if it's not got massive scale. I think one one thing that I would mention that we do do yeah, maybe, maybe two related things, actually. The first is we're big fans of strong typing. We share the types all the way from the Backend Python code all the way to the to the front end in TypeScript and find that is I mean We'd probably do this anyway But it really helps one reason around the shapes of the data which can going to be going back and forth and that's really important When you can't rely upon You you're going to have to coerce the data that you get back from the ML if you want if you want for it to be structured basically speaking and The second thing which is related is we use checked exceptions inside our Python code base, which means that we can use the type system to make sure we are handling, properly handling, all of the, the various things that could be going wrong, all the different exceptions that could be getting raised.[00:13:16] So, checked exceptions are not, not really particularly popular. Actually there's not many people that are big fans of them. For our particular use case, to really make sure that we've not just forgotten to handle, , This particular type of error we have found them useful to to, to force us to think about all the different edge cases that can come up.[00:13:32] swyx: Fascinating. How just a quick note of technology. How do you share types from Python to TypeScript? Do you, do you use GraphQL? Do you use something[00:13:39] James Brady: else? We don't, we don't use GraphQL. Yeah. So we've got the We've got the types defined in Python, that's the source of truth. And we go from the OpenAPI spec, and there's a, there's a tool that you work and use to generate types dynamically, like TypeScript types from those OpenAPI definitions.[00:13:57] swyx: Okay, excellent. Okay, cool. Sorry, sorry for diving into that rabbit hole a little bit. I always like to spell out technologies for people to dig their teeth into.[00:14:04] How do you Interview for Defensive AI Engineering[00:14:04] swyx: One thing I'll, one thing I'll mention quickly is that a lot of the stuff that you mentioned is typically not part of the normal interview loop.[00:14:10] It's actually really hard to interview for because this is the stuff that you polish out in, as you go into production, the coding interviews are typically about the happy path. How do we do that? How do we, how do we design, how do you look for a defensive fault first mindset?[00:14:24] Because you can defensive code all day long and not add functionality. to your to your application.[00:14:29] James Brady: Yeah, it's a great question and I think that's exactly true. Normally the interview is about the happy path and then there's maybe a box checking exercise at the end of the candidate says of course in reality I would handle the edge cases or something like this and that unfortunately isn't isn't quite good enough when when the happy path is is very very narrow and yeah there's lots of weirdness on either side so basically speaking, it's just a case of, of foregrounding those kind of concerns through the interview process.[00:14:58] It's, there's, there's no magic to it. We, we talk about this in the, in the po in the post that we're gonna be putting up on, on Laton space. The, there's two main technical exercises that we do through our interview process for this role. The first is more coding focus, and the second is more system designy.[00:15:16] Yeah. White whiteboarding a potential solution. And in, without giving too much away in the coding exercise. You do need to think about edge cases. You do need to think about errors. The exercise consists of adding features and fixing bugs inside the code base. And in both of those two cases, it does demand, because of the way that we set the application up and the interview up, it does demand that you think about something other than the happy path.[00:15:41] But your thinking is the right prompt of how do we get the candidate thinking outside of the, the kind of normal Sweet spot, smooth smooth, smoothly paved path. In terms of the system design interview, that's a little easier to prompt this kind of fault first mindset because it's very easy in that situation just to say, let's imagine that, , this node dies, how does the app still work?[00:16:03] Let's imagine that this network is, is going super slow. Let's imagine that, I don't know, like you, you run out of, you run out of capacity in, in, in this database that you've sketched out here, how do you handle that, that, that sort of stuff. So. It's, in both cases, they're not firmly anchored to and built specifically around language models and ways language models can go wrong, but we do exercise the same muscles of thinking defensively and yeah, foregrounding the edge cases, basically.[00:16:32] Adam Wiggins: James, earlier there you mentioned retries. And this is something that I think I've seen some interesting debates internally about things regarding, first of all, retries are, can be costly, right? In general, this medium, in addition to having this incredibly high variance and response rate, and, , being non deterministic, is actually quite expensive.[00:16:50] And so, in many cases, doing a retry when you get a fail does make sense, but actually that has an impact on cost. And so there is Some sense to which, at least I've seen the AI engineers on our team, worry about that. They worry about, okay, how do we give the best user experience, but balance that against what the infrastructure is going to, , is going to cost our company, which I think is again, an interesting mix of, yeah, again, it's a little bit the distributed system mindset, but it's also a product perspective and you're thinking about the end user experience, but also the.[00:17:22] The bottom line for the business, you're bringing together a lot of a lot of qualities there. And there's also the fallback case, which is kind of, kind of a related or adjacent one. I think there was also a discussion on that internally where, I think it maybe was search, there was something recently where there was one of the frontline search providers was having some, yeah, slowness and outages, and essentially then we had a fallback, but essentially that gave people for a while, especially new users that come in that don't the difference, they're getting a They're getting worse results for their search.[00:17:52] And so then you have this debate about, okay, there's sort of what is correct to do from an engineering perspective, but then there's also what actually is the best result for the user. Is giving them a kind of a worse answer to their search result better, or is it better to kind of give them an error and be like, yeah, sorry, it's not working right at the moment, try again.[00:18:12] Later, both are obviously non optimal, but but this is the kind of thing I think that that you run into or, or the kind of thing we need to grapple with a lot more than you would other kinds of, of mediums.[00:18:24] James Brady: Yeah, that's a really good example. I think it brings to the fore the two different things that you could be optimizing for of uptime and response at all costs on one end of the spectrum and then effectively fragility, but kind of, if you get a response, it's the best response we can come up with at the other end of the spectrum.[00:18:43] And where you want to land there kind of depends on, well, it certainly depends on the app, obviously depends on the user. I think it depends on the, feature within the app as well. So in the search case that you, that you mentioned there, in retrospect, we probably didn't want to have the fallback. And we've actually just recently on Monday, changed that to Show an error message rather than giving people a kind of degraded experience in other situations We could use for example a large language model from a large language model from provider B rather than provider A and Get something which is within the A few percentage points performance, and that's just a really different situation.[00:19:21] So yeah, like any interesting question, the answer is, it depends.[00:19:25] Does Model Shadowing Work?[00:19:25] swyx: I do hear a lot of people suggesting I, let's call this model shadowing as a defensive technique, which is, if OpenAI happens to be down, which, , happens more often than people think then you fall back to anthropic or something.[00:19:38] How realistic is that, right? Like you, don't you have to develop completely different prompts for different models and won't the, won't the performance of your application suffer from whatever reason, right? Like it may be caused differently or it's not maintained in the same way. I, I think that people raise this idea of fallbacks to models, but I don't think it's, I don't, I don't see it practiced very much.[00:20:02] James Brady: Yeah, it is, you, you definitely need to have a different prompt if you want to stay within a few percentage points degradation Like I, like I said before, and that certainly comes at a cost, like fallbacks and backups and things like this It's really easy for them to go stale and kind of flake out on you because they're off the beaten track And In our particular case inside of Elicit, we do have fallbacks for a number of kind of crucial functions where it's going to be very obvious if something has gone wrong, but we don't have fallbacks in all cases.[00:20:40] It really depends on a task to task basis throughout the app. So I can't give you a kind of a, a single kind of simple rule of thumb for, in this case, do this. And in the other, do that. But yeah, we've it's a little bit easier now that the APIs between the anthropic models and opening are more similar than they used to be.[00:20:59] So we don't have two totally separate code paths with different protocols, like wire protocols to, to speak, which makes things easier, but you're right. You do need to have different prompts if you want to, have similar performance across the providers.[00:21:12] Adam Wiggins: I'll also note, just observing again as a relative newcomer here, I was surprised, impressed, not sure what the word is for it, at the blend of different backends that the team is using.[00:21:24] And so there's many The product presents as kind of one single interface, but there's actually several dozen kind of main paths. There's like, for example, the search versus a data extraction of a certain type, versus chat with papers, versus And each one of these, , the team has worked very hard to pick the right Model for the job and craft the prompt there, but also is constantly testing new ones.[00:21:48] So a new one comes out from either, from the big providers or in some cases, Our own models that are , running on, on essentially our own infrastructure. And sometimes that's more about cost or performance, but the point is kind of switching very fluidly between them and, and very quickly because this field is moving so fast and there's new ones to choose from all the time is like part of the day to day, I would say.[00:22:11] So it isn't more of a like, there's a main one, it's been kind of the same for a year, there's a fallback, but it's got cobwebs on it. It's more like which model and which prompt is changing weekly. And so I think it's quite, quite reasonable to to, to, to have a fallback that you can expect might work.[00:22:29] Is it too early to standardize Tech stacks?[00:22:29] swyx: I'm curious because you guys have had experience working at both, , Elicit, which is a smaller operation and, and larger companies. A lot of companies are looking at this with a certain amount of trepidation as, as, , it's very chaotic. When you have, when you have , one engineering team that, that, knows everyone else's names and like, , they, they, they, they meet constantly in Slack and knows what's going on.[00:22:50] It's easier to, to sync on technology choices. When you have a hundred teams, all shipping AI products and all making their own independent tech choices. It can be, it can be very hard to control. One solution I'm hearing from like the sales forces of the worlds and Walmarts of the world is that they are creating their own AI gateway, right?[00:23:05] Internal AI gateway. This is the one model hub that controls all the things and has our standards. Is that a feasible thing? Is that something that you would want? Is that something you have and you're working towards? What are your thoughts on this stuff? Like, Centralization of control or like an AI platform internally.[00:23:22] James Brady: Certainly for larger organizations and organizations that are doing things which maybe are running into HIPAA compliance or other, um, legislative tools like that. It could make a lot of sense. Yeah. I think for the TLDR for something like Elicit is we are small enough, as you indicated, and need to have full control over all the levers available and switch between different models and different prompts and whatnot, as Adam was just saying, that that kind of thing wouldn't work for us.[00:23:52] But yeah, I've spoken with and, um, advised a couple of companies that are trying to sell into that kind of a space or at a larger stage, and it does seem to make a lot of sense for them. So, for example, if you're trying to sell If you're looking to sell to a large enterprise and they cannot have any data leaving the EU, then you need to be really careful about someone just accidentally putting in, , the sort of US East 1 GPT 4 endpoints or something like this.[00:24:22] I'd be interested in understanding better what the specific problem is that they're looking to solve with that, whether it is to do with data security or centralization of billing, or if they have a kind of Suite of prompts or something like this that people can choose from so they don't need to reinvent the wheel again and again I wouldn't be able to say without understanding the problems and their proposed solutions , which kind of situations that be better or worse fit for but yeah for illicit where really the The secret sauce, if there is a secret sauce, is which models we're using, how we're using them, how we're combining them, how we're thinking about the user problem, how we're thinking about all these pieces coming together.[00:25:02] You really need to have all of the affordances available to you to be able to experiment with things and iterate rapidly. And generally speaking, whenever you put these kind of layers of abstraction and control and generalization in there, that, that gets in the way. So, so for us, it would not work.[00:25:19] Adam Wiggins: Do you feel like there's always a tendency to want to reach for standardization and abstractions pretty early in a new technology cycle?[00:25:26] There's something comforting there, or you feel like you can see them, or whatever. I feel like there's some of that discussion around lang chain right now. But yeah, this is not only so early, but also moving so fast. , I think it's . I think it's tough to, to ask for that. That's, that's not the, that's not the space we're in, but the, yeah, the larger an organization, the more that's your, your default is to, to, to want to reach for that.[00:25:48] It, it, it's a sort of comfort.[00:25:51] swyx: Yeah, I find it interesting that you would say that , being a founder of Heroku where , you were one of the first platforms as a service that more or less standardized what, , that sort of early developer experience should have looked like.[00:26:04] And I think basically people are feeling the differences between calling various model lab APIs and having an actual AI platform where. , all, all their development needs are thought of for them. , it's, it's very much, and, and I, I defined this in my AI engineer post as well.[00:26:19] Like the model labs just see their job ending at serving models and that's about it. But actually the responsibility of the AI engineer has to fill in a lot of the gaps beyond that. So.[00:26:31] Adam Wiggins: Yeah, that's true. I think, , a huge part of the exercise with Heroku, which It was largely inspired by Rails, which itself was one of the first frameworks to standardize the SQL database.[00:26:42] And people had been building apps like that for many, many years. I had built many apps. I had made my own templates based on that. I think others had done it. And Rails came along at the right moment. We had been doing it long enough that you see the patterns and then you can say look let's let's extract those into a framework that's going to make it not only easier to build for the experts but for people who are relatively new the best practices are encoded into you.[00:27:07] That framework, , Model View Controller, to take one example. But then, yeah, once you see that, and once you experience the power of a framework, and again, it's so comforting, and you can develop faster, and it's easier to onboard new people to it because you have these standards. And this consistency, then folks want that for something new that's evolving.[00:27:29] Now here I'm thinking maybe if you fast forward a little to, for example, when React came on the on the scene, , a decade ago or whatever. And then, okay, we need to do state management. What's that? And then there's, , there's a new library every six months. Okay, this is the one, this is the gold standard.[00:27:42] And then, , six months later, that's deprecated. Because of course, it's evolving, you need to figure it out, like the tacit knowledge and the experience of putting it in practice and seeing what those real What those real needs are are, are critical, and so it's, it is really about finding the right time to say yes, we can generalize, we can make standards and abstractions, whether it's for a company, whether it's for, , a library, an open source library, for a whole class of apps and it, it's very much a, much more of a A judgment call slash just a sense of taste or , experience to be able to say, Yeah, we're at the right point.[00:28:16] We can standardize this. But it's at least my, my very, again, and I'm so new to that, this world compared to you both, but my, my sense is, yeah, still the wild west. That's what makes it so exciting and feels kind of too early for too much. too much in the way of standardized abstractions. Not that it's not interesting to try, but , you can't necessarily get there in the same way Rails did until you've got that decade of experience of whatever building different classes of apps in that, with that technology.[00:28:45] James Brady: Yeah, it's, it's interesting to think about what is going to stay more static and what is expected to change over the coming five years, let's say. Which seems like when I think about it through an ML lens, it's an incredibly long time. And if you just said five years, it doesn't seem, doesn't seem that long.[00:29:01] I think that, that kind of talks to part of the problem here is that things that are moving are moving incredibly quickly. I would expect, this is my, my hot take rather than some kind of official carefully thought out position, but my hot take would be something like the You can, you'll be able to get to good quality apps without doing really careful prompt engineering.[00:29:21] I don't think that prompt engineering is going to be a kind of durable differential skill that people will, will hold. I do think that, The way that you set up the ML problem to kind of ask the right questions, if you see what I mean, rather than the specific phrasing of exactly how you're doing chain of thought or few shot or something in the prompt I think the way that you set it up is, is probably going to be remain to be trickier for longer.[00:29:47] And I think some of the operational challenges that we've been talking about of wild variations in, in, in latency, And handling the, I mean, one way to think about these models is the first lesson that you learn when, when you're an engineer, software engineer, is that you need to sanitize user input, right?[00:30:05] It was, I think it was the top OWASP security threat for a while. Like you, you have to sanitize and validate user input. And we got used to that. And it kind of feels like this is the, The shell around the app and then everything else inside you're kind of in control of and you can grasp and you can debug, etc.[00:30:22] And what we've effectively done is, through some kind of weird rearguard action, we've now got these slightly chaotic things. I think of them more as complex adaptive systems, which , related but a bit different. Definitely have some of the same dynamics. We've, we've injected these into the foundations of the, of the app and you kind of now need to think with this defined defensive mindset downwards as well as upwards if you, if you see what I mean.[00:30:46] So I think it would gonna, it's, I think it will take a while for us to truly wrap our heads around that. And also these kinds of problems where you have to handle things being unreliable and slow sometimes and whatever else, even if it doesn't happen very often, there isn't some kind of industry wide accepted way of handling that at massive scale.[00:31:10] There are definitely patterns and anti patterns and tools and whatnot, but it's not like this is a solved problem. So I would expect that it's not going to go down easily as a, as a solvable problem at the ML scale either.[00:31:23] swyx: Yeah, excellent. I would describe in, in the terminology of the stuff that I've written in the past, I describe this inversion of architecture as sort of LLM at the core versus LLM or code at the core.[00:31:34] We're very used to code at the core. Actually, we can scale that very well. When we build LLM core apps, we have to realize that the, the central part of our app that's orchestrating things is actually prompt, prone to, , prompt injections and non determinism and all that, all that good stuff.[00:31:48] I, I did want to move the conversation a little bit from the sort of defensive side of things to the more offensive or, , the fun side of things, capabilities side of things, because that is the other part. of the job description that we kind of skimmed over. So I'll, I'll repeat what you said earlier.[00:32:02] Capabilities: Offensive AI Engineering[00:32:02] swyx: It's, you want people to have a genuine curiosity and enthusiasm for the capabilities of language models. We just, we're recording this the day after Anthropic just dropped Cloud 3. 5. And I was wondering, , maybe this is a good, good exercise is how do people have Curiosity and enthusiasm for capabilities language models when for example the research paper for cloud 3.[00:32:22] 5 is four pages[00:32:23] James Brady: Maybe that's not a bad thing actually in this particular case So yeah If you really want to know exactly how the sausage was made That hasn't been possible for a few years now in fact for for these new models but from our perspective as when we're building illicit What we primarily care about is what can these models do?[00:32:41] How do they perform on the tasks that we already have set up and the evaluations we have in mind? And then on a slightly more expansive note, what kinds of new capabilities do they seem to have? Can we elicit, no pun intended, from the models? For example, well, there's, there's very obvious ones like multimodality , there wasn't that and then there was that, or it could be something a bit more subtle, like it seems to be getting better at reasoning, or it seems to be getting better at metacognition, or Or it seems to be getting better at marking its own work and giving calibrated confidence estimates, things like this.[00:33:19] So yeah, there's, there's plenty to be excited about there. It's just that yeah, there's rightly or wrongly been this, this, this shift over the last few years to not give all the details. So no, but from application development perspective we, every time there's a new model release, there's a flow of activity in our Slack, and we try to figure out what's going on.[00:33:38] What it can do, what it can't do, run our evaluation frameworks, and yeah, it's always an exciting, happy day.[00:33:44] Adam Wiggins: Yeah, from my perspective, what I'm seeing from the folks on the team is, first of all, just awareness of the new stuff that's coming out, so that's, , an enthusiasm for the space and following along, and then being able to very quickly, partially that's having Slack to do this, but be able to quickly map that to, okay, What does this do for our specific case?[00:34:07] And that, the simple version of that is, let's run the evaluation framework, which Lissa has quite a comprehensive one. I'm actually working on an article on that right now, which I'm very excited about, because it's a very interesting world of things. But basically, you can just try, not just, but try the new model in the evaluations framework.[00:34:27] Run it. It has a whole slew of benchmarks, which includes not just Accuracy and confidence, but also things like performance, cost, and so on. And all of these things may trade off against each other. Maybe it's actually, it's very slightly worse, but it's way faster and way cheaper, so actually this might be a net win, for example.[00:34:46] Or, it's way more accurate. But that comes at its slower and higher cost, and so now you need to think about those trade offs. And so to me, coming back to the qualities of an AI engineer, especially when you're trying to hire for them, It's this, it's, it is very much an application developer in the sense of a product mindset of What are our users or our customers trying to do?[00:35:08] What problem do they need solved? Or what what does our product solve for them? And how does the capabilities of a particular model potentially solve that better for them than what exists today? And by the way, what exists today is becoming an increasingly gigantic cornucopia of things, right? And so, You say, okay, this new model has these capabilities, therefore, , the simple version of that is plug it into our existing evaluations and just look at that and see if it, it seems like it's better for a straight out swap out, but when you talk about, for example, you have multimodal capabilities, and then you say, okay, wait a minute, actually, maybe there's a new feature or a whole new There's a whole bunch of ways we could be using it, not just a simple model swap out, but actually a different thing we could do that we couldn't do before that would have been too slow, or too inaccurate, or something like that, that now we do have the capability to do.[00:35:58] I think of that as being a great thing. I don't even know if I want to call it a skill, maybe it's even like an attitude or a perspective, which is a desire to both be excited about the new technology, , the new models and things as they come along, but also holding in the mind, what does our product do?[00:36:16] Who is our user? And how can we connect the capabilities of this technology to how we're helping people in whatever it is our product does?[00:36:25] James Brady: Yeah, I'm just looking at one of our internal Slack channels where we talk about things like new new model releases and that kind of thing And it is notable looking through these the kind of things that people are excited about and not It's, I don't know the context, the context window is much larger, or it's, look at how many parameters it has, or something like this.[00:36:44] It's always framed in terms of maybe this could be applied to that kind of part of Elicit, or maybe this would open up this new possibility for Elicit. And, as Adam was saying, yeah, I don't think it's really a I don't think it's a novel or separate skill, it's the kind of attitude I would like to have all engineers to have at a company our stage, actually.[00:37:05] And maybe more generally, even, which is not just kind of getting nerd sniped by some kind of technology number, fancy metric or something, but how is this actually going to be applicable to the thing Which matters in the end. How is this going to help users? How is this going to help move things forward strategically?[00:37:23] That kind of, that kind of thing.[00:37:24] AI Engineering Required Knowledge[00:37:24] swyx: Yeah, applying what , I think, is, is, is the key here. Getting hands on as well. I would, I would recommend a few resources for people listening along. The first is Elicit's ML reading list, which I, I found so delightful after talking with Andreas about it.[00:37:38] It looks like that's part of your onboarding. We've actually set up an asynchronous paper club instead of my discord for people following on that reading list. I love that you separate things out into tier one and two and three, and that gives people a factored cognition way of Looking into the, the, the corpus, right?[00:37:55] Like yes, the, the corpus of things to know is growing and the water is slowly rising as far as what a bar for a competent AI engineer is. But I think, , having some structured thought as to what are the big ones that everyone must know I think is, is, is key. It's something I, I haven't really defined for people and I'm, I'm glad that this is actually has something out there that people can refer to.[00:38:15] Yeah, I wouldn't necessarily like make it required for like the job. Interview maybe, but , it'd be interesting to see like, what would be a red flag. If some AI engineer would not know, I don't know what, , I don't know where we would stoop to, to call something required knowledge, , or you're not part of the cool kids club.[00:38:33] But there increasingly is something like that, right? Like, not knowing what context is, is a black mark, in my opinion, right?[00:38:40] I think it, I think it does connect back to what we were saying before of this genuine Curiosity about and that. Well, maybe it's, maybe it's actually that combined with something else, which is really important, which is a self starting bias towards action, kind of a mindset, which again, everybody needs.[00:38:56] Exactly. Yeah. Everyone needs that. So if you put those two together, or if I'm truly curious about this and I'm going to kind of figure out how to make things happen, then you end up with people. Reading, reading lists, reading papers, doing side projects, this kind of, this kind of thing. So it isn't something that we explicitly included.[00:39:14] We don't have a, we don't have an ML focused interview for the AI engineer role at all, actually. It doesn't really seem helpful. The skills which we are checking for, as I mentioned before, this kind of fault first mindset. And conventional software engineering kind of thing. It's, it's 0. 1 and 0.[00:39:32] 3 on the list that, that we talked about. In terms of checking for ML curiosity and there are, how familiar they are with these concepts. That's more through talking interviews and culture fit types of things. We want for them to have a take on what Elisa is doing. doing, certainly as they progress through the interview process.[00:39:50] They don't need to be completely up to date on everything we've ever done on day zero. Although, , that's always nice when it happens. But for them to really engage with it, ask interesting questions, and be kind of bought into our view on how we want ML to proceed. I think that is really important, and that would reveal that they have this kind of this interest, this ML curiosity.[00:40:13] ML First Mindset[00:40:13] swyx: There's a second aspect to that. I don't know if now's the right time to talk about it, which is, I do think that an ML first approach to building software is something of a different mindset. I could, I could describe that a bit now if that, if that seems good, but yeah, I'm a team. Okay. So yeah, I think when I joined Elicit, this was the biggest adjustment that I had to make personally.[00:40:37] So as I said before, I'd been, Effectively building conventional software stuff for 15 years or so, something like this, well, for longer actually, but professionally for like 15 years. And had a lot of pattern matching built into my brain and kind of muscle memory for if you see this kind of problem, then you do that kind of a thing.[00:40:56] And I had to unlearn quite a lot of that when joining Elicit because we truly are ML first and try to use ML to the fullest. And some of the things that that means is, This relinquishing of control almost, at some point you are calling into this fairly opaque black box thing and hoping it does the right thing and dealing with the stuff that it sends back to you.[00:41:17] And that's very different if you're interacting with, again, APIs and databases, that kind of a, that kind of a thing. You can't just keep on debugging. At some point you hit this, this obscure wall. And I think the second, the second part to this is the pattern I was used to is that. The external parts of the app are where most of the messiness is, not necessarily in terms of code, but in terms of degrees of freedom, almost.[00:41:44] If the user can and will do anything at any point, and they'll put all sorts of wonky stuff inside of text inputs, and they'll click buttons you didn't expect them to click, and all this kind of thing. But then by the time you're down into your SQL queries, for example, as long as you've done your input validation, things are pretty pretty well defined.[00:42:01] And that, as we said before, is not really the case. When you're working with language models, there is this kind of intrinsic uncertainty when you get down to the, to the kernel, down to the core. Even, even beyond that, there's all that stuff is somewhat defensive and these are things to be wary of to some degree.[00:42:18] Though the flip side of that, the really kind of positive part of taking an ML first mindset when you're building applications is that you, If you, once you get comfortable taking your hands off the wheel at a certain point and relinquishing control, letting go then really kind of unexpected powerful things can happen if you lean on the, if you lean on the capabilities of the model without trying to overly constrain and slice and dice problems with to the point where you're not really wringing out the most capability from the model that you, that you might.[00:42:47] So, I was trying to think of examples of this earlier, and one that came to mind was we were working really early when just after I joined Elicit, we were working on something where we wanted to generate text and include citations embedded within it. So it'd have a claim, and then a, , square brackets, one, in superscript, something, something like this.[00:43:07] And. Every fiber in my, in my, in my being was screaming that we should have some way of kind of forcing this to happen or Structured output such that we could guarantee that this citation was always going to be present later on that the kind of the indication of a footnote would actually match up with the footnote itself and Kind of went into this symbolic.[00:43:28] I need full control kind of kind of mindset and it was notable that Andreas Who's our CEO, again, has been on the podcast, was was the opposite. He was just kind of, give it a couple of examples and it'll probably be fine. And then we can kind of figure out with a regular expression at the end. And it really did not sit well with me, to be honest.[00:43:46] I was like, but it could say anything. I could say, it could literally say anything. And I don't know about just using a regex to sort of handle this. This is a potent feature of the app. But , this is that was my first kind of, , The starkest introduction to this ML first mindset, I suppose, which Andreas has been cultivating for much longer than me, much longer than most, of yeah, there might be some surprises of stuff you get back from the model, but you can also It's about finding the sweet spot, I suppose, where you don't want to give a completely open ended prompt to the model and expect it to do exactly the right thing.[00:44:25] You can ask it too much and it gets confused and starts repeating itself or goes around in loops or just goes off in a random direction or something like this. But you can also over constrain the model. And not really make the most of the, of the capabilities. And I think that is a mindset adjustment that most people who are coming into AI engineering afresh would need to make of yeah, giving up control and expecting that there's going to be a little bit of kind of extra pain and defensive stuff on the tail end, but the benefits that you get as a, as a result are really striking.[00:44:58] The ML first mindset, I think, is something that I struggle with as well, because the errors, when they do happen, are bad. , they will hallucinate, and your systems will not catch it sometimes if you don't have large enough of a sample set.[00:45:13] AI Engineers and Creativity[00:45:13] swyx: I'll leave it open to you, Adam. What else do you think about when you think about curiosity and exploring capabilities?[00:45:22] Do people are there reliable ways to get people to push themselves? for joining us on Capabilities, because I think a lot of times we have this implicit overconfidence, maybe, of we think we know what it is, what a thing is, when actually we don't, and we need to keep a more open mind, and I think you do a particularly good job of Always having an open mind, and I want to get that out of more engineers that I talk to, but I, I, I, I struggle sometimes.[00:45:45] Adam Wiggins: I suppose being an engineer is, at its heart, this sort of contradiction of, on one hand, yeah,

Paul Orlando is back to talk about his book titled “Why Now?” You may remember Paul from his last appearance (a fan favorite) talking with Jerod about complex systems & second-order effects. Paul's book, “Why Now?” explores the concept of timing and the importance of understanding the ‘why now' in business and product development. We discuss timing examples from the book that were either too early or too late (such as the first video phone and car phones), the need to consider both technological advancements and user demand when assessing timing, the significance of timing in the success of companies like Apple and the launch of the iPhone, Uber and Heroku, and more. Also, join our Slack community for a chance to get a signed copy of Paul's book.

Paul Orlando is back to talk about his book titled “Why Now?” You may remember Paul from his last appearance (a fan favorite) talking with Jerod about complex systems & second-order effects. Paul's book, “Why Now?” explores the concept of timing and the importance of understanding the ‘why now' in business and product development. We discuss timing examples from the book that were either too early or too late (such as the first video phone and car phones), the need to consider both technological advancements and user demand when assessing timing, the significance of timing in the success of companies like Apple and the launch of the iPhone, Uber and Heroku, and more. Also, join our Slack community for a chance to get a signed copy of Paul's book.

Host Victoria Guido connects with Francis Lacoste, a seasoned VPE and CTO coach. He details his unexpected journey from an aspiring cinema professional to a key player in the tech industry after honing his remote-first work culture skills. He delves into his move toward coaching, emphasizing his commitment to developing engineering management talent and his dedication to building strong engineering cultures and leadership within organizations. Francis discusses the psychological aspects of leadership, such as the importance of psychological safety and the role of trust in organizational effectiveness. He also reflects on the nuances of transitioning from hands-on technical work to strategic leadership roles, emphasizing the critical soft skills necessary for effective leadership. Follow Francis Lacoste on LinkedIn (https://www.linkedin.com/in/francislacoste/). Visit his website: thevpe.coach (https://thevpe.coach/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Francis Lacoste, VPE and CTO coach. Francis, thank you for joining me. FRANCIS: My pleasure, Victoria. Thanks for having me. VICTORIA: Thank you. Well, it's a beautiful spring day today. And just to get us started and warmed up a little bit, I wonder if you could tell me about what is your favorite winter activity? FRANCIS: Cross-country skiing without doubt. I did a lot of alpine skiing when I was a kid. Could still do it, but really I found alpine, just skiing through parks and the calm of winter, is a very relaxing activity. And I use that as basically my workout. There's a park nearby the school of one of my kids. So, I drop him at school, then go do a few laps in the park near the river. It's beautiful. Unfortunately, this was a winter without almost any snow. So, I could only do four outings this year, which I need to do other workouts because that's not enough. VICTORIA: Wow. That's really cool. How long have you been cross-country skiing then? FRANCIS: I started doing that as a kid, but regularly only in the past, I'd say, four or five years. I bought some skis. Before that, I would only rent. So, that allowed me to do it more regularly. VICTORIA: That's interesting. I am cross-country ski curious because I've tried regular skiing the last couple of years, and I've found that it's way too fast for me personally [laughter]. So, I'm not sure. I think I might like it. FRANCIS: Yeah. I mean, cross-country skiing is more like jogging in a way because it's very cardio, unlike Alpine skiing, downhill skiing, where if you don't work hard, you can go very fast. You know, if you want to go slow, it's actually...you have to put in a lot of effort in downhill skiing, but cross-country skiing it's kind of like jogging. You're gliding on the snow and getting some momentum. I mean, if it's not flat, then it becomes a little bit more fiddly, but I do mostly flat courses because if you have, like, some slope, then it requires other technique, and it's actually harder to control than Alpine skiing. VICTORIA: Ooh. Well, I was going to say it sounds like my type of thing until the last part you said there [laughter]. I was like, oh, that's the part that I'm scared of. Well, I don't know, I don't get a chance to go skiing too often down here in San Diego, but I should go up to, like, Mammoth Mountain and things like that more often. But we got a ton of snow this year, so you'll have to come West and visit us sometime. FRANCIS: [laughs] VICTORIA: Well, wonderful. Well, Francis, tell me a little bit about your background and what led you to your coaching career here. FRANCIS: I've been working in software forever, basically. Fun fact: I wanted to go into cinema, and that's what I studied at university, but kept ending up in programming job basically, or programming endeavors. And this was, like, the beginning of the commercial internet, end of the '90s, and was very much into free software and open source, and that's how I got started as a software engineer. And eventually ended up at Canonical, which is still is; they celebrated their 20 years this year; the company that founded Ubuntu, the Linux distribution, which was very popular and still is to a large extent. That's where I kind of left, transitioned into software management, engineering management over there. I didn't know at all what I was getting into. I was on parental leave at the time, and my boss left a message to say, "Hey, we're thinking of creating teams, and we think you'd be a good fit for one of the team lead. Let me know what you think." And I said, "Yes," really, not knowing that this was a totally different job. Fortunately, I got good mentors and found out I enjoyed that. And then, after Canonical, I moved to Heroku, which I joined to help build a remote culture there because, at that point, the company was hiring more and more remote. And Canonical was a remote-first company. I mean, I've been working remotely for 25 years, almost, at this point. So, kind of had a good experience there, and at Heroku, really that, I kind of discovered coaching. I joined as a director, and then a few years in, there was a reorg. I ended up again with a single team to manage, which was, okay, I can do that. That's fine. Fortunately, I mean, by coincidence or luck, there was a guy on the team who wanted to become an engineering manager. He was already running most of the ceremonies of the team. And I said, "Oh, great [laughs]. What I love about being a director is growing engineering managers. So, I'm going to mentor you and help you de facto run the team, do the things that you're not in a position to do yet but eventually will transition that," which left me with a lot of time. My VP was supportive of this, and we had a lot of new first-time engineering managers at the time, so we didn't have a lot of people who had experience as engineering managers. So, I offered to mentor and coach internally. A lot of people took me up on that offer. So, I ended up doing that and eventually ended up with, like, running a large org again, but continuing doing that part. And this was the part that I kind of enjoyed the most [laughs] in my role, in a way. So, I think it was 2019. So, five years ago, I was running seven teams. It was the largest department, engineering department at Heroku. Things were fine, you know. But when I was stopping for summer vacation or winter vacation, I realized that the day before going back to work, I was kind of not looking forward to it. That was kind of a sign. And it was very subtle because, like, a week later, everything was fine again, you know, loved the people and the company and what we were doing. But there was something, like, deep down, I was not, like, fulfilled by the role. I did some soul searching and then realized, okay, what I really like is not running the organization but more, like, the mentoring, the nurturing of the culture. I was also doing a training at the time, working with groups, group facilitation, and so, like, working more, like, with advising leadership teams, that sort of thing. I went to my VP and told him, "Look, I realize this is not fulfilling for me. Don't freak out. I'm not quitting [laughs] yet, you know. I can do this for a year again. But if there is...then my next role is going to be consulting around engineering culture. But if there's a role, you know, where an organization is large, more aligned with this, I'd be happy to continue working at Heroku and Salesforce," because Heroku was part of Salesforce ever since I joined. So, he and the SVP were kind of thrilled by that idea. So, I became Chief of Staff for Heroku and start working with the whole engineering exec team. And that was great for six months. And then Salesforce did a big reorg, and I ended up...all the exec left, and Heroku engineering was kind of split apart and refactored into the normal Salesforce engineering. Fortunately for me, the EVP I had a relationship with him, and he knew what I was doing. And he took my role and said, like, "We like what you did with Heroku culture. Can you help us do that across all of platform?" So, I ended up doing culture work for one of the largest departments at Salesforce. At the time, it was 1,500 people. It was very scary in a way, in the sense that I knew this was the next step, you know, after Heroku, but I went from 150 engineers to 150. There were more engineering managers in platform than there were engineers at Heroku. So it was kind of, okay, I need to rethink my strategy and stuff like that. And then, that lasted until last year, and then there were the layoffs at Salesforce, and culture is one of the first thing that is usually cut. So, I got cut, which was fine because I kind of knew, okay, my next step after Salesforce was consulting around engineering culture. So, that's when I launched my business and decided to focus on coaching because that's what I had continued doing in the meantime and was finding the most fulfilling. VICTORIA: That's really interesting. Thank you for sharing all of that context. I have a lot of questions to follow up, but to recap a little bit, it sounds like you started as a software developer. You worked your way up to engineering management and then focused on coaching other leaders throughout your career. And now you're doing that as part of your own business. So, you founded your own company to just do that, which sounds super interesting. FRANCIS: Exactly. Yes. So, my focus is on I coach VP of engineering and CTOs at scaling startup. Like I said, I started coaching engineering managers at Heroku, and a lot of them eventually became directors. And at a large organization like Salesforce, after director, the next steps up there are a few opportunities in a way. So, you need to be at the right place at the right time, but otherwise, there's not just a lot of opportunities. And meanwhile, they get hit every week by recruiters on LinkedIn say, "Hey, come join our startup as VP of engineering," or CTO and things like that. A lot of them actually jumped ship to such role, and I continue coaching them in that capacity. And that was really just rewarding seeing the impact that these people have. So, last year when I started, I had a question around, okay, what is my offer? I want great engineering culture, but what is the offer? Then, looking at what I did, it's kind of, oh, well, this work I've done with all of these folks, this was always pleasurable and fulfilling to me. And coaching is a known offering, so there's probably something there. So, this was kind of what's kind of the business aspect of it. And the mission aspect is that...and I do other things than coaching. I do workshops and things like that. But my experience is that unless the executive, you know, the founder, the top leaders are not committed and bought in in creating a great culture and personally working on themselves, because that's required, you can bring, like, workshops to the team. You can...great process in place. You can do a lot of great things, which has an impact, but then it's not built on solid ground in a way because at the first reorg or the first, like, change [inaudible 10:31], then all of this work becomes very shaky ground. So, to me, it was kind of, oh yes, I need to start with coaching the CTOs and VPs, and that will ensure that there's actually potential for a great culture there. VICTORIA: That's really interesting. So, yeah, the coaching part is the key part and, like, the culture is number one. So, if you were talking to a new CTO, what kind of questions would you ask them to kind of gauge where they're at with their engineering culture? FRANCIS: The first question I always ask is, well, do you have, like, principles or values around that? And it's surprising. I come from Salesforce, which is a value-driven company, and there's a lot of startups that [inaudible 11:11]. It's kind of the playbook, you know, defining your company values. But still, there's a lot of people who've done it or who've not done it or done it, but it's kind of more like an exercise, and it's not, like, integrated. So, really, this is where usually I start when we're looking at culture is kind of what are your values, and are these values enacted, you know, manifested in your organization? Are they part of the day-to-day decision-making, the hiring process, the performance evaluation? And not just that, you know, also, when you're designing something internally, we're putting in place, like, a code review process. Well, how is that related to our values or not? And this is something I was fortunate because Salesforce it's a huge corporation, but still, they're serious about values there. And it is used, and they are living their values, not perfectly, I mean, it's still humans, and it's still a business. But these day-to-day decision-making values are definitely taken care of, and it's not just words on the wall. VICTORIA: Yeah. I think the second part of what you said there is the hardest part, not just what are your values, but how do you use those values in your everyday decision-making? FRANCIS: Yes. Mid-Roll Ad: As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what's important to your customers to help you transition to intuitive digital services your customers will trust. We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. VICTORIA: I'm interested in what it takes to be a CTO and go from that startup mentality into starting to think about how you're going to scale this organization. Because what I see a lot of times a CTO in an early-stage startup is the main developer also [chuckles] and has built the whole app. So, how do you think about that? What kinds of things do you start to delve into after the values, and how a CTO can transition into that role, into the scaling and leading larger teams? FRANCIS: Yeah, no, you're totally spot on here, Victoria, because CTO is one of these...somebody asked me once why the VPE coach and not the CTO coach. And, to me, it was, well, actually, because CTO is one of these multi-dimensional variable scope word, which means a very different thing. And often, at a startup, the CTO is basically the founding engineer. He is the person writing the code, building the product. And that's good. But as you grow, then the role change, and many of my clients are technical co-founders who actually want to scale with the org and not become, like, a chief architect, even though many of them will still keep the CTO title. And then, they will hire a VPE to actually build the organization and do what the role of the CTO is from my perspective. The CTO role, if we define it, it's really you're part of the exec team, and the exec team whose responsibility is to align technology to the business objective. So, can we use technology or build a product to actually deliver our product objective? So, it's kind of a strategic role, and at some point, you don't necessarily run the day-to-day of the org. But at a transition point, you need to focus on the org management and the org building. So, I often say, one, my ideal clients are these technical co-founders who want to switch from a product builder identity to a product development organization builder identity. That's the transition point. And then, it requires all the leadership skills somebody who leads an org needs, which are, like, being able to...empathy being one of the most important one, you know, being able to understand people, to inspire them, everything like that [chuckles]. VICTORIA: Yeah. All the easy stuff, right [chuckles]? FRANCIS: Yes [chuckles]. Yeah. It's called the soft skills [laughs], but we all know that it's not because they're easy [laughs]. VICTORIA: Right. Yeah, they're hard. FRANCIS: It's actually more because they are nebulous, which is very hard for somebody who's technically minded, you know, people; it's not like there's an on and an off, and logic gate is not what this is about. VICTORIA: Yeah. And, mentally, it must be challenging for someone who has poured their heart and soul, and time, and energy into this product to then turn around and say, "Okay, I'm going to let a bunch of other people get in there and start doing stuff [laughs]. FRANCIS: Yes. VICTORIA: And take it over. And, like, I'll just be involved from..." like, you know, when you say executive position, what does that mean? Is it, like, budget and strategy? And, you know, sometimes it's really hard to be effective in those conversations, and it really becomes about educating other people in your organization more than anything else. FRANCIS: Yeah, I mean, a lot of it is about budget and that sort of thing. To me, it's more like boring, and it's not the most critical part. I mean, your role as a leader is really to set the context for the people to execute them, you know, so that they have, like, the clarity of direction but not the control of the execution. You need to let go of control. You need to move much more on the influence side than the controlling side, especially the larger the org gets. You probably have managed folks. You need to lose the idea that you're in charge and you're making the decisions because otherwise, you get frustrated very fast. VICTORIA: Yeah. How would you refer to that? Is that like the inner game, like a mental game you have to shift into? FRANCIS: Yeah, I mean, to me, the inner game is all about the self-awareness, emotional intelligence, developing these capacities, which enables you to be a more effective leader. It's not just about being an effective leader. It's also about feeling good about your role and who you are in this context, you know, and that's the inner game. What happens externally, how you act, is a reflection of these inner capacities in a way. VICTORIA: That makes sense. And if you want to create a culture of psychological safety, you may want to start within yourself, right? FRANCIS: Yes. I mean, psychological safety it's one of the essential dimension of team performance. There's the Aristotle study that was done at Google, which they analyzed Agile teams and, okay, what is the most important factor in team performance? And what they came out with is, oh, it's this thing called psychological safety. Psychological safety as a name, as a concept was kind of coined by Amy C. Edmondson. I'm not fond of the term because I think it leads to some. I mean, it's a technical term, but because psychological safety and safety has a lot of, like, day-to-day meaning, it skews a little bit what it is. I much prefer...this is the same thing what Patrick Lencioni was calling out as the first dysfunction of a team, you know, the lack of trust. And it was defining trust as vulnerability-based trust, which goes with the technical definition of psychological safety, which is the perception that the team is safe for interpersonal risk-taking. So, it's kind of, A, here I'm not sure how this is going to go. This is risky a bit. I'm being vulnerable. But I perceive that the team...I trust that the team will receive that respectfully in a way. And that connection to the inner game is...as a manager, if you want to create psychological safety, you need to lead by example, which means you need to show that you can be vulnerable, you know, that you trust the team that they're not going to hang you to dry if you show a weakness or say, "Hey, I don't know here," or things like that. And this is very hard as leaders because we want to instill confidence and things like that. But that often comes with, like, masking our vulnerabilities, and that's actually detrimental in fostering psychological safety. VICTORIA: Yeah, we actually did a facilitated exercise on psychological safety at thoughtbot last year. And I brought up an idea I'd had where I wanted to see if I could say something obviously wrong on my team calls [laughter] and see if they would correct me. Like, are they going to correct me? Do they feel safe enough to, like, give me that correction? Like, you know. And I can say that my team does feel comfortable [laughs]. They crack me a lot [laughs]. FRANCIS: Awesome. VICTORIA: But that's great. You hire people who hopefully have, you know, expertise and security that might be greater and deeper or more recent, and yours that you have to do that. So, that's really interesting. Talking about all the reports, it reminds me as well as, like, the DevOps research, DORA report, where they say that security as well, like, the biggest indicator for a high-security organization is trust as well. So, it's really interesting to think about, like, how you as a CTO create that culture and create that culture of, like, trust, and compassion, and empathy, and vulnerability, and that will lead to performance, which may seem counterintuitive to some people. FRANCIS: Yeah. So, I'm kind of a model collector. I'm someone who loves different models. They're all good, you know, and that's the problem [laughs]. All models are good, but none of them actually exhaust reality. In one model, in a way, it's kind of simplification of The Five Dysfunctions Model and others. But there's two dimensions that are really important for team performance. So, the first one is kind of the, to me, this is kind of the ground, the horizontal layer. It's kind of how people relate to each other, so psychological safety. And then the vertical dimension is the clarity of the North Star and the mission. We all can relate to each other as human beings and trust each other, but we're here to do some work. And what is this work about? What is unifying us that we're here and not someplace else? And that's kind of the clarity of what we're trying to achieve, the North Star or the mission. And those two create the space for high performance because if you just have psychological safety but there is no clear mission and accountability to that mission...once you know clearly what we're here to do, we can hold each other accountable to delivering on it. And if you're the only person holding accountability as the leader, then you're far from high performance. Really, you get high performance when everyone is in it together. That's given by the clarity of what is it we're trying to achieve. And if that's not there, you have, like, a great group of people, but there's no direction. And if you have only direction and, you know, a mission, then you can get, like, in a very authoritarian thing, which, I mean, everybody's aligned to do something, but everybody is kind of afraid and not showing up fully. And you're not getting the full engagement of everyone, so there's a lot of heat and friction that's being lost. VICTORIA: Yeah. And you mentioned accountability. And I'm curious, what does that look like in your experience, like, holding each other accountable? What kind of ways can leaders do that? FRANCIS: To me, the most interesting question is how can leaders foster shared accountability on the team, mutual accountability? And how it looks like...and I'm a big fan of...it's kind of the virtuous cycle between team agreements and retrospective, you know, in agile, another word that can mean many things. But this idea of continuous improvement after every sprint or regularly the team gets together and reflects on what went well. What could we improve? Those sorts of things. This is kind of the collective space of where the teams exist as a team, you know, really kind of where there's something very important in the retrospective where we're showing up as a team and reflecting on the team. And what I like to do is use that moment to not only, like, how do we reflect about the first layer of, okay, we missed that feature or that sort of thing but also reflect on the norms of the team, which can be written down ideally, you know? And this is a team agreement part. And the output of the retrospective is modification or experiment around "Oh, we could try this or this other way of working." But the idea of team agreements is this is how we are holding each other accountable, too. And how it manifests in practice is you know you have, like, mutual accountability when it's not only the manager that is reminding people of, hey, this is our norm, you know? So, for instance, I don't know, example could be trivial, but still, you know, we said we need two reviews to commit code, and then, like, somebody didn't do it or something like that. The manager could go and say, "Hey, you forgot about this agreement." But really, where you want to be is that it's other people on the team say, "Hey, Joe, why didn't you ask me for a review here? You know, I could have been that second review you needed," or things like that. And that really means that everyone is kind of bought in on the norms. So, that, to me, what is mutual accountability about is when it feels confident enough to challenge each other and remind themselves accountable to the team norms. VICTORIA: Right. And facilitating that development of the team norms together, too, right? FRANCIS: Yes. VICTORIA: Wonderful. Do you have any questions for me? FRANCIS: So, I'm interested to hear about your story this time where you got called out [laughs]. You said okay...I love the test you did, you know. I'm going to say something here that I know is wrong and see if people feel confident enough to...so, how did you achieve that, you know? VICTORIA: Lucky for me, I don't have to test it because it just happens naturally [laughs]. So, in my role of managing director, I have to talk to clients, come up with estimates for the work, when will the work start, who is the right person for the team. And so, sometimes, you know, I'll put the proposal together, and I'll hear my team members say like, "Why are we doing it like this [laughs]? Do it this way instead. Like, I think this person's a better fit." And, you know, when I see them engaging in the proposal and not just saying, "Yeah, it looks good," that means that we're doing a good job, and they're actually reading it, and processing it, and thinking about the client's requirements and yeah, giving me real feedback. That's what I want, so that's what I like to see. And, you know, when I do my one on ones with my team members, at least every three months, I try to do a retrospective style where I ask, "In my role, what should I continue doing that's helping you? What should I start doing, and then what should I stop?" I do it in that order specifically, so we start with the nice stuff [laughs]. But yeah, and then I make sure that when I give that feedback back to my team members, I say like, "Make sure you feel like you can speak up and share and hear your voice. Like, it's maybe more of a start than a stop or a continue. Just try to, like, get your feedback in there. I want to hear from you. I want to make sure you feel comfortable giving feedback to me also." FRANCIS: Right. So, that's kind of demonstrating listening and enacting a feedback culture because you are asking for feedback and listening to it, and that fosters trust, you know, vulnerability-based trust. So, anything else you did that helped create that psychological safety on your team? VICTORIA: It's really important how you react to things in meetings, like in retrospectives, especially if, like, you're trying to...like, in my role a lot, I'm trying to represent the business and talk to my team about what's the strategy and what we're trying to do. Like, if someone asks you a question like, "Well, why are we doing it right that way? Like, I think that's, like, what [laughs], you know, like, what are you guys even thinking? That seems random." I think the emotional work, like you mentioned, like, taking a breath myself and, like, calming down. Because, like, part of me could get really annoyed and be like, "Well, we've been talking about this for three months, guys [chuckles], you know, like, this isn't new information." But then, you know, thinking about it, like, you know, taking the time to calm your own emotions and put yourself in their shoes and think about, well, how much time have they really had to, like, look at any of this stuff? And, like, maybe they need it in a different format, or in a different way, or, like, written up somewhere else and not just, like, briefly covered in a call. So, opening yourself up to alternatives and staying curious about, well, what is this feeling behind? Like, what's really needed to clear? So, it's, again, coming back to listening and acting on it. So, maybe that's part of it. So, to create more psychological safety on the team is that part about managing your own emotions and not overreacting if somebody doesn't like your idea is a really important part of it. FRANCIS: Yes, so true. You said something very interesting there, which is how you react to things. And this is true, you know, you want to be graceful in your reaction and not react from a place of frustration or anger. There's the saying that psychological safety is fragile, you know, trust can be lost easily and easy to lose. And I think this is actually, while there is some truth to it, it's actually just partially true. From my perspective, when you have psychological safety, basically, there's an anti-fragile aspect to it in the sense that you self-heal. But to self-heal, you need to recognize the breakage and heal. So, I see the occasions where we want to be reacting gracefully listening to feedback. And then, somebody asks a question, like, say, "Why are we doing this?" You know, and then, well, because [laughs] and you answer, "Yes, well, because we've been talking for three months about this, you know, get to the page." If you stop there, yes, this is detrimental. I mean, people will say, "Oh, this was weird, and I'll think twice next time before asking that question." But if you are committed to psychological safety, you realize that, or somebody might make you realize that. And then, you can repair saying, "Hey. Hey, sorry. I messed up here. This is really not in line with our value of listening to feedback. I'm sorry. I'm under..." and that's the healing part, and that actually strengthen psychological safety more than it was. I mean, this is the idea of antifragility, you know, a bone breaks, and when it rebuilds, it rebuilds stronger because you've shown vulnerability and kind of, okay, yes, when they make a mistake, I can see that they are able to correct in the moment. And that's the safety part that I don't like, you know, the common day word meaning of safety that I feel is misleading is that it makes the thing...it seems very fragile. People walk on eggs. You know, we have this sentiment that, oh, I should be cautious about what I'm saying and things like that, where, actually, if you have a psychological safety culture, you can be a little bit more spontaneous and candid. And if you mess up, well, there's enough safety that you can repair and recover from there. VICTORIA: Yeah, I actually, I mean, I did say that in the moment. And the way I recovered was that I said, "You know, I didn't want it to come across as an admonishment, like, why haven't you been listening? But more about back to our values, how can I make you all more bought into our goals from the beginning and make sure that you're connected and we're on the same page? Because it felt a little disconnected for me [laughs]," right? But yeah, no, I like that you put it that way. Like it's also about how you repair. And I think that's true as well. When I think about whether or not you're safe with someone, it's also like, are you safe enough to tell me when I made a mistake? And the way you're going to feel safe is if someone tells you that they make a mistake, they're going to apologize, and repair, and figure out how to do better next time. FRANCIS: Yeah, totally. VICTORIA: And then, I think about how much my, like, leadership learning fits into my, like, regular personal life [laughs] also, right? Yeah, that's wonderful. If you could go back in time to maybe when you were that engineer about to take your engineering management position, what advice would you give yourself if you could? FRANCIS: Hey, you do realize this is a totally different path. You're going to need to develop different skills that you add to. That was fine, you know because I kind of navigated that very seamlessly in many ways. But what I didn't highlight is that there was a transition, actually. And I think this is where the advice would come in. So, I was an engineer, so thinking with systems and system thinking. And I realized very rapidly this is a different role. I'm not programming code anymore, you know. And what I told myself was I'm programming the system in which code is being written. And I think that's a good working metaphor or thinking for a while. And that's where the advice would come in. It's kind of, A, this is not, like, an engineering system. This is about humans. So, in a way, I would kind of nudge myself toward developing the soft skills much more rapidly because I think it took me a while to really grok that, hey, I need to understand how to relate individually and personally to people and not just to ideas, roles, and process. Because you can have, like, an engineering perspective on management but that's lacking in empathy and...mainly the empathy [laughs]. So, do pay attention to empathy. I think that would be the fifth advice [laughs]. VICTORIA: Isn't that great advice for all of us all the time, right [laughs]? FRANCIS: Yes. VICTORIA: I love that. Yeah, wonderful. FRANCIS: I'm always happy to connect with people. You can find me on LinkedIn, Francis Lacoste. I think we don't talk to each other enough in these digital times. And so, we all network a lot, you know, on Slack and LinkedIn. And one day, I was connecting with someone on LinkedIn, and the guy offered me...said, "Hey, happy to connect. Are you interested in doing, like, a short call just to get acquainted?" And I said, "Oh, that's actually a good idea." I talked with the guy and decided to do the same thing myself. So, I'm always happy to have a conversation with folks. So, I invite you to try it out, you know, there's a lot of people out there, interesting people, and have interesting conversations. VICTORIA: I love that so much. That's really nice. And people can do that to me, too. You can always...people talk to me, come talk to me on my podcast [laughs]. Thank you so much for being with us here today, Francis. I really enjoyed our conversation. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on thoughtbotmastodonsocial@vguido. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Welcome to episode 257 of the Cloud Pod podcast – where the forecast is always cloudy! This week your hosts Justin, Matthew, Ryan, and Jonathan are in the barnyard bringing you the latest news, which this week is really just Meta's release of Llama 3. Seriously. That's every announcement this week. Don’t say we didn't warn you.  Titles we almost went with this week: Meta Llama says no Drama No Meta Prob-llama Keep Calm and Llama on  Redis did not embrace the Llama MK The bedrock of good AI is built on Llamas The CloudPod announces support for Llama3 since everyone else was doing it Llama3, better know as Llama Llama Llama The Cloud Pod now known as the LLMPod Cloud Pod is considering changing its name to LlamaPod Unlike WinAMP nothing whips the llamas ass A big thanks to this week's sponsor: Check out Sonrai Securities‘ new Cloud Permission Firewall. Just for our listeners, enjoy a 14 day trial at www.sonrai.co/cloudpod Follow Up  01:27 Valkey is Rapidly Overtaking Redis  Valkey has continued to rack up support from AWS, Ericsson, Google, Oracle and Verizon initially, to now being joined by Alibaba, Aiven, Heroku and Percona backing Valkey as well.   Numerous blog posts have come out touting Valkey adoption. I'm not sure this whole thing is working out as well as Redis CEO Rowan Trollope had hoped.  AI Is Going Great – Or How AI Makes All It's Money  03:26 Introducing Meta Llama 3: The most capable openly available LLM to date  Meta has launched Llama 3, the next generation of their state-of-the-art open source large language model.  Llama 3 will be available on AWS, Databricks, GCP, Hugging Face, Kaggle, IBM WatsonX, Microsoft Azure, Nvidia NIM, and Snowflake with support from hardware platforms offered by AMD, AWS, Dell, Intel, Nvidia and Qualcomm Includes new trust and safety tools such as Llama Guard 2, Code Shield and Cybersec eval 2 They plan to introduce new capabilities, including longer context windows, additional model sizes and enhanced performance. The first two models from Meta Lama3 are the 8B and 70B parameter variants that can support a broad range of use cases.  Meta shared some benchmarks against Gemma 7B and Mistral 7B vs the Lama 3 8B models and showed improvements across all major benchmarks.  Including Math with Gemma 7b doing 12.2 vs 30 with Llama 3 It had highly comparable performance with the 70B model against Gemini Pro 1.5 and Claude 3 Sonnet scoring within a few points of most of the other scores.  Jonathan recommends using LM Studio to get start playing around with LLMS, which you can find at https://lmstudio.ai/ 04:42 Jonathan – “Isn’t it funny how you go from an 8 billion parameter model to a 70 billion parameter model but nothing in between? Like you would have thought there would be some kind of like, some middle ground maybe? But, uh, but… No. But, um,

Adam Gross is one of the masters of product-led growth (PLG). Most recently, Adam was Vimeo's interim CEO. Before Vimeo, Adam was CEO of Heroku, which he joined after selling his startup, Cloudconnect in 2013. Additionally, Adam has held executive leadership roles at Salesforce and Dropbox, and has been an active angel investor & advisor to companies, including Buildkite, Cribl, and Tailscale. In Today's Episode with Adam Gross We Discuss: PLG Tactics from Dropbox, Heroku and Salesforce: What were Adam's biggest takeaways from his time at Salesforce? How did it shape his growth mindset? What did Adam learn about customer acquisition at Dropbox? What would Adam most like to change about growth today? Product-Led Growth: The Fundamentals: What is growth? What is it not? What do founders get wrong about growth? Why does Adam think PLG is not for everybody? What do most great PLG businesses have in common? How are value propositions segmented in PLG? How can startups transition from individual to enterprise clients? Why does Adam think startups doing paid acquisition sub $100M aren't actually PLG? The Secrets to Optimizing Growth Channels: What are the most common reasons fast-growing companies plateau? How does Adam advise founders on diversifying channels? What are the biggest mistakes founders make when scaling into enterprise? How should startups do effective product marketing in horizontal products? What is emotive & strategic marketing? How should startups balance both? How Angel Investing Changes How You View Companies: What are Adam's top 3 pieces of advice for founders? What does Adam mean when he says you are either hiring a poet or a librarian? What are the biggest mistakes founders make when hiring? What was Adam's biggest investment miss? What did he learn from it?

I'm starting a SaaS project using Django, and there are tons of decisions right out of the gate. To help me navigate these decisions, I've brought on Cory Zue.   Cory is the creator of SaaS Pegasus, and has tons of experience with Django.Some of the topics discussed:Building Django applicationsSaaS Pegasusplacecard.meWhat boilerplate projects areDjango cookiecutterCookiecutterWhich database to use, probably PostgreSQLAuthentication choises, probably AllauthDocker, Docker for development, Docker for deploymentDeployment targets / hosting services. Render, Heroku, Fly.io, for PaaS options.Front end frameworks. Bootstrap, Tailwind, DaisyUI, TailwindUIHTMX vs React vs straight Django templatesRocketsFont Awesomeand of course, SaaS Pegasus Sponsored by Mailtrap.ioAn Email Delivery Platform that developers love. An email-sending solution with industry-best analytics, SMTP, and email API, SDKs for major programming languages, and 24/7 human support. Try for Free at MAILTRAP.IOSponsored by PyCharm ProUse code PYTEST for 20% off PyCharm Professional at jetbrains.com/pycharmNow with Full Line Code CompletionSee how easy it is to run pytest from PyCharm at pythontest.com/pycharmThe Complete pytest CourseFor the fastest way to learn pytest, go to courses.pythontest.comWhether your new to testing or pytest, or just want to maximize your efficiency and effectiveness when testing.

In today's episode, Elixir Wizards Owen and Dan delve into the complexities of building advanced reporting features within software applications. They share personal insights and challenges encountered while developing reporting solutions for user-generated data, leveraging both Elixir/Phoenix and Ruby on Rails. The discussion zeroes in on crucial data modeling and architectural decisions that enhance reporting efficiency and flexibility. Owen and Dan explore tactics like materialized views, event sourcing, and database triggers to optimize data handling while being mindful of UX elements like progress indicators and background job management. They share insights on leveraging the Elixir/Beam ecosystem's strengths—like concurrency and streamlined deployment—to tackle common reporting, caching, and integration challenges. The episode highlights the impact of reporting features across all aspects of a software application's design and architecture. Key topics discussed in this episode: Reporting on assessment data, survey results, and user metrics Differences between reporting and performance/error monitoring Implementing reporting in Elixir/Phoenix vs. Ruby on Rails Displaying reports in web, printable, PDF, SVG, and CSV formats Challenges of generating PDFs for large data sets Streaming CSV data directly to the client Handling long-running report generation tasks Providing progress indicators and user notifications Strategies for canceling or abandoning incomplete reports Tradeoffs of pre-calculating report data vs. real-time generation Materializing views and denormalizing data for reporting Exploring event sourcing patterns for reporting needs Using database triggers and stored procedures for reporting Balancing data structure optimization for reports vs. day-to-day usage Caching report data for faster retrieval and rendering Charting and visualization integration in reporting systems Links mentioned: Prometheus monitoring system & time series database https://prometheus.io/ Thinking Elixir "FLAME with Chris McCord" https://podcast.thinkingelixir.com/181 Phoenix LiveView Uploads https://hexdocs.pm/phoenix/fileuploads.html https://hexdocs.pm/phoenixlive_view/Phoenix.LiveView.UploadWriter.html Postgrex PostgreSQL driver for Elixir https://hexdocs.pm/postgrex/Postgrex.html Ecto https://hexdocs.pm/ecto/Ecto.html Heroku cloud application platform  https://www.heroku.com/ Elixir Wizards S9E12 Marcelo Dominguez on Command and Query Responsibility Segregation https://smartlogic.io/podcast/elixir-wizards/s9-e12-marcelo-dominguez-cqrs/ Commanded Elixir CQRS/ES applications https://github.com/commanded/commanded Tailwind CSS Framework https://github.com/tailwindlabs Memcached https://memcached.org/ Redis https://redis.io/ Oban https://hexdocs.pm/oban/Oban.html ETS https://hexdocs.pm/ets/ETS.html Capistrano remote server automation and deployment tool https://capistranorb.com/

Joël conducted a thoughtbot mini-workshop on query plans, which Stephanie found highly effective due to its interactive format. They then discuss the broader value of interactive workshops over traditional talks for deeper learning. Addressing listener questions, Stephanie and Joël explore the strategic use of if and else in programming for clearer code, the importance of thorough documentation in identifying bugs, and the use of Postgres' EXPLAIN ANALYZE, highlighting the need for environment-specific considerations in query optimization. Episode mentioning query plans (https://bikeshed.thoughtbot.com/418) Query plan visualizer (https://explain.dalibo.com/) RailsConf 2024 (https://railsconf.org/) Episode 349: Unpopular Opinions (https://bikeshed.thoughtbot.com/349) Squint test (https://www.youtube.com/watch?v=8bZh5LMaSmE) Episode 405: Retro on Sandi Metz rules (https://bikeshed.thoughtbot.com/405) Structuring conditionals in a wizard (https://thoughtbot.com/blog/structuring-conditionals-in-a-wizard) Episode 417: Module docs (https://bikeshed.thoughtbot.com/417) Episode 416: Multidimensional numbers (https://bikeshed.thoughtbot.com/416) ruby-units gem (https://github.com/olbrich/ruby-units) Solargraph (https://marketplace.visualstudio.com/items?itemName=castwide.solargraph) parity (https://github.com/thoughtbot/parity) Transcript: STEPHANIE:  Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville, and together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: Just recently, I ran a sort of mini workshop for some colleagues here at thoughtbot to dig into the idea of query plans and, how to read them, how to use them. And, initially, this was going to be more of a kind of presentation style. And a colleague and I who were sharing this decided to go for a more interactive format where, you know, this is a, like, 45-minute slot. And so, we set it up so that we did a sort of intro to query plans in about 10 minutes then 15 minutes of breakout rooms, where people got a chance to have a query plan. And they had some sort of comprehension questions to answer about it. And then, 15 minutes together to have each group share a little bit about what they had discovered in their query plan back with the rest of the group, so trying to balance some understanding, some application, some group discussion, trying to keep it engaging. It was a pretty fun approach to sharing information like that. STEPHANIE: Yeah. I wholeheartedly agree. I got to attend that workshop, and it was really great. Now that I'm hearing you kind of talk about the three different components and what you wanted people attending to get out of it, I am impressed because [laughs] there is, like, a lot more thought, I think, that went into just participant engagement that reflecting on it now I'm like, oh yeah, like, I think that was really effective as opposed to just a presentation. Because you had, you know, sent us out into breakout rooms, and each group had a different query that they were analyzing. You had kind of set up links that had the query set up in the query analyzer. I forget what the tool was called that you used. JOËL: I forget the name of it, but we will link it in the show notes. STEPHANIE: Yeah. It was helpful for me, though, because, you know, I think if I were just to have learned about it in a presentation or even just looked at, you know, screenshots of it on a slide, that's different still from interacting with it and feeling more confident to use it next time I find myself in a situation where it might be helpful. JOËL: It's really interesting because that was sort of the goal of it was to make it a bit more interactive and then, hopefully, helping people to retain more information than just a straight up, like, presentation would be. I don't know how you feel, I find that often when I go to a place like, let's say, RailsConf, I tend to stay away from more of the workshop-y style events and focus more on the talks. Is that something that you do as well? STEPHANIE: Yeah. I have to confess that I've never attended a workshop [laughs] at a conference. I think it's partly my learning style and also partly just honestly, like, my energy level when I'm at the conference. I kind of just want to sit back. It's on my to-do list. Like, I definitely want to attend one just to see what it's like. And maybe that might even inspire me to want to create my own workshop. But it's like, once I'm in it, and, you know, like, everyone else is also participating, I'm very easily peer pressured [laughs]. So, in a group setting, I will find myself enjoying it a lot more. And I felt that kind of same way with the workshop you ran for our team. Though, I will say a funny thing that happened was that when I went out into my breakout group with another co-worker, and we were trying to grok this query that you gave us, we found out that we got the hardest one, the most complicated one [laughs] because there were so many things going on. There was, like, multiple, like, you know, unions, some that were, like, nested, and then just, like, a lot of duplication as well, like, some conditions that were redundant because of a different condition happening inside of, like, an inner statement. And yeah, we were definitely scratching our heads for a bit and were very grateful that we got to come back together as a group and be like, "Can someone please help? [laughs] Let's figure out what's going on here." JOËL: Sort of close that loop and like, "Hey, here's what we saw. What does everybody else see?" STEPHANIE: Yeah, and I appreciated that you took queries from actual client projects that you were working on. JOËL: Yeah, that was the really fun part of it was that these were not sort of made-up queries to illustrate a point. These were actual queries that I had spent some time trying to optimize and where I had had to spend a lot of time digging into the query plans to understand what was going on. And it sounds like, for you, workshops are something that is...they're generally more engaging, and you get more value out of them. But there's higher activation energy to get started. Does that sound right? STEPHANIE: Yeah, that sounds right. I think, like, I've watched so many talks now, both in person and on YouTube, that a lot of them are easily forgettable [laughs], whereas I think a workshop would be a lot more memorable because of that interactivity and, you know, you get out of it what you put in a little bit. JOËL: Yeah, that's true. Have you looked at the schedule for RailsConf 2024 yet? And are there any workshops on there that you're maybe considering or that maybe have piqued your interest? STEPHANIE: I have, in fact, and maybe I will check off attending a workshop [laughs] off my bucket list this year. There are two that I'm excited about. Unfortunately, they're both at the same time slot, so I -- JOËL: Oh no. You're going to have to choose. STEPHANIE: I know. I imagine I'll have to choose. But I'm interested in the Let's Extend Rails With A Gem by Noel Rappin and Vision For Inclusion Workshop run by Todd Sedano. The Rails gem one I'm excited about because it's just something that I haven't had to do really in my dev career so far, and I think I would really appreciate having that guidance. And also, I think that would be motivation to just get that, like, hands-on experience with it. Otherwise, you know, this is something that I could say that I would want to do and then never get [chuckles] around to it. JOËL: Right, right. And building a gem is the sort of thing that I think probably fits better in a workshop format than in a talk format. STEPHANIE: Yeah. And I've really appreciated all of Noel's content out there. I've found it always really practical, so I imagine that the workshop would be the same. JOËL: So, other than poring over the RailsConf schedule and planning your time there, what has been new for you this week? STEPHANIE: I have a really silly one [laughs]. JOËL: Okay. STEPHANIE: Which is, yesterday I went out to eat dinner to celebrate my partner's birthday, and I experienced, for the first time, robots [laughter] at this restaurant. So, we went out to Hot Pot, and I guess they just have these, like, robot, you know, little, small dish delivery things. They were, like, as tall as me, almost, at least, like, four feet. They were cat-themed. JOËL: [laughs] STEPHANIE: So, they had, like...shaped like cat...they had cat ears, and then there was a screen, and on the screen, there was, like, a little face, and the face would, like, wink at you and smile. JOËL: Aww. STEPHANIE: And I guess how this works is we ordered our food on an iPad, and if you ordered some, like, side dishes and stuff, it would come out to you on this robot cat with wheels. JOËL: Very fun. STEPHANIE: This robot tower cat. I'm doing a poor job describing it because I'm still apparently bewildered [laughs]. But yeah, I was just so surprised, and I was not as...I think I was more, like, shocked than delighted. I imagine other people would find this, like, very fun. But I was a little bit bewildered [laughs]. The other thing that was very funny about this experience is that these robots were kind of going down the aisle between tables, and the aisles were not quite big enough for, like, two-way traffic. And so, there were times where I would be, you know, walking up to go use the restroom, and I would turn the corner and find myself, like, face to face with one of these cat robot things, and, like, it's starting to go at me. I don't know if it will stop [laughs], and I'm the kind of person who doesn't want to find out. JOËL: [laughs] STEPHANIE: So, to avoid colliding with this, you know, food delivery robot, I just, like, ran away from it [laughs]. JOËL: You don't know if they're, like, programmed to yield or something like that. STEPHANIE: Listen, it did not seem like it was going to stop. JOËL: [laughs] STEPHANIE: It got, like, I was, you know, kind of standing there frozen in paralysis [laughs] for a little while. And then, once it got, I don't know, maybe two or three feet away from me, I was like, okay, like, this is too close for comfort [laughs]. So, that was my, I don't know, my experience at this robot restaurant. Definitely starting to feel like I'm in the, I don't know, is this the future? Someone, please let me know [laughs]. JOËL: Is this a future that you're excited or happy about, or does this future seem a little bit dystopian to you? STEPHANIE: I was definitely alarmed [laughter]. But I'm not, like, a super early adopter of new technology. These kinds of innovations, if you will, always surprise me, and I'm like, oh, I guess this is happening now [laughs]. And I will say that the one thing I did not enjoy about it is that there was not enough room to go around this robot. It definitely created just pedestrian traffic issues. So, perhaps this could be very cool and revolutionary, but also, maybe design robots for humans first. JOËL: Or design your dining room to accommodate your vision for the robots. I'm sure that flying cars and robots will solve all of this, for sure. STEPHANIE: Oh yeah [laughter]. Then I'll just have to worry about things colliding above my head. JOËL: And for the listeners who cannot see my face right now, that was absolutely sarcasm [laughs]. Speaking of our listeners, today we're going to look at a group of different listener questions. And if you didn't know that, you could send in a question to have Stephanie and I discuss, you can do that. Just send us an email at hosts@bikeshed.fm. And sometimes, we put it into a regular episode. Sometimes, we combine a few and sort of make a listener question episode, which is what we're doing today. STEPHANIE: Yeah. It's a little bit of a grab bag. JOËL: Our first question comes from Yuri, and Yuri actually has a few different questions. But the first one is asking about Episode 349, which is pretty far back. It was my first episode when I was coming on with Chris and Steph, and they were sort of handing the baton to me as a host of the show. And we talked about a variety of hot takes or unpopular opinions. Yuri mentions, you know, a few that stood out to him: one about SPAs being not so great, one about how you shouldn't need to have a side project to progress in your career as a developer, one about developer title inflation, one about DRY and how it can be dangerous for a mid-level dev, avoiding let in RSpec specs, the idea that every if should come with an else, and the idea that developers shouldn't be included in design and planning. And Yuri's question is specifically the question about if statements, that every if should come with an else. Is that still an opinion that we still have, and why do we feel that way? STEPHANIE: Yeah, I'm excited to get into this because I was not a part of that episode. I was a listener back then when it was still Steph and Chris. So, I am hopefully coming in with a different, like, additional perspective to add as well while we kind of do a little bit of a throwback. So, the one about every if should come with an else, that was an unpopular opinion of yours. Do you mind kind of explaining what that means for you? JOËL: Yeah. So, in general, Ruby is an expression-oriented language. So, if you have an if that does not include an else, it will implicitly return nil, which can burn you. There may be some super expert programmers out there that have never run into undefined method for nil nil class, but I'm still the kind of programmer who runs into that every now and then. And so, implicit nils popping up in my code is not something I generally like. I also generally like having explicit else for control flow purposes, making it a little bit clearer where flow of control goes and what are the actual paths through a particular method. And then, finally, doing ifs and elses instead of doing them sort of inline or as trailing conditionals or things like that, by having them sort of all on each lines and balancing out. The indentation itself helps to scan the code a little bit more. So, deeper indentation tells you, okay, we're, like, nesting multiple conditions, or something like that. And so, it makes it a little bit easier to spot complexity in the code. You can apply, and I want to say this is from Sandi Metz, the squint test. STEPHANIE: Yeah, it is. JOËL: Where you just kind of, like, squint at your code so you're not looking at the actual characters, and more of the structure, and the indentation is actually a friend there rather than something to fight. So, that was sort of the original, I think, idea behind that. I'm curious, in your experience, if you would like to balance your conditionals, ifs with something else, or if you would like to do sort of hanging ifs. STEPHANIE: Hanging ifs, I like that phrase that you just coined there. I agree with your opinion, and I think it's especially true if you're returning values, right? I mean, in Ruby, you kind of always are. But if you are caring about return values, like you said, to avoid that implicit nil situation, I find, especially if you're writing tests for that code, it's really easy, you know, if you spot that condition, you're like, okay, great. Like, this is a path I need to test. But then, oftentimes, you don't test that implicit path, and if you don't enter the condition, then what happens, right? So, I think that's kind of what you're referring to when you talk about both. It's, like, easier to spot in terms of control flow, like, all the different paths of execution, as well as, yeah, like, saving you the headaches of some bugs down the line. One thing that I thought about when I was kind of revisiting that opinion of yours is the idea of like, what are you trying to communicate is different or special about this condition when you are writing an if statement? And, in my head, I kind of came up with a few different situations you might find yourself in, which is, one, where you truly just have, like, a special case, and you're treating that completely differently. Another when you have more of a, like, binary situation, where it's you want to kind of highlight either...more of a dichotomy, right? It's not necessarily that there is a default but that these are two opposite things. And then, a third situation in which you have multiple conditions, but you only happen to have two right now. JOËL: Interesting. And do you think that, like, breaking down those situations would lead you to pick different structures for writing your conditionals? STEPHANIE: I think so. JOËL: Which of those scenarios do you think you might be more likely to reach for an if that doesn't have an else that goes with it? STEPHANIE: I think that first one, the special case one. And in Yuri's email, he actually asked, as a follow-up, "Do we avoid guard clauses as a result of this kind of heuristic or rule?" And I think that special case situation is where a guard clause would shine because you are highlighting it by putting it at the top of a method, and then saying like, you know, "Bail out of this" or, like, "Return this particular thing, and then don't even bother about the rest of this code." JOËL: I like that. And I think guard clauses they're not the first thing I reach for, but they're not something I absolutely avoid. I think they need to be used with care. Like you said, they have to be in the top of your method. If you're adding returns and things that break out of your method, deep inside a conditional somewhere, 20 lines into your method, you don't get to call that a guard clause anymore. That's something else entirely. I think, ideally, guard clauses are also things that will break out of the method, so they're maybe raising exception. Maybe they're returning a value. But they are things that very quickly check edge cases and bail so that the body of the method can focus on expecting data in the correct shape. STEPHANIE: I have a couple more thoughts about this; one is I'm reminded of back when we did that episode on kind of retroing Sandi Metz's Rules For Developers. I think one of the rules was: methods should only be five lines of code. And I recall we'd realized, at least I had realized for the first time, that if you write an if-else condition in Ruby, that's exactly five lines [laughs]. And so, now that I'm thinking about this topic, it's cool to see that a couple of these rules converge a little bit, where there's a bit of explicitness in saying, like, you know, if you're starting to have more conditions that can't just be captured in a five-line if-else statement, then maybe you need something else there, right? Something perhaps like polymorphic or just some way to have branched earlier. JOËL: That's true. And so, even, like, you were talking about the exceptional edge cases where you might want to bail. That could be a sign that your method is doing too much, trying to like, validate inputs and also run some sort of algorithm. Maybe this needs to be some sort of, like, two-step thing, where there's almost, like, a parsing phase that's handled by a different object or a different method that will attempt to standardize your inputs and raise the appropriate errors and everything. And then, your method that has the actual algorithm or code that you're trying to run can just assume that its inputs are in the correct shape, kind of that pushing the uncertainty to the edges. And, you know, if you've only got one edge case to check, maybe it's not worth to, like, build this in layers, or separate out the responsibilities, or whatever. But if you're having a lot, then maybe it does make sense to say, "Let's break those two responsibilities out into two places." STEPHANIE: Yeah. And then, the one last kind of situation I've observed, and I think you all talked about this in the Unpopular Opinions episode, but I'm kind of curious how you would handle it, is side effects that only need to be applied under a certain condition. Because I think that's when, if we're focusing less on return values and more just on behavior, that's when I will usually see, like, an if something, then do this that doesn't need to happen for the other path. JOËL: Yes. I guess if you're doing some sort of side effect, like, I don't know, making a request to an API or writing to a file or something, having, like, else return nil or some other sentinel value feels a little bit weird because now you're caring about side effects rather than return values, something that you need to keep thinking of. And that's something where I think my thing has evolved since that episode is, once you start having multiple of these, how do they compose together? So, if you've got if condition, write to a file, no else, keep going. New if condition, make a request to an API endpoint, no else, continue. What I've started calling independent conditions now, you have to think about all the different ways that they can combine, and what you end up having is a bit of a combinatorial explosion. So, here we've got two potential actions: writing to a file, making a request to an API. And we could have one or the other, or both, or neither could happen, depending on the inputs to your method, and maybe you actually want that, and that's cool. Oftentimes, you didn't necessarily want all of those, especially once you start going to three, four, five. And now you've got that, you know, explosion, like, two to the five. That's a lot of paths through your method. And you probably didn't really need that many. And so, that can get really messy. And so, sometimes the way that an if and an else work where those two paths are mutually exclusive actually cuts down on the total number of paths through your method. STEPHANIE: Hmm, I like that. That makes a lot of sense to me. I have definitely seen a lot of, like, procedural code, where it becomes really hard to tell how to even start relating some of these concepts together. So, if you happen to need to run a side effect, like writing to a file or, I don't know, one common one I can think of is notifying something or someone in a particular case, and maybe you put that in a condition. But then there's a different branching path that you also need to kind of notify someone for a similar reason, maybe even the same reason. It starts to become hard to connect, like, those two reasons. It's not something that, like, you can really scan for or, like, necessarily make that connection because, at that point, you're going down different paths, right? And there might be other signals that are kind of confusing things along the way. And it makes it a lot harder, I think, to find a shared abstraction, which could ultimately make those really complicated nested conditions a little more manageable or just, like, easier to understand at a certain complexity. I definitely think there is a threshold. JOËL: Right. And now you're talking about nested versus non-nested because when conditions are sort of siblings of each other, an if-else behaves differently from two ifs without an else. I think a classic situation where this pops up is when you're structuring code for a wizard, a multi-step form. And, oftentimes, people will have a bunch of checks. They're like, oh, if this field is present, do these things. If this field is present, do these things. And then, it becomes very tricky to know what the flow of control is, what you can expect at what moment, and especially which actions might get shared across multiple steps. Is it safe to refactor in one place if you don't want to break step three? And so, learning to think about the different paths through your code and how different conditional structures will impact that, I think, was a big breakthrough for me in terms of taking the next logical step in terms of thinking, when do I want to balance my ifs and when do I not want to? I wrote a whole article on the topic. We'll link it in the show notes. So, Yuri, thanks for a great question, bringing us back into a classic developer discussion. Yuri also asks or gives us a bit of a suggestion: What about revisiting this topic and doing an episode on hot takes or unpopular topics? Is that something that you'd be interested in, Stephanie? STEPHANIE: Oh yeah, definitely, because I didn't get to, you know, share my hot topics the last episode [laughs]. [inaudible 24:23] JOËL: You just got them queued up and ready to go. STEPHANIE: Yeah, exactly. So, yeah, I will definitely be brainstorming some spicy takes for the show. JOËL: So, Yuri, thanks for the questions and for the episode suggestion. STEPHANIE: So, another listener, Kevin, wrote in to us following up from our episode on Module Docs and about a different episode about Multi-dimensional Numbers. And he mentioned a gem that he maintains. It's called Ruby Units. And it basically handles the nitty gritty of unit conversions for you, which I thought was really neat. He mentioned that it has a numeric class, and it knows how to do math [laughs], which I would find really convenient because that is something that I have been grateful not to have to really do since college [laughs], at least those unit conversions and all the things that I'd probably learned in math and physics courses [laughs]. So, I thought that was really cool, definitely is one to check out if you frequently work with units. It seemed like it would be something that would make sense for a domain that is more science or deals in that kind of domain. JOËL: I'm always a huge fan of anything that tags raw numbers that you're working with with a quantity rather than just floating raw numbers around. It's so easy to make a mistake to either treat a number as a quantity you didn't think of, or make some sort of invalid operation on it, or even to think you have a value in a different size than you do. You think you're dealing with...you know you have a time value, but you think it's in seconds. It's actually in milliseconds. And then, you get off by some big factor. These are all mistakes that I have personally made in my career, so leaning on a library to help avoid those mistakes, have better information hiding for the things that really aren't relevant to the work that I'm trying to do, and also, kind of reify these ideas so that they have sort of a name, and they're, like, their own object, their own thing that we can interact with in the app rather than just numbers floating around, those are all big wins from my perspective. STEPHANIE: I also just thought of a really silly use case for this that is, I don't know, maybe I'll have to experiment with this. But every now and then, I find the need to have to convert a unit, and I just pop into Google, and I'm like, please give me, you know, I'll search for 10 kilometers in miles or something [laughs]. But then I have to...sometimes Google will figure it out for me, and sometimes it will just list me with a bunch of weird conversion websites that all have really old-school UI [laughs]. Do you know what I'm talking about here? Anyway, I would be curious to see if I could use this gem as a command-line interface [laughs] for me without having to go to my browser and roll the dice with freecalculator.com or something like that [laughs]. JOËL: One thing that's really cool with this library that I saw is the ability to define your own units, and that's a thing that you'll often encounter having to deal with values that are maybe not one of the most commonly used units that are out there, dealing with numbers that might mean a thing that's very particular to your domain. So, that's great that the library supports that. I couldn't see if it supports multi-dimensional units. That was the episode that inspired the comment. But either way, this is a really cool library. And thank you, Kevin, for sharing this with us. STEPHANIE: Kevin also mentions that he really enjoys using YARD docs. And we had done that whole episode on Module Docs and your experience writing them. So, you know, your people are out there [laughs]. JOËL: Yay. STEPHANIE: And we talked about this a little bit; I think that writing the docs, you know, on one hand, is great for future readers, but, also, I think has the benefit of forcing the author to really think about their inputs and outputs, as Kevin mentions. He's found bugs by simply just going through that process in designing his code, and also recommends Solargraph and Solargraph's VSCode extension, which I suspect really kind of makes it easy to navigate a complex codebase and kind of highlight just what you need to know when working with different APIs for your classes. So, I recently kind of switched to the Ruby LSP, build with Shopify, but I'm currently regretting it because nothing is working for me right now. So, that might be the push that I need [laughs] to go back to using Solargraph. JOËL: It's interesting that Kevin mentions finding bugs while writing docs because that has absolutely been my experience. And even in this most recent round, I was documenting some code that was just sort of there. It wasn't new code that I was writing. And so, I had given myself the rule that this would be documentation-only PRs, no code changes. And I found some weird code, and I found some code that I'm 98% sure is broken. And I had to have the discipline to just put a notice in the documentation to be like, "By the way, this is how the method should work. I'm pretty sure it's broken," and then, maybe come back to it later to fix it. But it's amazing how trying to document code, especially code that you didn't write yourself, really forces you to read it in a different way, interact with it in a different way, and really, like, understand it in a deep way that surprised me a little bit the first time I did it. STEPHANIE: That's cool. I imagine it probably didn't feel good to be like, "Hey, I know that this is broken, and I can't fix it right now," but I'm glad you did. That takes a lot of, I don't know, I think, courage, in my opinion [laughs], to be like, "Yeah, I found this, and I'm going to, you know, like, raise my hand acknowledging that this is how it is," as supposed to just hiding behind a broken functionality that no one [laughs] has paid attention to. JOËL: And it's a thing where if somebody else uses this method and it breaks in a way, and they're like, "Well, the docs say it should behave like this," that would be really frustrating. If the docs say, "Hey, it should behave like this, but it looks like it's broken," then, you know, I don't know, I would feel a little bit vindicated as a person who's annoyed at the code right now. STEPHANIE: For sure. JOËL: Finally, we have a message from Tim about using Postgres' EXPLAIN ANALYZE. Tim says, "Hey, Joël, in the last episode, you talked a bit about PG EXPLAIN ANALYZE. As you stated, it's a great tool to help figure out what's going on with your queries, but there is a caveat you need to keep in mind. The query planner uses statistics gathered on the database when making decisions about how to fetch records. If there's a big difference between your dev or staging database and production, the query may make different decisions. For example, if a table has a low number of records in it, then the query planner may just do a table scan, but in production, it might use an index. Also, keep in mind that after a schema changes, it may not know about new indexes or whatever unless an explicit ANALYZE is done on the table." So, this is really interesting because, as Tim mentions, EXPLAIN ANALYZE doesn't behave exactly the same in production versus in your local development environment. STEPHANIE: When you were trying to optimize some slow queries, where were you running the ANALYZE command? JOËL: I used a combination. I mostly worked off of production data. I did a little bit on a staging database that had not the same amount of records and things. That was pretty significant. And so, I had to switch to production to get realistic results. So, yes, I encountered this kind of firsthand. STEPHANIE: Nice. For some reason, this comment also made me think of..., and I wanted to plug a thoughtbot shell command that we have called Parity, which lets you basically download your production database into your local dev database if you use Heroku. And that has come in handy for me, obviously, in regular development, but would be really great in this use case. JOËL: With all of the regular caveats around security, and PII, and all this stuff that come with dealing with production data. But if you're running real productions on production, you should be cleared and, like, trained for access to all of that. I also want to note that the queries that you all worked with on Friday are also from the production database. STEPHANIE: Really? JOËL: So, you got to see what it actually does, what the actual timings were. STEPHANIE: I'm surprised by that because we were using, like, a web-based tool to visualize the query plans. Like, what were you kind of plugging into the tool for it to know? JOËL: So, the tool accepts a query plan, which is a text output from running a SQL query. STEPHANIE: Okay. So, it's just visualizing it. JOËL: Correct. Yeah. So, you've got this query plan, which comes back as this very intimidating block of, like, text, and arrows, and things like that. And you plug it into this web UI, and now you've got something that is kind of interactive, and visual, and you can expand or collapse nodes. And it gives you tooltips on different types of information and where you're spending the most time. So, yeah, it's just a nicer way to visualize that data that comes from the query plan. STEPHANIE: Gotcha. That makes sense. JOËL: So, that's a very important caveat. I don't think that's something that we mentioned on the episode. So, thank you, Tim, for highlighting that. And for all of our listeners who were intrigued by leaning into EXPLAIN ANALYZE and query plan viewers to debug your slow queries, make sure you try it out in production because you might get different results otherwise. STEPHANIE: So, yeah, that about wraps up our listener topics in recent months. On that note, Joël, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Francis Lacoste enters the podcast to speak about how he fuels growth for VPs of Engineering as a coach. Drawing from decades of startup experience at Heroku and Salesforce, Francis puts into practice operational principles that help teams scale past 20 employees.  He coach technical executives to become leaders who nurture amazing engineering cultures. He help CTOs transition from “building the product" into “building the org that builds the product”. I support them in growing their team building and relational skills.-CareerBefore coaching, he spent over twenty-five years in the open-source and cloud developer tools industry. He started as a software engineer working on open-source technology. He transitioned into engineering management at Canonical. My experience with remote environment led him to Heroku where he built the remote engineering culture. In 2019, he realized that the engineering management path wasn't fulfilling to me, and I move into a role dedicated to supporting the engineering culture within the Salesforce Platform.- I've worked remotely for 24 years. Interested in promoting your product/service via sponsoring the podcast? Fill out this form. Learn more about at https://thevpe.coach

SaaStr 732: What It's Like Running a Profitable $400M Public SaaS Company with Vimeo CEO Adam Gross and SaaStr CEO and Founder Jason Lemkin Vimeo CEO and SaaS veteran Adam Gross and Jason Lemkin, SaaStr founder and CEO, recently hosted a fireside chat at SaaStr Miami, talking about running a profitable public company with $400M in revenue, including themes around:  Using a combination of self-serve and sales-led motions How to juggle and manage several different ICPs  How to avoid over-monetization during tough times Who owns “free” What to expect from AI in the near future Adam is an OG in Cloud and SaaS. His first company was Personify and he went on to be a VP of Developer Relations at Salesforce, then hire number 11 at Dropbox, CEO at Heroku, and an investor and on many boards before landing as the current CEO at Vimeo.  -------------------------------------------------------------------------------------------- SaaStr hosts the largest SaaS community events on the planet. Join us in 2024 at: SaaStr Annual: Sept. 10-12 in the SF Bay Area. Join 12,500 SaaS professionals, CEOs, revenue leaders and investors for the world's LARGEST SaaS community event of the year. Podcast listeners can grab a discount on tickets here: https://www.saastrannual2024.com/buy-tickets?promo=fave20 SaaStr Europa: June 5-6 in London. We'll be hosting the 5th SaaStr Europa in London for two days of content and networking. Join 3,000 SaaS and Cloud leaders. Podcast listeners can grab a discount on Europa tickets here: https://www.saastreuropa2024.com/buy-tickets?promo=fave200 -------------- This episode is sponsored by: Northwest Registered Agent Get more when Northwest Registered Agent starts your business. They'll form your company fast and stand up your entire business identity in minutes. That means business free domain, business email, website, hosting, address, mail scanning, business phone app, all within minutes. Visit https://www.northwestregisteredagent.com/saastr to get a 60 percent discount on your next LLC.

This Friday we're doing a special crossover event in SF with of SemiAnalysis (previous guest!), and we will do a live podcast on site. RSVP here. Also join us on June 25-27 for the biggest AI Engineer conference of the year!Replicate is one of the most popular AI inference providers, reporting over 2 million users as of their $40m Series B with a16z. But how did they get there? The Definitive Replicate Story (warts and all)Their overnight success took 5 years of building, and it all started with arXiv Vanity, which was a 2017 vacation project that scrapes arXiv PDFs and re-renders them into semantic web pages that reflow nicely with better typography and whitespace. From there, Ben and Andreas' idea was to build tools to make ML research more robust and reproducible by making it easy to share code artefacts alongside papers. They had previously created Fig, which made it easy to spin up dev environments; it was eventually acquired by Docker and turned into `docker-compose`, the industry standard way to define services from containerized applications. 2019: CogThe first iteration of Replicate was a Fig-equivalent for ML workloads which they called Cog; it made it easy for researchers to package all their work and share it with peers for review and reproducibility. But they found that researchers were terrible users: they'd do all this work for a paper, publish it, and then never return to it again. “We talked to a bunch of researchers and they really wanted that.... But how the hell is this a business, you know, like how are we even going to make any money out of this? …So we went and talked to a bunch of companies trying to sell them something which didn't exist. So we're like, hey, do you want a way to share research inside your company so that other researchers or say like the product manager can test out the machine learning model? They're like, maybe. Do you want like a deployment platform for deploying models? Do you want a central place for versioning models? We were trying to think of lots of different products we could sell that were related to this thing…So we then got halfway through our YC batch. We hadn't built a product. We had no users. We had no idea what our business was going to be because we couldn't get anybody to like buy something which didn't exist. And actually there was quite a way through our, I think it was like two thirds the way through our YC batch or something. And we're like, okay, well we're kind of screwed now because we don't have anything to show at demo day.”The team graduated YCombinator with no customers, no product and nothing to demo - which was fine because demo day got canceled as the YC W'20 class graduated right into the pandemic. The team spent the next year exploring and building Covid tools.2021: CLIP + GAN = PixRayBy 2021, OpenAI released CLIP. Overnight dozens of Discord servers got spun up to hack on CLIP + GANs. Unlike academic researchers, this community was constantly releasing new checkpoints and builds of models. PixRay was one of the first models being built on Replicate, and it quickly started taking over the community. Chris Dixon has a famous 2010 post titled “The next big thing will start out looking like a toy”; image generation would have definitely felt like a toy in 2021, but it gave Replicate its initial boost.2022: Stable DiffusionIn August 2022 Stable Diffusion came out, and all the work they had been doing to build this infrastructure for CLIP / GANs models became the best way for people to share their StableDiffusion fine-tunes:And like the first week we saw people making animation models out of it. We saw people make game texture models that use circular convolutions to make repeatable textures. We saw a few weeks later, people were fine tuning it so you could put your face in these models and all of these other ways. […] So tons of product builders wanted to build stuff with it. And we were just sitting in there in the middle, as the interface layer between all these people who wanted to build, and all these machine learning experts who were building cool models. And that's really where it took off. Incredible supply, incredible demand, and we were just in the middle.(Stable Diffusion also spawned Latent Space as a newsletter)The landing page paved the cowpath for the intense interest in diffusion model APIs.2023: Llama & other multimodal LLMsBy 2023, Replicate's growing visibility in the Stable Diffusion indie hacker community came from top AI hackers like Pieter Levels and Danny Postmaa, each making millions off their AI apps:Meta then released LLaMA 1 and 2 (our coverage of it), greatly pushing forward the SOTA open source model landscape. Demand for text LLMs and other modalities rose, and Replicate broadened its focus accordingly, culminating in a $18m Series A and $40m Series B from a16z (at a $350m valuation).Building standards for the AI worldNow that the industry is evolving from toys to enterprise use cases, all these companies are working to set standards for their own space. We cover this at ~45 mins in the podcast. Some examples:* LangChain has been trying to establish "chain” as the standard mental models when putting multiple prompts and models together, and the “LangChain Expression Language” to go with it. (Our episode with Harrison)* LLamaHub for packaging RAG utilities. (Our episode with Jerry)* Ollama's Modelfile to define runtimes for different model architectures. These are usually targeted at local inference. * Cog (by Replicate) to create environments to which you can easily attach CUDA devices and make it easy to spin up inference on remote servers. * GGUF as the filetype ggml-based executors. None of them have really broken out yet, but this is going to become a fiercer competition as the market matures. Full Video PodcastAs a reminder, all Latent Space pods now come in full video on our YouTube, with bonus content that we cut for time!Show Notes* Ben Firshman* Replicate* Free $10 credit for Latent Space readers* Andreas Jansson (Ben's co-founder)* Charlie Holtz (Replicate's Hacker in Residence)* Fig (now Docker Compose)* Command Line Interface Guidelines (clig)* Apple Human Interface Guidelines* arXiv Vanity* Open Interpreter* PixRay* SF Compute* Big Sleep by Advadnoun* VQGAN-CLIP by Rivers Have WingsTimestamps* [00:00:00] Introductions* [00:01:17] Low latency is all you need* [00:04:08] Evolution of CLIs* [00:05:59] How building ArxivVanity led to Replicate* [00:11:37] Making ML research replicable with containers* [00:17:22] Doing YC in 2020 and pivoting to tools for COVID* [00:20:22] Launching the first version of Replicate* [00:25:51] Embracing the generative image community* [00:28:04] Getting reverse engineered into an API product* [00:31:25] Growing to 2 million users* [00:34:29] Indie vs Enterprise customers* [00:37:09] How Unsplash uses Replicate* [00:38:29] Learnings from Docker that went into Cog* [00:45:25] Creating AI standards* [00:50:05] Replicate's compute availability* [00:53:55] Fixing GPU waste* [01:00:39] What's open source AI?* [01:04:46] Building for AI engineers* [01:06:41] Hiring at ReplicateThis summary covers the full range of topics discussed throughout the episode, providing a comprehensive overview of the content and insights shared.TranscriptAlessio [00:00:00]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO in Residence at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:14]: Hey, and today we have Ben Firshman in the studio. Welcome Ben.Ben [00:00:18]: Hey, good to be here.Swyx [00:00:19]: Ben, you're a co-founder and CEO of Replicate. Before that, you were most notably founder of Fig, which became Docker Compose. You also did a couple of other things before that, but that's what a lot of people know you for. What should people know about you that, you know, outside of your, your sort of LinkedIn profile?Ben [00:00:35]: Yeah. Good question. I think I'm a builder and tinkerer, like in a very broad sense. And I love using my hands to make things. So like I work on, you know, things may be a bit closer to tech, like electronics. I also like build things out of wood and I like fix cars and I fix my bike and build bicycles and all this kind of stuff. And there's so much, I think I've learned from transferable skills, from just like working in the real world to building things, building things in software. And you know, it's so much about being a builder, both in real life and, and in software that crosses over.Swyx [00:01:11]: Is there a real world analogy that you use often when you're thinking about like a code architecture or problem?Ben [00:01:17]: I like to build software tools as if they were something real. So I wrote this thing called the command line interface guidelines, which was a bit like sort of the Mac human interface guidelines, but for command line interfaces, I did it with the guy I created Docker Compose with and a few other people. And I think something in there, I think I described that your command line interface should feel like a big iron machine where you pull a lever and it goes clunk and like things should respond within like 50 milliseconds as if it was like a real life thing. And like another analogy here is like in the real life, you know, when you press a button on an electronic device and it's like a soft switch and you press it and nothing happens and there's no physical feedback of anything happening, then like half a second later, something happens. Like that's how a lot of software feels, but instead like software should feel more like something that's real where you touch, you pull a physical lever and the physical lever moves, you know, and I've taken that lesson of kind of human interface to, to software a ton. You know, it's all about kind of low latency of feeling, things feeling really solid and robust, both the command lines and, and user interfaces as well.Swyx [00:02:22]: And how did you operationalize that for Fig or Docker?Ben [00:02:27]: A lot of it's just low latency. Actually, we didn't do it very well for Fig in the first place. We used Python, which was a big mistake where Python's really hard to get booting up fast because you have to load up the whole Python runtime before it can run anything. Okay. Go is much better at this where like Go just instantly starts.Swyx [00:02:45]: You have to be under 500 milliseconds to start up?Ben [00:02:48]: Yeah, effectively. I mean, I mean, you know, perception of human things being immediate is, you know, something like a hundred milliseconds. So anything like that is, is yeah, good enough.Swyx [00:02:57]: Yeah. Also, I should mention, since we're talking about your side projects, well, one thing is I am maybe one of a few fellow people who have actually written something about CLI design principles because I was in charge of the Netlify CLI back in the day and had many thoughts. One of my fun thoughts, I'll just share it in case you have thoughts, is I think CLIs are effectively starting points for scripts that are then run. And the moment one of the script's preconditions are not fulfilled, typically they end. So the CLI developer will just exit the program. And the way that I designed, I really wanted to create the Netlify dev workflow was for it to be kind of a state machine that would resolve itself. If it detected a precondition wasn't fulfilled, it would actually delegate to a subprogram that would then fulfill that precondition, asking for more info or waiting until a condition is fulfilled. Then it would go back to the original flow and continue that. I don't know if that was ever tried or is there a more formal definition of it? Because I just came up with it randomly. But it felt like the beginnings of AI in the sense that when you run a CLI command, you have an intent to do something and you may not have given the CLI all the things that it needs to do, to execute that intent. So that was my two cents.Ben [00:04:08]: Yeah, that reminds me of a thing we sort of thought about when writing the CLI guidelines, where CLIs were designed in a world where the CLI was really a programming environment and it's primarily designed for machines to use all of these commands and scripts. Whereas over time, the CLI has evolved to humans. It was back in a world where the primary way of using computers was writing shell scripts effectively. We've transitioned to a world where actually humans are using CLI programs much more than they used to. And the current sort of best practices about how Unix was designed, there's lots of design documents about Unix from the 70s and 80s, where they say things like, command line commands should not output anything on success. It should be completely silent, which makes sense if you're using it in a shell script. But if a user is using that, it just looks like it's broken. If you type copy and it just doesn't say anything, you assume that it didn't work as a new user. I think what's really interesting about the CLI is that it's actually a really good, to your point, it's a really good user interface where it can be like a conversation, where it feels like you're, instead of just like you telling the computer to do this thing and either silently succeeding or saying, no, you did, failed, it can guide you in the right direction and tell you what your intent might be, and that kind of thing in a way that's actually, it's almost more natural to a CLI than it is in a graphical user interface because it feels like this back and forth with the computer, almost funnily like a language model. So I think there's some interesting intersection of CLIs and language models actually being very sort of closely related and a good fit for each other.Swyx [00:05:59]: Yeah, I'll say one of the surprises from last year, I worked on a coding agent, but I think the most successful coding agent of my cohort was Open Interpreter, which was a CLI implementation. And I have chronically, even as a CLI person, I have chronically underestimated the CLI as a useful interface. You also developed ArchiveVanity, which you recently retired after a glorious seven years.Ben [00:06:22]: Something like that.Swyx [00:06:23]: Which is nice, I guess, HTML PDFs.Ben [00:06:27]: Yeah, that was actually the start of where Replicate came from. Okay, we can tell that story. So when I quit Docker, I got really interested in science infrastructure, just as like a problem area, because it is like science has created so much progress in the world. The fact that we're, you know, can talk to each other on a podcast and we use computers and the fact that we're alive is probably thanks to medical research, you know. But science is just like completely archaic and broken and it's like 19th century processes that just happen to be copied to the internet rather than take into account that, you know, we can transfer information at the speed of light now. And the whole way science is funded and all this kind of thing is all kind of very broken. And there's just so much potential for making science work better. And I realized that I wasn't a scientist and I didn't really have any time to go and get a PhD and become a researcher, but I'm a tool builder and I could make existing scientists better at their job. And if I could make like a bunch of scientists a little bit better at their job, maybe that's the kind of equivalent of being a researcher. So one particular thing I dialed in on is just how science is disseminated in that all of these PDFs, quite often behind paywalls, you know, on the internet.Swyx [00:07:34]: And that's a whole thing because it's funded by national grants, government grants, then they're put behind paywalls. Yeah, exactly.Ben [00:07:40]: That's like a whole, yeah, I could talk for hours about that. But the particular thing we got dialed in on was, interestingly, these PDFs are also, there's a bunch of open science that happens as well. So math, physics, computer science, machine learning, notably, is all published on the archive, which is actually a surprisingly old institution.Swyx [00:08:00]: Some random Cornell.Ben [00:08:01]: Yeah, it was just like somebody in Cornell who started a mailing list in the 80s. And then when the web was invented, they built a web interface around it. Like it's super old.Swyx [00:08:11]: And it's like kind of like a user group thing, right? That's why they're all these like numbers and stuff.Ben [00:08:15]: Yeah, exactly. Like it's a bit like something, yeah. That's where all basically all of math, physics and computer science happens. But it's still PDFs published to this thing. Yeah, which is just so infuriating. The web was invented at CERN, a physics institution, to share academic writing. Like there are figure tags, there are like author tags, there are heading tags, there are site tags. You know, hyperlinks are effectively citations because you want to link to another academic paper. But instead, you have to like copy and paste these things and try and get around paywalls. Like it's absurd, you know. And now we have like social media and things, but still like academic papers as PDFs, you know. This is not what the web was for. So anyway, I got really frustrated with that. And I went on vacation with my old friend Andreas. So we were, we used to work together in London on a startup, at somebody else's startup. And we were just on vacation in Greece for fun. And he was like trying to read a machine learning paper on his phone, you know, like we had to like zoom in and like scroll line by line on the PDF. And he was like, this is f*****g stupid. So I was like, I know, like this is something we discovered our mutual hatred for this, you know. And we spent our vacation sitting by the pool, like making latex to HTML, like converters, making the first version of Archive Vanity. Anyway, that was up then a whole thing. And the story, we shut it down recently because they caught the eye of Archive. They were like, oh, this is great. We just haven't had the time to work on this. And what's tragic about the Archive, it's like this project of Cornell that's like, they can barely scrounge together enough money to survive. I think it might be better funded now than it was when we were, we were collaborating with them. And compared to these like scientific journals, it's just that this is actually where the work happens. But they just have a fraction of the money that like these big scientific journals have, which is just so tragic. But anyway, they were like, yeah, this is great. We can't afford to like do it, but do you want to like as a volunteer integrate arXiv Vanity into arXiv?Swyx [00:10:05]: Oh, you did the work.Ben [00:10:06]: We didn't do the work. We started doing the work. We did some. I think we worked on this for like a few months to actually get it integrated into arXiv. And then we got like distracted by Replicate. So a guy called Dan picked up the work and made it happen. Like somebody who works on one of the, the piece of the libraries that powers arXiv Vanity. Okay.Swyx [00:10:26]: And the relationship with arXiv Sanity?Ben [00:10:28]: None.Swyx [00:10:30]: Did you predate them? I actually don't know the lineage.Ben [00:10:32]: We were after, we both were both users of arXiv Sanity, which is like a sort of arXiv...Ben [00:10:37]: Which is Andre's RecSys on top of arXiv.Ben [00:10:40]: Yeah. Yeah. And we were both users of that. And I think we were trying to come up with a working name for arXiv and Andreas just like cracked a joke of like, oh, let's call it arXiv Vanity. Let's make the papers look nice. Yeah. Yeah. And that was the working name and it just stuck.Swyx [00:10:52]: Got it.Ben [00:10:53]: Got it.Alessio [00:10:54]: Yeah. And then from there, tell us more about why you got distracted, right? So Replicate, maybe it feels like an overnight success to a lot of people, but you've been building this since 2019. Yeah.Ben [00:11:04]: So what prompted the start?Alessio [00:11:05]: And we've been collaborating for even longer.Ben [00:11:07]: So we created arXiv Vanity in 2017. So in some sense, we've been doing this almost like six, seven years now, a classic seven year.Swyx [00:11:16]: Overnight success.Ben [00:11:17]: Yeah. Yes. We did arXiv Vanity and then worked on a bunch of like surrounding projects. I was still like really interested in science publishing at that point. And I'm trying to remember, because I tell a lot of like the condensed story to people because I can't really tell like a seven year history. So I'm trying to figure out like the right. Oh, we got room. The right length.Swyx [00:11:35]: We want to nail the definitive Replicate story here.Ben [00:11:37]: One thing that's really interesting about these machine learning papers is that these machine learning papers are published on arXiv and a lot of them are actual fundamental research. So like should be like prose describing a theory. But a lot of them are just running pieces of software that like a machine learning researcher made that did something, you know, it was like an image classification model or something. And they managed to make an image classification model that was better than the existing state of the art. And they've made an actual running piece of software that does image segmentation. And then what they had to do is they then had to take that piece of software and write it up as prose and math in a PDF. And what's frustrating about that is like if you want to. So this was like Andreas is, Andreas was a machine learning engineer at Spotify. And some of his job was like he did pure research as well. Like he did a PhD and he was doing a lot of stuff internally. But part of his job was also being an engineer and taking some of these existing things that people have made and published and trying to apply them to actual problems at Spotify. And he was like, you know, you get given a paper which like describes roughly how the model works. It's probably listing lots of crucial information. There's sometimes code on GitHub. More and more there's code on GitHub. But back then it was kind of relatively rare. But it's quite often just like scrappy research code and didn't actually run. And, you know, there was maybe the weights that were on Google Drive, but they accidentally deleted the weights of Google Drive, you know, and it was like really hard to like take this stuff and actually use it for real things. We just started talking together about like his problems at Spotify and I connected this back to my work at Docker as well. I was like, oh, this is what we created containers for. You know, we solved this problem for normal software by putting the thing inside a container so you could ship it around and it kept on running. So we were sort of hypothesizing about like, hmm, what if we put machine learning models inside containers so they could actually be shipped around and they could be defined in like some production ready formats and other researchers could run them to generate baselines and you could people who wanted to actually apply them to real problems in the world could just pick up the container and run it, you know. And we then thought this is quite whether it gets normally in this part of the story I skip forward to be like and then we created cog this container stuff for machine learning models and we created Replicate, the place for people to publish these machine learning models. But there's actually like two or three years between that. The thing we then got dialed into was Andreas was like, what if there was a CI system for machine learning? It's like one of the things he really struggled with as a researcher is generating baselines. So when like he's writing a paper, he needs to like get like five other models that are existing work and get them running.Swyx [00:14:21]: On the same evals.Ben [00:14:22]: Exactly, on the same evals so you can compare apples to apples because you can't trust the numbers in the paper.Swyx [00:14:26]: So you can be Google and just publish them anyway.Ben [00:14:31]: So I think this was coming from the thinking of like there should be containers for machine learning, but why are people going to use that? Okay, maybe we can create a supply of containers by like creating this useful tool for researchers. And the useful tool was like, let's get researchers to package up their models and push them to the central place where we run a standard set of benchmarks across the models so that you can trust those results and you can compare these models apples to apples and for like a researcher for Andreas, like doing a new piece of research, he could trust those numbers and he could like pull down those models, confirm it on his machine, use the standard benchmark to then measure his model and you know, all this kind of stuff. And so we started building that. That's what we applied to YC with, got into YC and we started sort of building a prototype of this. And then this is like where it all starts to fall apart. We were like, okay, that sounds great. And we talked to a bunch of researchers and they really wanted that and that sounds brilliant. That's a great way to create a supply of like models on this research platform. But how the hell is this a business, you know, like how are we even going to make any money out of this? And we're like, oh s**t, that's like the, that's the real unknown here of like what the business is. So we thought it would be a really good idea to like, okay, before we get too deep into this, let's try and like reduce the risk of this turning into a business. So let's try and like research what the business could be for this research tool effectively. So we went and talked to a bunch of companies trying to sell them something which didn't exist. So we're like, hey, do you want a way to share research inside your company so that other researchers or say like the product manager can test out the machine learning model? They're like, maybe. And we were like, do you want like a deployment platform for deploying models? Like, do you want like a central place for versioning models? Like we're trying to think of like lots of different like products we could sell that were like related to this thing. And terrible idea. Like we're not sales people and like people don't want to buy something that doesn't exist. I think some people can pull this off, but we were just like, you know, a bunch of product people, products and engineer people, and we just like couldn't pull this off. So we then got halfway through our YC batch. We hadn't built a product. We had no users. We had no idea what our business was going to be because we couldn't get anybody to like buy something which didn't exist. And actually there was quite a way through our, I think it was like two thirds the way through our YC batch or something. And we're like, okay, well we're kind of screwed now because we don't have anything to show at demo day. And then we then like tried to figure out, okay, what can we build in like two weeks that'll be something. So we like desperately tried to, I can't remember what we've tried to build at that point. And then two weeks before demo day, I just remember it was all, we were going down to Mountain View every week for dinners and we got called on to like an all hands Zoom call, which was super weird. We're like, what's going on? And they were like, don't come to dinner tomorrow. And we realized, we kind of looked at the news and we were like, oh, there's a pandemic going on. We were like so deep in our startup. We were just like completely oblivious to what was going on around us.Swyx [00:17:20]: Was this Jan or Feb 2020?Ben [00:17:22]: This was March 2020. March 2020. 2020.Swyx [00:17:25]: Yeah. Because I remember Silicon Valley at the time was early to COVID. Like they started locking down a lot faster than the rest of the US.Ben [00:17:32]: Yeah, exactly. And I remember, yeah, soon after that, like there was the San Francisco lockdowns and then like the YC batch just like stopped. There wasn't demo day and it was in a sense a blessing for us because we just kind ofSwyx [00:17:43]: In the normal course of events, you're actually allowed to defer to a future demo day. Yeah.Ben [00:17:51]: So we didn't even take any defer because it just kind of didn't happen.Swyx [00:17:55]: So was YC helpful?Ben [00:17:57]: Yes. We completely screwed up the batch and that was our fault. I think the thing that YC has become incredibly valuable for us has been after YC. I think there was a reason why we couldn't, didn't need to do YC to start with because we were quite experienced. We had done some startups before. We were kind of well connected with VCs, you know, it was relatively easy to raise money because we were like a known quantity. You know, if you go to a VC and be like, Hey, I made this piece of-Swyx [00:18:24]: It's Docker Compose for AI.Ben [00:18:26]: Exactly. Yeah. And like, you know, people can pattern match like that and they can have some trust, you know what you're doing. Whereas it's much harder for people straight out of college and that's where like YC sweet spot is like helping people straight out of college who are super promising, like figure out how to do that.Swyx [00:18:40]: No credentials.Ben [00:18:41]: Yeah, exactly. We don't need that. But the thing that's been incredibly useful for us since YC has been, this was actually, I think, so Docker was a YC company and Solomon, the founder of Docker, I think told me this. He was like, a lot of people underestimate the value of YC after you finish the batch. And his biggest regret was like not staying in touch with YC. I might be misattributing this, but I think it was him. And so we made a point of that. And we just stayed in touch with our batch partner, who Jared at YC has been fantastic.Ben [00:19:10]: Jared Friedman. All of like the team at YC, there was the growth team at YC when they were still there and they've been super helpful. And two things have been super helpful about that is like raising money, like they just know exactly how to raise money. And they've been super helpful during that process in all of our rounds, like we've done three rounds since we did YC and they've been super helpful during the whole process. And also just like reaching a ton of customers. So like the magic of YC is that you have all of, like there's thousands of YC companies, I think, on the order of thousands, I think. And they're all of your first customers. And they're like super helpful, super receptive, really want to like try out new things. You have like a warm intro to every one of them basically. And there's this mailing list where you can post about updates to your products, which is like really receptive. And that's just been fantastic for us. Like we've just like got so many of our users and customers through YC. Yeah.Swyx [00:20:00]: Well, so the classic criticism or the sort of, you know, pushback is people don't buy you because you are both from YC. But at least they'll open the email. Right. Like that's the... Okay.Ben [00:20:13]: Yeah. Yeah. Yeah.Swyx [00:20:16]: So that's been a really, really positive experience for us. And sorry, I interrupted with the YC question. Like you were, you make it, you just made it out of the YC, survived the pandemic.Ben [00:20:22]: I'll try and condense this a little bit. Then we started building tools for COVID weirdly. We were like, okay, we don't have a startup. We haven't figured out anything. What's the most useful thing we could be doing right now?Swyx [00:20:32]: Save lives.Ben [00:20:33]: So yeah. Let's try and save lives. I think we failed at that as well. We had a bunch of products that didn't really go anywhere. We kind of worked on, yeah, a bunch of stuff like contact tracing, which turned out didn't really be a useful thing. Sort of Andreas worked on like a door dash for like people delivering food to people who are vulnerable. What else did we do? The meta problem of like helping people direct their efforts to what was most useful and a few other things like that. It didn't really go anywhere. So we're like, okay, this is not really working either. We were considering actually just like doing like work for COVID. We have this decision document early on in our company, which is like, should we become a like government app contracting shop? We decided no.Swyx [00:21:11]: Because you also did work for the gov.uk. Yeah, exactly.Ben [00:21:14]: We had experience like doing some like-Swyx [00:21:17]: And the Guardian and all that.Ben [00:21:18]: Yeah. For like government stuff. And we were just like really good at building stuff. Like we were just like product people. Like I was like the front end product side and Andreas was the back end side. So we were just like a product. And we were working with a designer at the time, a guy called Mark, who did our early designs for Replicate. And we were like, hey, what if we just team up and like become and build stuff? And yeah, we gave up on that in the end for, I can't remember the details. So we went back to machine learning. And then we were like, well, we're not really sure if this is going to work. And one of my most painful experiences from previous startups is shutting them down. Like when you realize it's not really working and having to shut it down, it's like a ton of work and it's people hate you and it's just sort of, you know. So we were like, how can we make something we don't have to shut down? And even better, how can we make something that won't page us in the middle of the night? So we made an open source project. We made a thing which was an open source Weights and Biases, because we had this theory that like people want open source tools. There should be like an open source, like version control, experiment tracking like thing. And it was intuitive to us and we're like, oh, we're software developers and we like command line tools. Like everyone loves command line tools and open source stuff, but machine learning researchers just really didn't care. Like they just wanted to click on buttons. They didn't mind that it was a cloud service. It was all very visual as well, that you need lots of graphs and charts and stuff like this. So it wasn't right. Like it was right. We actually were building something that Andreas made at Spotify for just like saving experiments to cloud storage automatically, but other people didn't really want this. So we kind of gave up on that. And then that was actually originally called Replicate and we renamed that out of the way. So it's now called Keepsake and I think some people still use it. Then we sort of came back, we looped back to our original idea. So we were like, oh, maybe there was a thing in that thing we were originally sort of thinking about of like researchers sharing their work and containers for machine learning models. So we just built that. And at that point we were kind of running out of the YC money. So we were like, okay, this like feels good though. Let's like give this a shot. So that was the point we raised a seed round. We raised seed round. Pre-launch. We raised pre-launch and pre-team. It was an idea basically. We had a little prototype. It was just an idea and a team. But we were like, okay, like, you know, bootstrapping this thing is getting hard. So let's actually raise some money. Then we made Cog and Replicate. It initially didn't have APIs, interestingly. It was just the bit that I was talking about before of helping researchers share their work. So it was a way for researchers to put their work on a webpage such that other people could try it out and so that you could download the Docker container. We cut the benchmarks thing of it because we thought that was just like too complicated. But it had a Docker container that like, you know, Andreas in a past life could download and run with his benchmark and you could compare all these models apples to apples. So that was like the theory behind it. That kind of started to work. It was like still when like, you know, it was long time pre-AI hype and there was lots of interesting stuff going on, but it was very much in like the classic deep learning era. So sort of image segmentation models and sentiment analysis and all these kinds of things, you know, that people were using, that we're using deep learning models for. And we were very much building for research because all of this stuff was happening in research institutions, you know, the sort of people who'd be publishing to archive. So we were creating an accompanying material for their models, basically, you know, they wanted a demo for their models and we were creating a company material for it. What was funny about that is they were like not very good users. Like they were, they were doing great work obviously, but, but the way that research worked is that they, they just made like one thing every six months and they just fired and forget it, forgot it. Like they, they published this piece of paper and like, done, I've, I've published it. So they like output it to Replicate and then they just stopped using Replicate. You know, they were like once every six monthly users and that wasn't great for us, but we stumbled across this early community. This was early 2021 when OpenAI created this, created CLIP and people started smushing CLIP and GANs together to produce image generation models. And this started with, you know, it was just a bunch of like tinkerers on Discord, basically. There was an early model called Big Sleep by Advadnoun. And then there was VQGAN Clip, which was like a bit more popular by Rivers Have Wings. And it was all just people like tinkering on stuff in Colabs and it was very dynamic and it was people just making copies of co-labs and playing around with things and forking in. And to me this, I saw this and I was like, oh, this feels like open source software, like so much more than the research world where like people are publishing these papers.Swyx [00:25:48]: You don't know their real names and it's just like a Discord.Ben [00:25:51]: Yeah, exactly. But crucially, it was like people were tinkering and forking and things were moving really fast and it just felt like this creative, dynamic, collaborative community in a way that research wasn't really, like it was still stuck in this kind of six month publication cycle. So we just kind of latched onto that and started building for this community. And you know, a lot of those early models were published on Replicate. I think the first one that was really primarily on Replicate was one called Pixray, which was sort of mid 2021 and it had a really cool like pixel art output, but it also just like produced general, you know, the sort of, they weren't like crisp in images, but they were quite aesthetically pleasing, like some of these early image generation models. And you know, that was like published primarily on Replicate and then a few other models around that were like published on Replicate. And that's where we really started to find our early community and like where we really found like, oh, we've actually built a thing that people want and they were great users as well. And people really want to try out these models. Lots of people were like running the models on Replicate. We still didn't have APIs though, interestingly, and this is like another like really complicated part of the story. We had no idea what a business model was still at this point. I don't think people could even pay for it. You know, it was just like these web forms where people could run the model.Swyx [00:27:06]: Just for historical interest, which discords were they and how did you find them? Was this the Lion Discord? Yeah, Lion. This is Eleuther.Ben [00:27:12]: Eleuther, yeah. It was the Eleuther one. These two, right? There was a channel where Viki Gangklep, this was early 2021, where Viki Gangklep was set up as a Discord bot. I just remember being completely just like captivated by this thing. I was just like playing around with it all afternoon and like the sort of thing. In Discord. Oh s**t, it's 2am. You know, yeah.Swyx [00:27:33]: This is the beginnings of Midjourney.Ben [00:27:34]: Yeah, exactly. And Stability. It was the start of Midjourney. And you know, it's where that kind of user interface came from. Like what's beautiful about the user interface is like you could see what other people are doing. And you could riff off other people's ideas. And it was just so much fun to just like play around with this in like a channel full of a hundred people. And yeah, that just like completely captivated me and I'm like, okay, this is something, you know. So like we should get these things on Replicate. Yeah, that's where that all came from.Swyx [00:28:00]: And then you moved on to, so was it APIs next or was it Stable Diffusion next?Ben [00:28:04]: It was APIs next. And the APIs happened because one of our users, our web form had like an internal API for making the web form work, like with an API that was called from JavaScript. And somebody like reverse engineered that to start generating images with a script. You know, they did like, you know, Web Inspector Coffee is Carl, like figured out what the API request was. And it wasn't secured or anything.Swyx [00:28:28]: Of course not.Ben [00:28:29]: They started generating a bunch of images and like we got tons of traffic and like what's going on? And I think like a sort of usual reaction to that would be like, hey, you're abusing our API and to shut them down. And instead we're like, oh, this is interesting. Like people want to run these models. So we documented the API in a Notion document, like our internal API in a Notion document and like message this person being like, hey, you seem to have found our API. Here's the documentation. That'll be like a thousand bucks a month, please, with a straight form, like we just click some buttons to make. And they were like, sure, that sounds great. So that was our first customer.Swyx [00:29:05]: A thousand bucks a month.Ben [00:29:07]: It was a surprising amount of money. That's not casual. It was on the order of a thousand bucks a month.Swyx [00:29:11]: So was it a business?Ben [00:29:13]: It was the creator of PixRay. Like it was, he generated NFT art. And so he like made a bunch of art with these models and was, you know, selling these NFTs effectively. And I think lots of people in his community were doing similar things. And like he then referred us to other people who were also generating NFTs and he joined us with models. We started our API business. Yeah. Then we like made an official API and actually like added some billing to it. So it wasn't just like a fixed fee.Swyx [00:29:40]: And now people think of you as the host and models API business. Yeah, exactly.Ben [00:29:44]: But that just turned out to be our business, you know, but what ended up being beautiful about this is it was really fulfilling. Like the original goal of what we wanted to do is that we wanted to make this research that people were making accessible to like other people and for it to be used in the real world. And this was like the just like ultimately the right way to do it because all of these people making these generative models could publish them to replicate and they wanted a place to publish it. And software engineers, you know, like myself, like I'm not a machine learning expert, but I want to use this stuff, could just run these models with a single line of code. And we thought, oh, maybe the Docker image is enough, but it's actually super hard to get the Docker image running on a GPU and stuff. So it really needed to be the hosted API for this to work and to make it accessible to software engineers. And we just like wound our way to this. Yeah.Swyx [00:30:30]: Two years to the first paying customer. Yeah, exactly.Alessio [00:30:33]: Did you ever think about becoming Midjourney during that time? You have like so much interest in image generation.Swyx [00:30:38]: I mean, you're doing fine for the record, but, you know, it was right there, you were playing with it.Ben [00:30:46]: I don't think it was our expertise. Like I think our expertise was DevTools rather than like Midjourney is almost like a consumer products, you know? Yeah. So I don't think it was our expertise. It certainly occurred to us. I think at the time we were thinking about like, oh, maybe we could hire some of these people in this community and make great models and stuff like this. But we ended up more being at the tooling. Like I think like before I was saying, like I'm not really a researcher, but I'm more like the tool builder, the behind the scenes. And I think both me and Andreas are like that.Swyx [00:31:09]: I think this is an illustration of the tool builder philosophy. Something where you latch on to in DevTools, which is when you see people behaving weird, it's not their fault, it's yours. And you want to pave the cow paths is what they say, right? Like the unofficial paths that people are making, like make it official and make it easy for them and then maybe charge a bit of money.Alessio [00:31:25]: And now fast forward a couple of years, you have 2 million developers using Replicate. Maybe more. That was the last public number that I found.Ben [00:31:33]: It's 2 million users. Not all those people are developers, but a lot of them are developers, yeah.Alessio [00:31:38]: And then 30,000 paying customers was the number late in space runs on Replicate. So we had a small podcaster and we host a whisper diarization on Replicate. And we're paying. So we're late in space in the 30,000. You raised a $40 million dollars, Series B. I would say that maybe the stable diffusion time, August 22, was like really when the company started to break out. Tell us a bit about that and the community that came out and I know now you're expanding beyond just image generation.Ben [00:32:06]: Yeah, like I think we kind of set ourselves, like we saw there was this really interesting image, generative image world going on. So we kind of, you know, like we're building the tools for that community already, really. And we knew stable diffusion was coming out. We knew it was a really exciting thing, you know, it was the best generative image model so far. I think the thing we underestimated was just like what an inflection point it would be, where it was, I think Simon Willison put it this way, where he said something along the lines of it was a model that was open source and tinkerable and like, you know, it was just good enough and open source and tinkerable such that it just kind of took off in a way that none of the models had before. And like what was really neat about stable diffusion is it was open source so you could like, compared to like Dali, for example, which was like sort of equivalent quality. And like the first week we saw like people making animation models out of it. We saw people make like game texture models that like use circular convolutions to make repeatable textures. We saw, you know, a few weeks later, like people were fine tuning it so you could make, put your face in these models and all of these other-Swyx [00:33:10]: Textual inversion.Ben [00:33:11]: Yep. Yeah, exactly. That happened a bit before that. And all of this sort of innovation was happening all of a sudden. And people were publishing on Replicate because you could just like publish arbitrary models on Replicate. So we had this sort of supply of like interesting stuff being built. But because it was a sufficiently good model, there was also just like a ton of people building with it. They were like, oh, we can build products with this thing. And this was like about the time where people were starting to get really interested in AI. So like tons of product builders wanted to build stuff with it. And we were just like sitting in there in the middle, it's like the interface layer between like all these people who wanted to build and all these like machine learning experts who were building cool models. And that's like really where it took off. We were just sort of incredible supply, incredible demand, and we were just like in the middle. And then, yeah, since then, we've just kind of grown and grown really. And we've been building a lot for like the indie hacker community, these like individual tinkerers, but also startups and a lot of large companies as well who are sort of exploring and building AI things. Then kind of the same thing happened like middle of last year with language models and Lama 2, where the same kind of stable diffusion effect happened with Lama. And Lama 2 was like our biggest week of growth ever because like tons of people wanted to tinker with it and run it. And you know, since then we've just been seeing a ton of growth in language models as well as image models. Yeah. We're just kind of riding a lot of the interest that's going on in AI and all the people building in AI, you know. Yeah.Swyx [00:34:29]: Kudos. Right place, right time. But also, you know, took a while to position for the right place before the wave came. I'm curious if like you have any insights on these different markets. So Peter Levels, notably very loud person, very picky about his tools. I wasn't sure actually if he used you. He does. So you've met him on your Series B blog posts and Danny Post might as well, his competitor all in that wave. What are their needs versus, you know, the more enterprise or B2B type needs? Did you come to a decision point where you're like, okay, you know, how serious are these indie hackers versus like the actual businesses that are bigger and perhaps better customers because they're less churny?Ben [00:35:04]: They're surprisingly similar because I think a lot of people right now want to use and build with AI, but they're not AI experts and they're not infrastructure experts either. So they want to be able to use this stuff without having to like figure out all the internals of the models and, you know, like touch PyTorch and whatever. And they also don't want to be like setting up and booting up servers. And that's the same all the way from like indie hackers just getting started because like obviously you just want to get started as quickly as possible, all the way through to like large companies who want to be able to use this stuff, but don't have like all of the experts on stuff, you know, you know, big companies like Google and so on that do actually have a lot of experts on stuff, but the vast majority of companies don't. And they're all software engineers who want to be able to use this AI stuff, but they just don't know how to use it. And it's like, you really need to be an expert and it takes a long time to like learn the skills to be able to use that. So they're surprisingly similar in that sense. I think it's kind of also unfair of like the indie community, like they're not churning surprisingly, or churny or spiky surprisingly, like they're building real established businesses, which is like, kudos to them, like building these really like large, sustainable businesses, often just as solo developers. And it's kind of remarkable how they can do that actually, and it's in credit to a lot of their like product skills. And you know, we're just like there to help them being like their machine learning team effectively to help them use all of this stuff. A lot of these indie hackers are some of our largest customers, like alongside some of our biggest customers that you would think would be spending a lot more money than them, but yeah.Swyx [00:36:35]: And we should name some of these. So you have them on your landing page, your Buzzfeed, you have Unsplash, Character AI. What do they power? What can you say about their usage?Ben [00:36:43]: Yeah, totally. It's kind of a various things.Swyx [00:36:46]: Well, I mean, I'm naming them because they're on your landing page. So you have logo rights. It's useful for people to, like, I'm not imaginative. I see monkey see monkey do, right? Like if I see someone doing something that I want to do, then I'm like, okay, Replicate's great for that.Ben [00:37:00]: Yeah, yeah, yeah.Swyx [00:37:01]: So that's what I think about case studies on company landing pages is that it's just a way of explaining like, yep, this is something that we are good for. Yeah, totally.Ben [00:37:09]: I mean, it's, these companies are doing things all the way up and down the stack at different levels of sophistication. So like Unsplash, for example, they actually publicly posted this story on Twitter where they're using BLIP to annotate all of the images in their catalog. So you know, they have lots of images in the catalog and they want to create a text description of it so you can search for it. And they're annotating images with, you know, off the shelf, open source model, you know, we have this big library of open source models that you can run. And you know, we've got lots of people are running these open source models off the shelf. And then most of our larger customers are doing more sophisticated stuff. So they're like fine tuning the models, they're running completely custom models on us. A lot of these larger companies are like, using us for a lot of their, you know, inference, but it's like a lot of custom models and them like writing the Python themselves because they've got machine learning experts on the team. And they're using us for like, you know, their inference infrastructure effectively. And so it's like lots of different levels of sophistication where like some people using these off the shelf models. Some people are fine tuning models. So like level, Peter Levels is a great example where a lot of his products are based off like fine tuning, fine tuning image models, for example. And then we've also got like larger customers who are just like using us as infrastructure effectively. So yeah, it's like all things up and down, up and down the stack.Alessio [00:38:29]: Let's talk a bit about COG and the technical layer. So there are a lot of GPU clouds. I think people have different pricing points. And I think everybody tries to offer a different developer experience on top of it, which then lets you charge a premium. Why did you want to create COG?Ben [00:38:46]: You worked at Docker.Alessio [00:38:47]: What were some of the issues with traditional container runtimes? And maybe yeah, what were you surprised with as you built it?Ben [00:38:54]: COG came right from the start, actually, when we were thinking about this, you know, evaluation, the sort of benchmarking system for machine learning researchers, where we wanted researchers to publish their models in a standard format that was guaranteed to keep on running, that you could replicate the results of, like that's where the name came from. And we realized that we needed something like Docker to make that work, you know. And I think it was just like natural from my point of view of like, obviously that should be open source, that we should try and create some kind of open standard here that people can share. Because if more people use this format, then that's great for everyone involved. I think the magic of Docker is not really in the software. It's just like the standard that people have agreed on, like, here are a bunch of keys for a JSON document, basically. And you know, that was the magic of like the metaphor of real containerization as well. It's not the containers that are interesting. It's just like the size and shape of the damn box, you know. And it's a similar thing here, where really we just wanted to get people to agree on like, this is what a machine learning model is. This is how a prediction works. This is what the inputs are, this is what the outputs are. So cog is really just a Docker container that attaches to a CUDA device, if it needs a GPU, that has a open API specification as a label on the Docker image. And the open API specification defines the interface for the machine learning model, like the inputs and outputs effectively, or the params in machine learning terminology. And you know, we just wanted to get people to kind of agree on this thing. And it's like general purpose enough, like we weren't saying like, some of the existing things were like at the graph level, but we really wanted something general purpose enough that you could just put anything inside this and it was like future compatible and it was just like arbitrary software. And you know, it'd be future compatible with like future inference servers and future machine learning model formats and all this kind of stuff. So that was the intent behind it. It just came naturally that we wanted to define this format. And that's been really working for us. Like a bunch of people have been using cog outside of replicates, which is kind of our original intention, like this should be how machine learning is packaged and how people should use it. Like it's common to use cog in situations where like maybe they can't use the SAS service because I don't know, they're in a big company and they're not allowed to use a SAS service, but they can use cog internally still. And like they can download the models from replicates and run them internally in their org, which we've been seeing happen. And that works really well. People who want to build like custom inference pipelines, but don't want to like reinvent the world, they can use cog off the shelf and use it as like a component in their inference pipelines. We've been seeing tons of usage like that and it's just been kind of happening organically. We haven't really been trying, you know, but it's like there if people want it and we've been seeing people use it. So that's great. Yeah. So a lot of it is just sort of philosophical of just like, this is how it should work from my experience at Docker, you know, and there's just a lot of value from like the core being open, I think, and that other people can share it and it's like an integration point. So, you know, if replicate, for example, wanted to work with a testing system, like a CI system or whatever, we can just like interface at the cog level, like that system just needs to put cog models and then you can like test your models on that CI system before they get deployed to replicate. And it's just like a format that everyone, we can get everyone to agree on, you know.Alessio [00:41:55]: What do you think, I guess, Docker got wrong? Because if I look at a Docker Compose and a cog definition, first of all, the cog is kind of like the Dockerfile plus the Compose versus in Docker Compose, you're just exposing the services. And also Docker Compose is very like ports driven versus you have like the actual, you know, predict this is what you have to run.Ben [00:42:16]: Yeah.Alessio [00:42:17]: Any learnings and maybe tips for other people building container based runtimes, like how much should you separate the API services versus the image building or how much you want to build them together?Ben [00:42:29]: I think it was coming from two sides. We were thinking about the design from the point of view of user needs, what are their problems and what problems can we solve for them, but also what the interface should be for a machine learning model. And it was sort of the combination of two things that led us to this design. So the thing I talked about before was a little bit of like the interface around the machine learning model. So we realized that we wanted to be general purpose. We wanted to be at the like JSON, like human readable things rather than the tensor level. So it was like an open API specification that wrapped a Docker container. And that's where that design came from. And it's really just a wrapper around Docker. So we were kind of building on, standing on shoulders there, but Docker is too low level. So it's just like arbitrary software. So we wanted to be able to like have a open API specification that defined the function effectively that is the machine learning model. But also like how that function is written, how that function is run, which is all defined in code and stuff like that. So it's like a bunch of abstraction on top of Docker to make that work. And that's where that design came from. But the core problems we were solving for users was that Docker is really hard to use and productionizing machine learning models is really hard. So on the first part of that, we knew we couldn't use Dockerfiles. Like Dockerfiles are hard enough for software developers to write. I'm saying this with love as somebody who works on Docker and like works on Dockerfiles, but it's really hard to use. And you need to know a bunch about Linux, basically, because you're running a bunch of CLI commands. You need to know a bunch about Linux and best practices and like how apt works and all this kind of stuff. So we're like, OK, we can't get to that level. We need something that machine learning researchers will be able to understand, like people who are used to like Colab notebooks. And what they understand is they're like, I need this version of Python. I need these Python packages. And somebody told me to apt-get install something. You know? If there was sudo in there, I don't really know what that means. So we tried to create a format that was at that level, and that's what cog.yaml is. And we were really kind of trying to imagine like, what is that machine learning researcher going to understand, you know, and trying to build for them. Then the productionizing machine learning models thing is like, OK, how can we package up all of the complexity of like productionizing machine learning models, like picking CUDA versions, like hooking it up to GPUs, writing an inference server, defining a schema, doing batching, all of these just like really gnarly things that everyone does again and again. And just like, you know, provide that as a tool. And that's where that side of it came from. So it's like combining those user needs with, you know, the sort of world need of needing like a common standard for like what a machine learning model is. And that's how we thought about the design. I don't know whether that answers the question.Alessio [00:45:12]: Yeah. So your idea was like, hey, you really want what Docker stands for in terms of standard, but you actually don't want people to do all the work that goes into Docker.Ben [00:45:22]: It needs to be higher level, you know?Swyx [00:45:25]: So I want to, for the listener, you're not the only standard that is out there. As with any standard, there must be 14 of them. You are surprisingly friendly with Olama, who is your former colleagues from Docker, who came out with the model file. Mozilla came out with the Lama file. And then I don't know if this is in the same category even, but I'm just going to throw it in there. Like Hugging Face has the transformers and diffusers library, which is a way of disseminating models that obviously people use. How would you compare your contrast, your approach of Cog versus all these?Ben [00:45:53]: It's kind of complementary, actually, which is kind of neat in that a lot of transformers, for example, is lower level than Cog. So it's a Python library effectively, but you still need to like...Swyx [00:46:04]: Expose them.Ben [00:46:05]: Yeah. You still need to turn that into an inference server. You still need to like install the Python packages and that kind of thing. So lots of replicate models are transformers models and diffusers models inside Cog, you know? So that's like the level that that sits. So it's very complementary in some sense. We're kind of working on integration with Hugging Face such that you can deploy models from Hugging Face into Cog models and stuff like that to replicate. And some of these things like Llamafile and what Llama are working on are also very complementary in that they're doing a lot of the sort of running these things locally on laptops, which is not a thing that works very well with Cog. Like Cog is really designed around servers and attaching to CUDA devices and NVIDIA GPUs and this kind of thing. So we're actually like, you know, figuring out ways that like we can, those things can be interoperable because, you know, they should be and they are quite complementary and that you should be able to like take a model and replicate and run it on your local machine. You should be able to take a model, you know, the machine and run it in the cloud.Swyx [00:47:02]: Is the base layer something like, is it at the like the GGUF level, which by the way, I need to get a primer on like the different formats that have emerged, or is it at the star dot file level, which is model file, Llamafile, whatever, whatever, or is it at the Cog level? I don't know, to be honest.Ben [00:47:16]: And I think this is something we still have to figure out. There's a lot yet, like exactly where those lines are drawn. Don't know exactly. I think this is something we're trying to figure out ourselves, but I think there's certainly a lot of promise about these systems interoperating. We just want things to work together. You know, we want to try and reduce the number of standards. So the more, the more these things can interoperate and, you know

Highlights from this week's conversation include:Peter's background and journey in data (0:26)Introduction to PLG (4:18)Starting in data at Heroku (6:05)Building the data stack at Heroku (8:13)Data stack requirements for early-stage companies (12:00)Differentiating PLG companies from open source companies (19:26)Venture capital and open source as a lever for growth (22:56)Initial data modeling and analysis (25:38)Operationalizing Data (29:16)Sales and Marketing Operationalization (31:52)Identifying Signals (34:16)Challenges in Developing Signals (37:07)Account Management for Developer Tools (42:30)Challenges in Achieving Margins (45:02)Leveraging Infrastructure for Margins (47:35)Inference vs Training (54:55)Final thoughts and takeaways (57:02)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we'll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

We're writing this one day after the monster release of OpenAI's Sora and Gemini 1.5. We covered this on ‘s ThursdAI space, so head over there for our takes.IRL: We're ONE WEEK away from Latent Space: Final Frontiers, the second edition and anniversary of our first ever Latent Space event! Also: join us on June 25-27 for the biggest AI Engineer conference of the year!Online: All three Discord clubs are thriving. Join us every Wednesday/Friday!Almost 12 years ago, while working at Spotify, Erik Bernhardsson built one of the first open source vector databases, Annoy, based on ANN search. He also built Luigi, one of the predecessors to Airflow, which helps data teams orchestrate and execute data-intensive and long-running jobs. Surprisingly, he didn't start yet another vector database company, but instead in 2021 founded Modal, the “high-performance cloud for developers”. In 2022 they opened doors to developers after their seed round, and in 2023 announced their GA with a $16m Series A.More importantly, they have won fans among both household names like Ramp, Scale AI, Substack, and Cohere, and newer startups like (upcoming guest!) Suno.ai and individual hackers (Modal was the top tool of choice in the Vercel AI Accelerator):We've covered the nuances of GPU workloads, and how we need new developer tooling and runtimes for them (see our episodes with Chris Lattner of Modular and George Hotz of tiny to start). In this episode, we run through the major limitations of the actual infrastructure behind the clouds that run these models, and how Erik envisions the “postmodern data stack”. In his 2021 blog post “Software infrastructure 2.0: a wishlist”, Erik had “Truly serverless” as one of his points:* The word cluster is an anachronism to an end-user in the cloud! I'm already running things in the cloud where there's elastic resources available at any time. Why do I have to think about the underlying pool of resources? Just maintain it for me.* I don't ever want to provision anything in advance of load.* I don't want to pay for idle resources. Just let me pay for whatever resources I'm actually using.* Serverless doesn't mean it's a burstable VM that saves its instance state to disk during periods of idle.Swyx called this Self Provisioning Runtimes back in the day. Modal doesn't put you in YAML hell, preferring to colocate infra provisioning right next to the code that utilizes it, so you can just add GPU (and disk, and retries…):After 3 years, we finally have a big market push for this: running inference on generative models is going to be the killer app for serverless, for a few reasons:* AI models are stateless: even in conversational interfaces, each message generation is a fully-contained request to the LLM. There's no knowledge that is stored in the model itself between messages, which means that tear down / spin up of resources doesn't create any headaches with maintaining state.* Token-based pricing is better aligned with serverless infrastructure than fixed monthly costs of traditional software.* GPU scarcity makes it really expensive to have reserved instances that are available to you 24/7. It's much more convenient to build with a serverless-like infrastructure.In the episode we covered a lot more topics like maximizing GPU utilization, why Oracle Cloud rocks, and how Erik has never owned a TV in his life. Enjoy!Show Notes* Modal* ErikBot* Erik's Blog* Software Infra 2.0 Wishlist* Luigi* Annoy* Hetzner* CoreWeave* Cloudflare FaaS* Poolside AI* Modular Inference EngineChapters* [00:00:00] Introductions* [00:02:00] Erik's OSS work at Spotify: Annoy and Luigi* [00:06:22] Starting Modal* [00:07:54] Vision for a "postmodern data stack"* [00:10:43] Solving container cold start problems* [00:12:57] Designing Modal's Python SDK* [00:15:18] Self-Revisioning Runtime* [00:19:14] Truly Serverless Infrastructure* [00:20:52] Beyond model inference* [00:22:09] Tricks to maximize GPU utilization* [00:26:27] Differences in AI and data science workloads* [00:28:08] Modal vs Replicate vs Modular and lessons from Heroku's "graduation problem"* [00:34:12] Creating Erik's clone "ErikBot"* [00:37:43] Enabling massive parallelism across thousands of GPUs* [00:39:45] The Modal Sandbox for agents* [00:43:51] Thoughts on the AI Inference War* [00:49:18] Erik's best tweets* [00:51:57] Why buying hardware is a waste of money* [00:54:18] Erik's competitive programming backgrounds* [00:59:02] Why does Sweden have the best Counter Strike players?* [00:59:53] Never owning a car or TV* [01:00:21] Advice for infrastructure startupsTranscriptAlessio [00:00:00]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO-in-Residence at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:14]: Hey, and today we have in the studio Erik Bernhardsson from Modal. Welcome.Erik [00:00:19]: Hi. It's awesome being here.Swyx [00:00:20]: Yeah. Awesome seeing you in person. I've seen you online for a number of years as you were building on Modal and I think you're just making a San Francisco trip just to see people here, right? I've been to like two Modal events in San Francisco here.Erik [00:00:34]: Yeah, that's right. We're based in New York, so I figured sometimes I have to come out to capital of AI and make a presence.Swyx [00:00:40]: What do you think is the pros and cons of building in New York?Erik [00:00:45]: I mean, I never built anything elsewhere. I lived in New York the last 12 years. I love the city. Obviously, there's a lot more stuff going on here and there's a lot more customers and that's why I'm out here. I do feel like for me, where I am in life, I'm a very boring person. I kind of work hard and then I go home and hang out with my kids. I don't have time to go to events and meetups and stuff anyway. In that sense, New York is kind of nice. I walk to work every morning. It's like five minutes away from my apartment. It's very time efficient in that sense. Yeah.Swyx [00:01:10]: Yeah. It's also a good life. So we'll do a brief bio and then we'll talk about anything else that people should know about you. Actually, I was surprised to find out you're from Sweden. You went to college in KTH and your master's was in implementing a scalable music recommender system. Yeah.Erik [00:01:27]: I had no idea. Yeah. So I actually studied physics, but I grew up coding and I did a lot of programming competition and then as I was thinking about graduating, I got in touch with an obscure music streaming startup called Spotify, which was then like 30 people. And for some reason, I convinced them, why don't I just come and write a master's thesis with you and I'll do some cool collaborative filtering, despite not knowing anything about collaborative filtering really. But no one knew anything back then. So I spent six months at Spotify basically building a prototype of a music recommendation system and then turned that into a master's thesis. And then later when I graduated, I joined Spotify full time.Swyx [00:02:00]: So that was the start of your data career. You also wrote a couple of popular open source tooling while you were there. Is that correct?Erik [00:02:09]: No, that's right. I mean, I was at Spotify for seven years, so this is a long stint. And Spotify was a wild place early on and I mean, data space is also a wild place. I mean, it was like Hadoop cluster in the like foosball room on the floor. It was a lot of crude, like very basic infrastructure and I didn't know anything about it. And like I was hired to kind of figure out data stuff. And I started hacking on a recommendation system and then, you know, got sidetracked in a bunch of other stuff. I fixed a bunch of reporting things and set up A-B testing and started doing like business analytics and later got back to music recommendation system. And a lot of the infrastructure didn't really exist. Like there was like Hadoop back then, which is kind of bad and I don't miss it. But I spent a lot of time with that. As a part of that, I ended up building a workflow engine called Luigi, which is like briefly like somewhat like widely ended up being used by a bunch of companies. Sort of like, you know, kind of like Airflow, but like before Airflow. I think it did some things better, some things worse. I also built a vector database called Annoy, which is like for a while, it was actually quite widely used. In 2012, so it was like way before like all this like vector database stuff ended up happening. And funny enough, I was actually obsessed with like vectors back then. Like I was like, this is going to be huge. Like just give it like a few years. I didn't know it was going to take like nine years and then there's going to suddenly be like 20 startups doing vector databases in one year. So it did happen. In that sense, I was right. I'm glad I didn't start a startup in the vector database space. I would have started way too early. But yeah, that was, yeah, it was a fun seven years as part of it. It was a great culture, a great company.Swyx [00:03:32]: Yeah. Just to take a quick tangent on this vector database thing, because we probably won't revisit it but like, has anything architecturally changed in the last nine years?Erik [00:03:41]: I'm actually not following it like super closely. I think, you know, some of the best algorithms are still the same as like hierarchical navigable small world.Swyx [00:03:51]: Yeah. HNSW.Erik [00:03:52]: Exactly. I think now there's like product quantization, there's like some other stuff that I haven't really followed super closely. I mean, obviously, like back then it was like, you know, it's always like very simple. It's like a C++ library with Python bindings and you could mmap big files and into memory and like they had some lookups. I used like this kind of recursive, like hyperspace splitting strategy, which is not that good, but it sort of was good enough at that time. But I think a lot of like HNSW is still like what people generally use. Now of course, like databases are much better in the sense like to support like inserts and updates and stuff like that. I know I never supported that. Yeah, it's sort of exciting to finally see like vector databases becoming a thing.Swyx [00:04:30]: Yeah. Yeah. And then maybe one takeaway on most interesting lesson from Daniel Ek?Erik [00:04:36]: I mean, I think Daniel Ek, you know, he started Spotify very young. Like he was like 25, something like that. And that was like a good lesson. But like he, in a way, like I think he was a very good leader. Like there was never anything like, no scandals or like no, he wasn't very eccentric at all. It was just kind of like very like level headed, like just like ran the company very well, like never made any like obvious mistakes or I think it was like a few bets that maybe like in hindsight were like a little, you know, like took us, you know, too far in one direction or another. But overall, I mean, I think he was a great CEO, like definitely, you know, up there, like generational CEO, at least for like Swedish startups.Swyx [00:05:09]: Yeah, yeah, for sure. Okay, we should probably move to make our way towards Modal. So then you spent six years as CTO of Better. You were an early engineer and then you scaled up to like 300 engineers.Erik [00:05:21]: I joined as a CTO when there was like no tech team. And yeah, that was a wild chapter in my life. Like the company did very well for a while. And then like during the pandemic, yeah, it was kind of a weird story, but yeah, it kind of collapsed.Swyx [00:05:32]: Yeah, laid off people poorly.Erik [00:05:34]: Yeah, yeah. It was like a bunch of stories. Yeah. I mean, the company like grew from like 10 people when I joined at 10,000, now it's back to a thousand. But yeah, they actually went public a few months ago, kind of crazy. They're still around, like, you know, they're still, you know, doing stuff. So yeah, very kind of interesting six years of my life for non-technical reasons, like I managed like three, four hundred, but yeah, like learning a lot of that, like recruiting. I spent all my time recruiting and stuff like that. And so managing at scale, it's like nice, like now in a way, like when I'm building my own startup. It's actually something I like, don't feel nervous about at all. Like I've managed a scale, like I feel like I can do it again. It's like very different things that I'm nervous about as a startup founder. But yeah, I started Modal three years ago after sort of, after leaving Better, I took a little bit of time off during the pandemic and, but yeah, pretty quickly I was like, I got to build something. I just want to, you know. Yeah. And then yeah, Modal took form in my head, took shape.Swyx [00:06:22]: And as far as I understand, and maybe we can sort of trade off questions. So the quick history is started Modal in 2021, got your seed with Sarah from Amplify in 2022. You just announced your Series A with Redpoint. That's right. And that brings us up to mostly today. Yeah. Most people, I think, were expecting you to build for the data space.Erik: But it is the data space.Swyx:: When I think of data space, I come from like, you know, Snowflake, BigQuery, you know, Fivetran, Nearby, that kind of stuff. And what Modal became is more general purpose than that. Yeah.Erik [00:06:53]: Yeah. I don't know. It was like fun. I actually ran into like Edo Liberty, the CEO of Pinecone, like a few weeks ago. And he was like, I was so afraid you were building a vector database. No, I started Modal because, you know, like in a way, like I work with data, like throughout my most of my career, like every different part of the stack, right? Like I thought everything like business analytics to like deep learning, you know, like building, you know, training neural networks, the scale, like everything in between. And so one of the thoughts, like, and one of the observations I had when I started Modal or like why I started was like, I just wanted to make, build better tools for data teams. And like very, like sort of abstract thing, but like, I find that the data stack is, you know, full of like point solutions that don't integrate well. And still, when you look at like data teams today, you know, like every startup ends up building their own internal Kubernetes wrapper or whatever. And you know, all the different data engineers and machine learning engineers end up kind of struggling with the same things. So I started thinking about like, how do I build a new data stack, which is kind of a megalomaniac project, like, because you kind of want to like throw out everything and start over.Swyx [00:07:54]: It's almost a modern data stack.Erik [00:07:55]: Yeah, like a postmodern data stack. And so I started thinking about that. And a lot of it came from like, like more focused on like the human side of like, how do I make data teams more productive? And like, what is the technology tools that they need? And like, you know, drew out a lot of charts of like, how the data stack looks, you know, what are different components. And it shows actually very interesting, like workflow scheduling, because it kind of sits in like a nice sort of, you know, it's like a hub in the graph of like data products. But it was kind of hard to like, kind of do that in a vacuum, and also to monetize it to some extent. I got very interested in like the layers below at some point. And like, at the end of the day, like most people have code to have to run somewhere. So I think about like, okay, well, how do you make that nice? Like how do you make that? And in particular, like the thing I always like thought about, like developer productivity is like, I think the best way to measure developer productivity is like in terms of the feedback loops, like how quickly when you iterate, like when you write code, like how quickly can you get feedback. And at the innermost loop, it's like writing code and then running it. And like, as soon as you start working with the cloud, like it's like takes minutes suddenly, because you have to build a Docker container and push it to the cloud and like run it, you know. So that was like the initial focus for me was like, I just want to solve that problem. Like I want to, you know, build something less, you run things in the cloud and like retain the sort of, you know, the joy of productivity as when you're running things locally. And in particular, I was quite focused on data teams, because I think they had a couple unique needs that wasn't well served by the infrastructure at that time, or like still is in like, in particular, like Kubernetes, I feel like it's like kind of worked okay for back end teams, but not so well for data teams. And very quickly, I got sucked into like a very deep like rabbit hole of like...Swyx [00:09:24]: Not well for data teams because of burstiness. Yeah, for sure.Erik [00:09:26]: So like burstiness is like one thing, right? Like, you know, like you often have this like fan out, you want to like apply some function over very large data sets. Another thing tends to be like hardware requirements, like you need like GPUs and like, I've seen this in many companies, like you go, you know, data scientists go to a platform team and they're like, can we add GPUs to the Kubernetes? And they're like, no, like, that's, you know, complex, and we're not gonna, so like just getting GPU access. And then like, I mean, I also like data code, like frankly, or like machine learning code like tends to be like, super annoying in terms of like environments, like you end up having like a lot of like custom, like containers and like environment conflicts. And like, it's very hard to set up like a unified container that like can serve like a data scientist, because like, there's always like packages that break. And so I think there's a lot of different reasons why the technology wasn't well suited for back end. And I think the attitude at that time is often like, you know, like you had friction between the data team and the platform team, like, well, it works for the back end stuff, you know, why don't you just like, you know, make it work. But like, I actually felt like data teams, you know, or at this point now, like there's so much, so many people working with data, and like they, to some extent, like deserve their own tools and their own tool chains, and like optimizing for that is not something people have done. So that's, that's sort of like very abstract philosophical reason why I started Model. And then, and then I got sucked into this like rabbit hole of like container cold start and, you know, like whatever, Linux, page cache, you know, file system optimizations.Swyx [00:10:43]: Yeah, tell people, I think the first time I met you, I think you told me some numbers, but I don't remember, like, what are the main achievements that you were unhappy with the status quo? And then you built your own container stack?Erik [00:10:52]: Yeah, I mean, like, in particular, it was like, in order to have that loop, right? You want to be able to start, like take code on your laptop, whatever, and like run in the cloud very quickly, and like running in custom containers, and maybe like spin up like 100 containers, 1000, you know, things like that. And so container cold start was the initial like, from like a developer productivity point of view, it was like, really, what I was focusing on is, I want to take code, I want to stick it in container, I want to execute in the cloud, and like, you know, make it feel like fast. And when you look at like, how Docker works, for instance, like Docker, you have this like, fairly convoluted, like very resource inefficient way, they, you know, you build a container, you upload the whole container, and then you download it, and you run it. And Kubernetes is also like, not very fast at like starting containers. So like, I started kind of like, you know, going a layer deeper, like Docker is actually like, you know, there's like a couple of different primitives, but like a lower level primitive is run C, which is like a container runner. And I was like, what if I just take the container runner, like run C, and I point it to like my own root file system, and then I built like my own virtual file system that exposes files over a network instead. And that was like the sort of very crude version of model, it's like now I can actually start containers very quickly, because it turns out like when you start a Docker container, like, first of all, like most Docker images are like several gigabytes, and like 99% of that is never going to be consumed, like there's a bunch of like, you know, like timezone information for like Uzbekistan, like no one's going to read it. And then there's a very high overlap between the files are going to be read, there's going to be like lib torch or whatever, like it's going to be read. So you can also cache it very well. So that was like the first sort of stuff we started working on was like, let's build this like container file system. And you know, coupled with like, you know, just using run C directly. And that actually enabled us to like, get to this point of like, you write code, and then you can launch it in the cloud within like a second or two, like something like that. And you know, there's been many optimizations since then, but that was sort of starting point.Alessio [00:12:33]: Can we talk about the developer experience as well, I think one of the magic things about Modal is at the very basic layers, like a Python function decorator, it's just like stub and whatnot. But then you also have a way to define a full container, what were kind of the design decisions that went into it? Where did you start? How easy did you want it to be? And then maybe how much complexity did you then add on to make sure that every use case fit?Erik [00:12:57]: I mean, Modal, I almost feel like it's like almost like two products kind of glued together. Like there's like the low level like container runtime, like file system, all that stuff like in Rust. And then there's like the Python SDK, right? Like how do you express applications? And I think, I mean, Swix, like I think your blog was like the self-provisioning runtime was like, to me, always like to sort of, for me, like an eye-opening thing. It's like, so I didn't think about like...Swyx [00:13:15]: You wrote your post four months before me. Yeah? The software 2.0, Infra 2.0. Yeah.Erik [00:13:19]: Well, I don't know, like convergence of minds. I guess we were like both thinking. Maybe you put, I think, better words than like, you know, maybe something I was like thinking about for a long time. Yeah.Swyx [00:13:29]: And I can tell you how I was thinking about it on my end, but I want to hear you say it.Erik [00:13:32]: Yeah, yeah, I would love to. So to me, like what I always wanted to build was like, I don't know, like, I don't know if you use like Pulumi. Like Pulumi is like nice, like in the sense, like it's like Pulumi is like you describe infrastructure in code, right? And to me, that was like so nice. Like finally I can like, you know, put a for loop that creates S3 buckets or whatever. And I think like Modal sort of goes one step further in the sense that like, what if you also put the app code inside the infrastructure code and like glue it all together and then like you only have one single place that defines everything and it's all programmable. You don't have any config files. Like Modal has like zero config. There's no config. It's all code. And so that was like the goal that I wanted, like part of that. And then the other part was like, I often find that so much of like my time was spent on like the plumbing between containers. And so my thing was like, well, if I just build this like Python SDK and make it possible to like bridge like different containers, just like a function call, like, and I can say, oh, this function runs in this container and this other function runs in this container and I can just call it just like a normal function, then, you know, I can build these applications that may span a lot of different environments. Maybe they fan out, start other containers, but it's all just like inside Python. You just like have this beautiful kind of nice like DSL almost for like, you know, how to control infrastructure in the cloud. So that was sort of like how we ended up with the Python SDK as it is, which is still evolving all the time, by the way. We keep changing syntax quite a lot because I think it's still somewhat exploratory, but we're starting to converge on something that feels like reasonably good now.Swyx [00:14:54]: Yeah. And along the way you, with this expressiveness, you enabled the ability to, for example, attach a GPU to a function. Totally.Erik [00:15:02]: Yeah. It's like you just like say, you know, on the function decorator, you're like GPU equals, you know, A100 and then or like GPU equals, you know, A10 or T4 or something like that. And then you get that GPU and like, you know, you just run the code and it runs like you don't have to, you know, go through hoops to, you know, start an EC2 instance or whatever.Swyx [00:15:18]: Yeah. So it's all code. Yeah. So one of the reasons I wrote Self-Revisioning Runtimes was I was working at AWS and we had AWS CDK, which is kind of like, you know, the Amazon basics blew me. Yeah, totally. And then, and then like it creates, it compiles the cloud formation. Yeah. And then on the other side, you have to like get all the config stuff and then put it into your application code and make sure that they line up. So then you're writing code to define your infrastructure, then you're writing code to define your application. And I was just like, this is like obvious that it's going to converge, right? Yeah, totally.Erik [00:15:48]: But isn't there like, it might be wrong, but like, was it like SAM or Chalice or one of those? Like, isn't that like an AWS thing that where actually they kind of did that? I feel like there's like one.Swyx [00:15:57]: SAM. Yeah. Still very clunky. It's not, not as elegant as modal.Erik [00:16:03]: I love AWS for like the stuff it's built, you know, like historically in order for me to like, you know, what it enables me to build, but like AWS is always like struggle with developer experience.Swyx [00:16:11]: I mean, they have to not break things.Erik [00:16:15]: Yeah. Yeah. And totally. And they have to build products for a very wide range of use cases. And I think that's hard.Swyx [00:16:21]: Yeah. Yeah. So it's, it's easier to design for. Yeah. So anyway, I was, I was pretty convinced that this, this would happen. I wrote, wrote that thing. And then, you know, I imagine my surprise that you guys had it on your landing page at some point. I think, I think Akshad was just like, just throw that in there.Erik [00:16:34]: Did you trademark it?Swyx [00:16:35]: No, I didn't. But I definitely got sent a few pitch decks with my post on there and it was like really interesting. This is my first time like kind of putting a name to a phenomenon. And I think this is a useful skill for people to just communicate what they're trying to do.Erik [00:16:48]: Yeah. No, I think it's a beautiful concept.Swyx [00:16:50]: Yeah. Yeah. Yeah. But I mean, obviously you implemented it. What became more clear in your explanation today is that actually you're not that tied to Python.Erik [00:16:57]: No. I mean, I, I think that all the like lower level stuff is, you know, just running containers and like scheduling things and, you know, serving container data and stuff. So like one of the benefits of data teams is obviously like they're all like using Python, right? And so that made it a lot easier. I think, you know, if we had focused on other workloads, like, you know, for various reasons, we've like been kind of like half thinking about like CI or like things like that. But like, in a way that's like harder because like you also, then you have to be like, you know, multiple SDKs, whereas, you know, focusing on data teams, you can only, you know, Python like covers like 95% of all teams. That made it a lot easier. But like, I mean, like definitely like in the future, we're going to have others support, like supporting other languages. JavaScript for sure is the obvious next language. But you know, who knows, like, you know, Rust, Go, R, whatever, PHP, Haskell, I don't know.Swyx [00:17:42]: You know, I think for me, I actually am a person who like kind of liked the idea of programming language advancements being improvements in developer experience. But all I saw out of the academic sort of PLT type people is just type level improvements. And I always think like, for me, like one of the core reasons for self-provisioning runtimes and then why I like Modal is like, this is actually a productivity increase, right? Like, it's a language level thing, you know, you managed to stick it on top of an existing language, but it is your own language, a DSL on top of Python. And so language level increase on the order of like automatic memory management. You know, you could sort of make that analogy that like, maybe you lose some level of control, but most of the time you're okay with whatever Modal gives you. And like, that's fine. Yeah.Erik [00:18:26]: Yeah. Yeah. I mean, that's how I look at about it too. Like, you know, you look at developer productivity over the last number of decades, like, you know, it's come in like small increments of like, you know, dynamic typing or like is like one thing because not suddenly like for a lot of use cases, you don't need to care about type systems or better compiler technology or like, you know, the cloud or like, you know, relational databases. And, you know, I think, you know, you look at like that, you know, history, it's a steadily, you know, it's like, you know, you look at the developers have been getting like probably 10X more productive every decade for the last four decades or something that was kind of crazy. Like on an exponential scale, we're talking about 10X or is there a 10,000X like, you know, improvement in developer productivity. What we can build today, you know, is arguably like, you know, a fraction of the cost of what it took to build it in the eighties. Maybe it wasn't even possible in the eighties. So that to me, like, that's like so fascinating. I think it's going to keep going for the next few decades. Yeah.Alessio [00:19:14]: Yeah. Another big thing in the infra 2.0 wishlist was truly serverless infrastructure. The other on your landing page, you called them native cloud functions, something like that. I think the issue I've seen with serverless has always been people really wanted it to be stateful, even though stateless was much easier to do. And I think now with AI, most model inference is like stateless, you know, outside of the context. So that's kind of made it a lot easier to just put a model, like an AI model on model to run. How do you think about how that changes how people think about infrastructure too? Yeah.Erik [00:19:48]: I mean, I think model is definitely going in the direction of like doing more stateful things and working with data and like high IO use cases. I do think one like massive serendipitous thing that happened like halfway, you know, a year and a half into like the, you know, building model was like Gen AI started exploding and the IO pattern of Gen AI is like fits the serverless model like so well, because it's like, you know, you send this tiny piece of information, like a prompt, right, or something like that. And then like you have this GPU that does like trillions of flops, and then it sends back like a tiny piece of information, right. And that turns out to be something like, you know, if you can get serverless working with GPU, that just like works really well, right. So I think from that point of view, like serverless always to me felt like a little bit of like a solution looking for a problem. I don't actually like don't think like backend is like the problem that needs to serve it or like not as much. But I look at data and in particular, like things like Gen AI, like model inference, like it's like clearly a good fit. So I think that is, you know, to a large extent explains like why we saw, you know, the initial sort of like killer app for model being model inference, which actually wasn't like necessarily what we're focused on. But that's where we've seen like by far the most usage. Yeah.Swyx [00:20:52]: And this was before you started offering like fine tuning of language models, it was mostly stable diffusion. Yeah.Erik [00:20:59]: Yeah. I mean, like model, like I always built it to be a very general purpose compute platform, like something where you can run everything. And I used to call model like a better Kubernetes for data team for a long time. What we realized was like, yeah, that's like, you know, a year and a half in, like we barely had any users or any revenue. And like we were like, well, maybe we should look at like some use case, trying to think of use case. And that was around the same time stable diffusion came out. And the beauty of model is like you can run almost anything on model, right? Like model inference turned out to be like the place where we found initially, well, like clearly this has like 10x like better agronomics than anything else. But we're also like, you know, going back to my original vision, like we're thinking a lot about, you know, now, okay, now we do inference really well. Like what about training? What about fine tuning? What about, you know, end-to-end lifecycle deployment? What about data pre-processing? What about, you know, I don't know, real-time streaming? What about, you know, large data munging, like there's just data observability. I think there's so many things, like kind of going back to what I said about like redefining the data stack, like starting with the foundation of compute. Like one of the exciting things about model is like we've sort of, you know, we've been working on that for three years and it's maturing, but like this is so many things you can do like with just like a better compute primitive and also go up to stack and like do all this other stuff on top of it.Alessio [00:22:09]: How do you think about or rather like I would love to learn more about the underlying infrastructure and like how you make that happen because with fine tuning and training, it's a static memory. Like you exactly know what you're going to load in memory one and it's kind of like a set amount of compute versus inference, just like data is like very bursty. How do you make batches work with a serverless developer experience? You know, like what are like some fun technical challenge you solve to make sure you get max utilization on these GPUs? What we hear from people is like, we have GPUs, but we can really only get like, you know, 30, 40, 50% maybe utilization. What's some of the fun stuff you're working on to get a higher number there?Erik [00:22:48]: Yeah, I think on the inference side, like that's where we like, you know, like from a cost perspective, like utilization perspective, we've seen, you know, like very good numbers and in particular, like it's our ability to start containers and stop containers very quickly. And that means that we can auto scale extremely fast and scale down very quickly, which means like we can always adjust the sort of capacity, the number of GPUs running to the exact traffic volume. And so in many cases, like that actually leads to a sort of interesting thing where like we obviously run our things on like the public cloud, like AWS GCP, we run on Oracle, but in many cases, like users who do inference on those platforms or those clouds, even though we charge a slightly higher price per GPU hour, a lot of users like moving their large scale inference use cases to model, they end up saving a lot of money because we only charge for like with the time the GPU is actually running. And that's a hard problem, right? Like, you know, if you have to constantly adjust the number of machines, if you have to start containers, stop containers, like that's a very hard problem. Starting containers quickly is a very difficult thing. I mentioned we had to build our own file system for this. We also, you know, built our own container scheduler for that. We've implemented recently CPU memory checkpointing so we can take running containers and snapshot the entire CPU, like including registers and everything, and restore it from that point, which means we can restore it from an initialized state. We're looking at GPU checkpointing next, it's like a very interesting thing. So I think with inference stuff, that's where serverless really shines because you can drive, you know, you can push the frontier of latency versus utilization quite substantially, you know, which either ends up being a latency advantage or a cost advantage or both, right? On training, it's probably arguably like less of an advantage doing serverless, frankly, because you know, you can just like spin up a bunch of machines and try to satisfy, like, you know, train as much as you can on each machine. For that area, like we've seen, like, you know, arguably like less usage, like for modal, but there are always like some interesting use case. Like we do have a couple of customers, like RAM, for instance, like they do fine tuning with modal and they basically like one of the patterns they have is like very bursty type fine tuning where they fine tune 100 models in parallel. And that's like a separate thing that modal does really well, right? Like you can, we can start up 100 containers very quickly, run a fine tuning training job on each one of them for that only runs for, I don't know, 10, 20 minutes. And then, you know, you can do hyper parameter tuning in that sense, like just pick the best model and things like that. So there are like interesting training. I think when you get to like training, like very large foundational models, that's a use case we don't support super well, because that's very high IO, you know, you need to have like infinite band and all these things. And those are things we haven't supported yet and might take a while to get to that. So that's like probably like an area where like we're relatively weak in. Yeah.Alessio [00:25:12]: Have you cared at all about lower level model optimization? There's other cloud providers that do custom kernels to get better performance or are you just given that you're not just an AI compute company? Yeah.Erik [00:25:24]: I mean, I think like we want to support like a generic, like general workloads in a sense that like we want users to give us a container essentially or a code or code. And then we want to run that. So I think, you know, we benefit from those things in the sense that like we can tell our users, you know, to use those things. But I don't know if we want to like poke into users containers and like do those things automatically. That's sort of, I think a little bit tricky from the outside to do, because we want to be able to take like arbitrary code and execute it. But certainly like, you know, we can tell our users to like use those things. Yeah.Swyx [00:25:53]: I may have betrayed my own biases because I don't really think about modal as for data teams anymore. I think you started, I think you're much more for AI engineers. My favorite anecdotes, which I think, you know, but I don't know if you directly experienced it. I went to the Vercel AI Accelerator, which you supported. And in the Vercel AI Accelerator, a bunch of startups gave like free credits and like signups and talks and all that stuff. The only ones that stuck are the ones that actually appealed to engineers. And the top usage, the top tool used by far was modal.Erik [00:26:24]: That's awesome.Swyx [00:26:25]: For people building with AI apps. Yeah.Erik [00:26:27]: I mean, it might be also like a terminology question, like the AI versus data, right? Like I've, you know, maybe I'm just like old and jaded, but like, I've seen so many like different titles, like for a while it was like, you know, I was a data scientist and a machine learning engineer and then, you know, there was like analytics engineers and there was like an AI engineer, you know? So like, to me, it's like, I just like in my head, that's to me just like, just data, like, or like engineer, you know, like I don't really, so that's why I've been like, you know, just calling it data teams. But like, of course, like, you know, AI is like, you know, like such a massive fraction of our like workloads.Swyx [00:26:59]: It's a different Venn diagram of things you do, right? So the stuff that you're talking about where you need like infinite bands for like highly parallel training, that's not, that's more of the ML engineer, that's more of the research scientist and less of the AI engineer, which is more sort of trying to put, work at the application.Erik [00:27:16]: Yeah. I mean, to be fair to it, like we have a lot of users that are like doing stuff that I don't think fits neatly into like AI. Like we have a lot of people using like modal for web scraping, like it's kind of nice. You can just like, you know, fire up like a hundred or a thousand containers running Chromium and just like render a bunch of webpages and it takes, you know, whatever. Or like, you know, protein folding is that, I mean, maybe that's, I don't know, like, but like, you know, we have a bunch of users doing that or, or like, you know, in terms of, in the realm of biotech, like sequence alignment, like people using, or like a couple of people using like modal to run like large, like mixed integer programming problems, like, you know, using Gurobi or like things like that. So video processing is another thing that keeps coming up, like, you know, let's say you have like petabytes of video and you want to just like transcode it, like, or you can fire up a lot of containers and just run FFmpeg or like, so there are those things too. Like, I mean, like that being said, like AI is by far our biggest use case, but you know, like, again, like modal is kind of general purpose in that sense.Swyx [00:28:08]: Yeah. Well, maybe I'll stick to the stable diffusion thing and then we'll move on to the other use cases for AI that you want to highlight. The other big player in my mind is replicate. Yeah. In this, in this era, they're much more, I guess, custom built for that purpose, whereas you're more general purpose. How do you position yourself with them? Are they just for like different audiences or are you just heads on competing?Erik [00:28:29]: I think there's like a tiny sliver of the Venn diagram where we're competitive. And then like 99% of the area we're not competitive. I mean, I think for people who, if you look at like front-end engineers, I think that's where like really they found good fit is like, you know, people who built some cool web app and they want some sort of AI capability and they just, you know, an off the shelf model is like perfect for them. That's like, I like use replicate. That's great. I think where we shine is like custom models or custom workflows, you know, running things at very large scale. We need to care about utilization, care about costs. You know, we have much lower prices because we spend a lot more time optimizing our infrastructure, you know, and that's where we're competitive, right? Like, you know, and you look at some of the use cases, like Suno is a big user, like they're running like large scale, like AI. Oh, we're talking with Mikey.Swyx [00:29:12]: Oh, that's great. Cool.Erik [00:29:14]: In a month. Yeah. So, I mean, they're, they're using model for like production infrastructure. Like they have their own like custom model, like custom code and custom weights, you know, for AI generated music, Suno.AI, you know, that, that, those are the types of use cases that we like, you know, things that are like very custom or like, it's like, you know, and those are the things like it's very hard to run and replicate, right? And that's fine. Like I think they, they focus on a very different part of the stack in that sense.Swyx [00:29:35]: And then the other company pattern that I pattern match you to is Modular. I don't know.Erik [00:29:40]: Because of the names?Swyx [00:29:41]: No, no. Wow. No, but yeah, yes, the name is very similar. I think there's something that might be insightful there from a linguistics point of view. Oh no, they have Mojo, the sort of Python SDK. And they have the Modular Inference Engine, which is their sort of their cloud stack, their sort of compute inference stack. I don't know if anyone's made that comparison to you before, but like I see you evolving a little bit in parallel there.Erik [00:30:01]: No, I mean, maybe. Yeah. Like it's not a company I'm like super like familiar, like, I mean, I know the basics, but like, I guess they're similar in the sense like they want to like do a lot of, you know, they have sort of big picture vision.Swyx [00:30:12]: Yes. They also want to build very general purpose. Yeah. So they're marketing themselves as like, if you want to do off the shelf stuff, go out, go somewhere else. If you want to do custom stuff, we're the best place to do it. Yeah. Yeah. There is some overlap there. There's not overlap in the sense that you are a closed source platform. People have to host their code on you. That's true. Whereas for them, they're very insistent on not running their own cloud service. They're a box software. Yeah. They're licensed software.Erik [00:30:37]: I'm sure their VCs at some point going to force them to reconsider. No, no.Swyx [00:30:40]: Chris is very, very insistent and very convincing. So anyway, I would just make that comparison, let people make the links if they want to. But it's an interesting way to see the cloud market develop from my point of view, because I came up in this field thinking cloud is one thing, and I think your vision is like something slightly different, and I see the different takes on it.Erik [00:31:00]: Yeah. And like one thing I've, you know, like I've written a bit about it in my blog too, it's like I think of us as like a second layer of cloud provider in the sense that like I think Snowflake is like kind of a good analogy. Like Snowflake, you know, is infrastructure as a service, right? But they actually run on the like major clouds, right? And I mean, like you can like analyze this very deeply, but like one of the things I always thought about is like, why does Snowflake arbitrarily like win over Redshift? And I think Snowflake, you know, to me, one, because like, I mean, in the end, like AWS makes all the money anyway, like and like Snowflake just had the ability to like focus on like developer experience or like, you know, user experience. And to me, like really proved that you can build a cloud provider, a layer up from, you know, the traditional like public clouds. And in that layer, that's also where I would put Modal, it's like, you know, we're building a cloud provider, like we're, you know, we're like a multi-tenant environment that runs the user code. But we're also building on top of the public cloud. So I think there's a lot of room in that space, I think is very sort of interesting direction.Alessio [00:31:55]: How do you think of that compared to the traditional past history, like, you know, you had AWS, then you had Heroku, then you had Render, Railway.Erik [00:32:04]: Yeah, I mean, I think those are all like great. I think the problem that they all faced was like the graduation problem, right? Like, you know, Heroku or like, I mean, like also like Heroku, there's like a counterfactual future of like, what would have happened if Salesforce didn't buy them, right? Like, that's a sort of separate thing. But like, I think what Heroku, I think always struggled with was like, eventually companies would get big enough that you couldn't really justify running in Heroku. So they would just go and like move it to, you know, whatever AWS or, you know, in particular. And you know, that's something that keeps me up at night too, like, what does that graduation risk like look like for modal? I always think like the only way to build a successful infrastructure company in the long run in the cloud today is you have to appeal to the entire spectrum, right? Or at least like the enterprise, like you have to capture the enterprise market. But the truly good companies capture the whole spectrum, right? Like I think of companies like, I don't like Datadog or Mongo or something that were like, they both captured like the hobbyists and acquire them, but also like, you know, have very large enterprise customers. I think that arguably was like where I, in my opinion, like Heroku struggle was like, how do you maintain the customers as they get more and more advanced? I don't know what the solution is, but I think there's, you know, that's something I would have thought deeply if I was at Heroku at that time.Alessio [00:33:14]: What's the AI graduation problem? Is it, I need to fine tune the model, I need better economics, any insights from customer discussions?Erik [00:33:22]: Yeah, I mean, better economics, certainly. But although like, I would say like, even for people who like, you know, needs like thousands of GPUs, just because we can drive utilization so much better, like we, there's actually like a cost advantage of staying on modal. But yeah, I mean, certainly like, you know, and like the fact that VCs like love, you know, throwing money at least used to, you know, add companies who need it to buy GPUs. I think that didn't help the problem. And in training, I think, you know, there's less software differentiation. So in training, I think there's certainly like better economics of like buying big clusters. But I mean, my hope it's going to change, right? Like I think, you know, we're still pretty early in the cycle of like building AI infrastructure. And I think a lot of these companies over in the long run, like, you know, they're, except it may be super big ones, like, you know, on Facebook and Google, they're always going to build their own ones. But like everyone else, like some extent, you know, I think they're better off like buying platforms. And, you know, someone's going to have to build those platforms.Swyx [00:34:12]: Yeah. Cool. Let's move on to language models and just specifically that workload just to flesh it out a little bit. You already said that RAMP is like fine tuning 100 models at once simultaneously on modal. Closer to home, my favorite example is ErikBot. Maybe you want to tell that story.Erik [00:34:30]: Yeah. I mean, it was a prototype thing we built for fun, but it's pretty cool. Like we basically built this thing that hooks up to Slack. It like downloads all the Slack history and, you know, fine-tunes a model based on a person. And then you can chat with that. And so you can like, you know, clone yourself and like talk to yourself on Slack. I mean, it's like nice like demo and it's just like, I think like it's like fully contained modal. Like there's a modal app that does everything, right? Like it downloads Slack, you know, integrates with the Slack API, like downloads the stuff, the data, like just runs the fine-tuning and then like creates like dynamically an inference endpoint. And it's all like self-contained and like, you know, a few hundred lines of code. So I think it's sort of a good kind of use case for, or like it kind of demonstrates a lot of the capabilities of modal.Alessio [00:35:08]: Yeah. On a more personal side, how close did you feel ErikBot was to you?Erik [00:35:13]: It definitely captured the like the language. Yeah. I mean, I don't know, like the content, I always feel this way about like AI and it's gotten better. Like when you look at like AI output of text, like, and it's like, when you glance at it, it's like, yeah, this seems really smart, you know, but then you actually like look a little bit deeper. It's like, what does this mean?Swyx [00:35:32]: What does this person say?Erik [00:35:33]: It's like kind of vacuous, right? And that's like kind of what I felt like, you know, talking to like my clone version, like it's like says like things like the grammar is correct. Like some of the sentences make a lot of sense, but like, what are you trying to say? Like there's no content here. I don't know. I mean, it's like, I got that feeling also with chat TBT in the like early versions right now it's like better, but.Alessio [00:35:51]: That's funny. So I built this thing called small podcaster to automate a lot of our back office work, so to speak. And it's great at transcript. It's great at doing chapters. And then I was like, okay, how about you come up with a short summary? And it's like, it sounds good, but it's like, it's not even the same ballpark as like, yeah, end up writing. Right. And it's hard to see how it's going to get there.Swyx [00:36:11]: Oh, I have ideas.Erik [00:36:13]: I'm certain it's going to get there, but like, I agree with you. Right. And like, I have the same thing. I don't know if you've read like AI generated books. Like they just like kind of seem funny, right? Like there's off, right? But like you glance at it and it's like, oh, it's kind of cool. Like looks correct, but then it's like very weird when you actually read them.Swyx [00:36:30]: Yeah. Well, so for what it's worth, I think anyone can join the modal slack. Is it open to the public? Yeah, totally.Erik [00:36:35]: If you go to modal.com, there's a button in the footer.Swyx [00:36:38]: Yeah. And then you can talk to Erik Bot. And then sometimes I really like picking Erik Bot and then you answer afterwards, but then you're like, yeah, mostly correct or whatever. Any other broader lessons, you know, just broadening out from like the single use case of fine tuning, like what are you seeing people do with fine tuning or just language models on modal in general? Yeah.Erik [00:36:59]: I mean, I think language models is interesting because so many people get started with APIs and that's just, you know, they're just dominating a space in particular opening AI, right? And that's not necessarily like a place where we aim to compete. I mean, maybe at some point, but like, it's just not like a core focus for us. And I think sort of separately, it's sort of a question of like, there's economics in that long term. But like, so we tend to focus on more like the areas like around it, right? Like fine tuning, like another use case we have is a bunch of people, Ramp included, is doing batch embeddings on modal. So let's say, you know, you have like a, actually we're like writing a blog post, like we take all of Wikipedia and like parallelize embeddings in 15 minutes and produce vectors for each article. So those types of use cases, I think modal suits really well for. I think also a lot of like custom inference, like yeah, I love that.Swyx [00:37:43]: Yeah. I think you should give people an idea of the order of magnitude of parallelism, because I think people don't understand how parallel. So like, I think your classic hello world with modal is like some kind of Fibonacci function, right? Yeah, we have a bunch of different ones. Some recursive function. Yeah.Erik [00:37:59]: Yeah. I mean, like, yeah, I mean, it's like pretty easy in modal, like fan out to like, you know, at least like 100 GPUs, like in a few seconds. And you know, if you give it like a couple of minutes, like we can, you know, you can fan out to like thousands of GPUs. Like we run it relatively large scale. And yeah, we've run, you know, many thousands of GPUs at certain points when we needed, you know, big backfills or some customers had very large compute needs.Swyx [00:38:21]: Yeah. Yeah. And I mean, that's super useful for a number of things. So one of my early interactions with modal as well was with a small developer, which is my sort of coding agent. The reason I chose modal was a number of things. One, I just wanted to try it out. I just had an excuse to try it. Akshay offered to onboard me personally. But the most interesting thing was that you could have that sort of local development experience as it was running on my laptop, but then it would seamlessly translate to a cloud service or like a cloud hosted environment. And then it could fan out with concurrency controls. So I could say like, because like, you know, the number of times I hit the GPT-3 API at the time was going to be subject to the rate limit. But I wanted to fan out without worrying about that kind of stuff. With modal, I can just kind of declare that in my config and that's it. Oh, like a concurrency limit?Erik [00:39:07]: Yeah. Yeah.Swyx [00:39:09]: Yeah. There's a lot of control. And that's why it's like, yeah, this is a pretty good use case for like writing this kind of LLM application code inside of this environment that just understands fan out and rate limiting natively. You don't actually have an exposed queue system, but you have it under the hood, you know, that kind of stuff. Totally.Erik [00:39:28]: It's a self-provisioning cloud.Swyx [00:39:30]: So the last part of modal I wanted to touch on, and obviously feel free, I know you're working on new features, was the sandbox that was introduced last year. And this is something that I think was inspired by Code Interpreter. You can tell me the longer history behind that.Erik [00:39:45]: Yeah. Like we originally built it for the use case, like there was a bunch of customers who looked into code generation applications and then they came to us and asked us, is there a safe way to execute code? And yeah, we spent a lot of time on like container security. We used GeoVisor, for instance, which is a Google product that provides pretty strong isolation of code. So we built a product where you can basically like run arbitrary code inside a container and monitor its output or like get it back in a safe way. I mean, over time it's like evolved into more of like, I think the long-term direction is actually I think more interesting, which is that I think modal as a platform where like I think the core like container infrastructure we offer could actually be like, you know, unbundled from like the client SDK and offer to like other, you know, like we're talking to a couple of like other companies that want to run, you know, through their packages, like run, execute jobs on modal, like kind of programmatically. So that's actually the direction like Sandbox is going. It's like turning into more like a platform for platforms is kind of what I've been thinking about it as.Swyx [00:40:45]: Oh boy. Platform. That's the old Kubernetes line.Erik [00:40:48]: Yeah. Yeah. Yeah. But it's like, you know, like having that ability to like programmatically, you know, create containers and execute them, I think, I think is really cool. And I think it opens up a lot of interesting capabilities that are sort of separate from the like core Python SDK in modal. So I'm really excited about C. It's like one of those features that we kind of released and like, you know, then we kind of look at like what users actually build with it and people are starting to build like kind of crazy things. And then, you know, we double down on some of those things because when we see like, you know, potential new product features and so Sandbox, I think in that sense, it's like kind of in that direction. We found a lot of like interesting use cases in the direction of like platformized container runner.Swyx [00:41:27]: Can you be more specific about what you're double down on after seeing users in action?Erik [00:41:32]: I mean, we're working with like some companies that, I mean, without getting into specifics like that, need the ability to take their users code and then launch containers on modal. And it's not about security necessarily, like they just want to use modal as a back end, right? Like they may already provide like Kubernetes as a back end, Lambda as a back end, and now they want to add modal as a back end, right? And so, you know, they need a way to programmatically define jobs on behalf of their users and execute them. And so, I don't know, that's kind of abstract, but does that make sense? I totally get it.Swyx [00:42:03]: It's sort of one level of recursion to sort of be the Modal for their customers.Erik [00:42:09]: Exactly.Swyx [00:42:10]: Yeah, exactly. And Cloudflare has done this, you know, Kenton Vardar from Cloudflare, who's like the tech lead on this thing, called it sort of functions as a service as a service.Erik [00:42:17]: Yeah, that's exactly right. FaSasS.Swyx [00:42:21]: FaSasS. Yeah, like, I mean, like that, I think any base layer, second layer cloud provider like yourself, compute provider like yourself should provide, you know, it's a mark of maturity and success that people just trust you to do that. They'd rather build on top of you than compete with you. The more interesting thing for me is like, what does it mean to serve a computer like an LLM developer, rather than a human developer, right? Like, that's what a sandbox is to me, that you have to redefine modal to serve a different non-human audience.Erik [00:42:51]: Yeah. Yeah, and I think there's some really interesting people, you know, building very cool things.Swyx [00:42:55]: Yeah. So I don't have an answer, but, you know, I imagine things like, hey, the way you give feedback is different. Maybe you have to like stream errors, log errors differently. I don't really know. Yeah. Obviously, there's like safety considerations. Maybe you have an API to like restrict access to the web. Yeah. I don't think anyone would use it, but it's there if you want it.Erik [00:43:17]: Yeah.Swyx [00:43:18]: Yeah. Any other sort of design considerations? I have no idea.Erik [00:43:21]: With sandboxes?Swyx [00:43:22]: Yeah. Yeah.Erik [00:43:24]: Open-ended question here. Yeah. I mean, no, I think, yeah, the network restrictions, I think, make a lot of sense. Yeah. I mean, I think, you know, long-term, like, I think there's a lot of interesting use cases where like the LLM, in itself, can like decide, I want to install these packages and like run this thing. And like, obviously, for a lot of those use cases, like you want to have some sort of control that it doesn't like install malicious stuff and steal your secrets and things like that. But I think that's what's exciting about the sandbox primitive, is like it lets you do that in a relatively safe way.Alessio [00:43:51]: Do you have any thoughts on the inference wars? A lot of providers are just rushing to the bottom to get the lowest price per million tokens. Some of them, you know, the Sean Randomat, they're just losing money and there's like the physics of it just don't work out for them to make any money on it. How do you think about your pricing and like how much premium you can get and you can kind of command versus using lower prices as kind of like a wedge into getting there, especially once you have model instrumented? What are the tradeoffs and any thoughts on strategies that work?Erik [00:44:23]: I mean, we focus more on like custom models and custom code. And I think in that space, there's like less competition and I think we can have a pricing markup, right? Like, you know, people will always compare our prices to like, you know, the GPU power they can get elsewhere. And so how big can that markup be? Like it never can be, you know, we can never charge like 10x more, but we can certainly charge a premium. And like, you know, for that reason, like we can have pretty good margins. The LLM space is like the opposite, like the switching cost of LLMs is zero. If all you're doing is like straight up, like at least like open source, right? Like if all you're doing is like, you know, using some, you know, inference endpoint that serves an open source model and, you know, some other provider comes along and like offers a lower price, you're just going to switch, right? So I don't know, to me that reminds me a lot of like all this like 15 minute delivery wars or like, you know, like Uber versus Lyft, you know, and like maybe going back even further, like I think a lot about like sort of, you know, flip side of this is like, it's actually a positive side, which is like, I thought a lot about like fiber optics boom of like 98, 99, like the other day, or like, you know, and also like the overinvestment in GPU today. Like, like, yeah, like, you know, I don't know, like in the end, like, I don't think VCs will have the return they expected, like, you know, in these things, but guess who's going to benefit, like, you know, is the consumers, like someone's like reaping the value of this. And that's, I think an amazing flip side is that, you know, we should be very grateful, the fact that like VCs want to subsidize these things, which is, you know, like you go back to fiber optics, like there was an extreme, like overinvestment in fiber optics network in like 98. And no one made money who did that. But consumers, you know, got tremendous benefits of all the fiber optics cables that were led, you know, throughout the country in the decades after. I feel something similar abou

Imagine getting job opportunities WITHOUT applying for them. Seems too good to be true? Well, that's exactly what happened to Jae Taylor, a tech executive who's worked at famous companies like Microsoft, Expedia, and Salesforce, to name a few.Listen in as he discusses how building a strong personal reputation is essential for career resilience, how it can lead to new opportunities and offer protection during layoffs or organizational changes. As he shares his journey in the tech industry he gives insight into career growth, job-search strategies in an employer-driven economy, and changes in job hunting in different economic climates.Key points discussed:- Building a strong personal reputation within and outside of a company is essential for career resilience, as it can lead to new opportunities and offer protection during layoffs or organizational changes.- Specializing in a domain can give you a competitive edge, especially in a tight job market, as employers may prefer candidates with specific expertise over generalists.- Networking and maintaining relationships are crucial in both up and down economies, as they can lead to job referrals and opportunities that might not be accessible through traditional job applications.Timestamps:(0:00) Introduction and overview of episode's content(1:54) Jay Taylor's journey: Salesforce to Twitter to Peloton(7:47) Anticipation of layoffs at Peloton and volunteering to be laid off(12:22) Lessons learned from layoffs and down tech market(16:17) Sponsor: Get Your Dream Career Course by Jonaed Iqbal(18:39) Importance of continuous learning and preparation for economic shifts(24:27) Jae's experience with job transition after being laid off by Peloton(31:11) Jonaed's advice on choosing a specialty during a down economy(35:14) Jae's advice on building a reputation based on trusted execution(42:12) Jae Taylor discussing the growth of Mentor Mesh community(50:03) Jae Taylor introduces Mentor Mesh.io and its eventsSupport/Contact Jae:- Website: https://mentormesh.io- LinkedIn: https://www.linkedin.com/in/jaeontech/ Books and resources mentioned in this podcast: - Resume course: https://bit.ly/podcastpca  Need career or resume advice? Follow and/or connect with Jonaed Iqbal on LinkedIn.- LinkedIn: https://bit.ly/JonaedIqbalND Connect with us on social media!- LinkedIn: https://bit.ly/NoDegreeLinkedIn- Facebook: https://bit.ly/NoDegreeFB- Instagram: https://bit.ly/NoDegreeIG- Twitter: https://bit.ly/NoDegreeTW- TikTok: https://bit.ly/3qfUD2V- Join our discord server: https://bit.ly/NoDegreeDiscord Thank you for sponsoring our show. If you'd like to support our mission to end the stigma and economic disparity that comes along with not having a college degree, please share with a friend, drop us a review on Apple Podcast and/or subscribe to our Patreon: https://www.patreon.com/nodegree. Remember, no degree? No problem! Whether you're contemplating college or you're a college dropout, get started with your no-degree job search at nodegree.com.

Topics covered in this episode: Dokku Summary of Major Changes Between Python Versions How to check Internet Speed via Terminal? speedtest-cli Blogs: We all should blog more Extras Joke Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training The Complete pytest Course Patreon Supporters Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesdays at 11am PT. Older video versions available there too. Michael #1: Dokku An open source PAAS alternative to Heroku. Dokku helps you build and manage the lifecycle of applications from building to scaling. Powered by Docker, you can install Dokku on any hardware. Once it's set up on a host, you can push Heroku-compatible applications to it via Git. Rich plug in architecture. Brian #2: Summary of Major Changes Between Python Versions Nicholas Hairs Changes between versions & Tools & utilities to help with switching Hopefully you're already at least at 3.8, but come on, 3.11 & 3.12 are so fun! Useful things pyupgrade can automatically upgrade code base (However, I frequently just upgrade and run tests and let my old code be as-is until it bugs me. - Brian) black checks pyproject.toml requires-python setting and uses version specific rules. Versions (way more highlights listed in the article) 3.8 Assignment expressions := walrus f"{variable=}" now works 3.9 Typing has built in generics like dict[], so no more from typing import Dict Dict union operator Strings can removeprefix and removesuffix 3.10 Structural pattern matching match/case Typing: Union using pipe | Dataclasses support slots=True and kw_only=True 3.11 tomllib included as a standard TOMP parser Exception groups Exception Notes add_note() Typing: A Self type Star unpacking expressions allowed in for statements: for x in *a, *b: 3.12 f-strings can re-use quotes Typing: better type parameter syntax Typing: @override decorator ensures a method being overridden by a child class actually exists. Michael #3: How to check Internet Speed via Terminal? speedtest-cli Command line interface for testing internet bandwidth using speedtest.net Just pipx install speedtest-cli Has a Python API too Brian #4: Blogs: We all should blog more Jeff Triplett is attempting one post per day in February Feb 1: Choosing the Right Python and Django Versions for Your Projects Feb 2: My First Mac Which also links to a quite interesting Personal: Default Apps 2023 Feb 3: What's Your Go-to Comfort Media? [rough cut] Feb 4: The Django apps I actually use (rough cut) Feb 5: How to test with Django and pytest fixtures Need ideas? Check out Build an idea bank and never run out of blog ideas Not using AI? Thanks. We appreciate that. Maybe tag it as Not By AI Extras Brian: If upgrading to pytest 8, be aware that running individual tests with parametrization will result in a reverse order. It shouldn't matter. You shouldn't be depending on test order. But it was surprising to me. Issue has been logged Michael: Orbstack follow up Joke: White Lies

Stephanie shares her task of retiring a small, internally-used link-shortening app. She describes the process as both celebratory and a bit mournful. Meanwhile, Joël discusses his deep dive into ActiveRecord, particularly in the context of debugging. He explores the complexities of ActiveRecord querying schemas and the additional latency this introduces. Together, the hosts discuss the nuances of package management systems and their implications for developers. They touch upon the differences between system packages and language packages, sharing personal experiences with tools like Homebrew, RubyGems, and Docker. Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, this week, I got to have some fun working on some internal thoughtbot work. And what I focused on was retiring one of our just, like, small internal self-hosted on Heroku apps in favor of going with a third-party service for this functionality. We basically had a tiny, little app that we used as a link-shortening service. So, if you've ever seen a tbot.io short link out in the world, we were using our just, like, an in-house app to do that, you know, but for various reasons, we wanted to...just it wasn't worth maintaining anymore. So, we wanted to just use a purchased service. But today, I got to just, like, do the little bit of, like, tidying up, you know, in preparation to archive a repo and kind of delete the app from Heroku, and I hadn't done that before. So, it felt a little bit celebratory and a little bit mournful even [laughs] to, you know, retire something like that. And I was pairing with another thoughtbot developer, and we used a pairing app called Tuple. And you can just send, like, fun reactions to each other. Like, you could send, like, a fire emoji [laughs] or something if that's what you're feeling. And so, I sent some, like, confetti when we clicked the, "I understand what deleting this app means on GitHub." But I joked that "Actually, I feel like what I really needed was a, like, a salute kind of like thank you for your service [laughs] type of reaction." JOËL: I love those moments when you're kind of you're hitting those kind of milestone-y moments, and then you get to send a reaction. I should do that more often in Tuple. Those are fun. STEPHANIE: They are fun. There's also a, like, table flip reaction, too, is one that I really enjoy [laughs], you know, you just have to manifest that energy somehow. And then, after we kind of sent out an email to the company saying like, "Oh yeah, we're not using our app anymore for link shortening," someone had a great suggestion to make our archived repo public instead of private. I kind of liked it as a way of, like, memorializing this application and let community members see, you know, real code in a real...the application that we used here at thoughtbot. So, hopefully, if not me, then someone else will be able to do that and maybe publish a little blog post about that. JOËL: That's exciting. So, it's not currently public, the repo, but it might be at some point in the future. STEPHANIE: Yeah, that's right. JOËL: We'll definitely have to mention it on a future episode if that happens so that people following along with the story can go check out the code. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been doing a deep dive into how ActiveRecord works. Particularly, I am debugging some pretty significant slowdowns in querying ActiveRecord models that are backed not by a regular Postgres database but instead a Snowflake data warehouse via an ODBC connection. So, there's a bunch of moving pieces going on here, and it would just take forever to make any queries. And sure, the actual reported query time is longer than for a local Postgres database, but then there's this sort of mystery extra waiting time, and I couldn't figure out why is it taking so much longer than the actual sort of recorded query time. And I started digging into all of this, and it turns out that in addition to executing queries to pull actual data in, ActiveRecord needs to, at various points, query the schema of your data store to pull things like names of tables and what are the indexes and primary keys and things like that. STEPHANIE: Wow. That sounds really cool and something that I have never needed to do before. I'm curious if you noticed...you said that it takes, I guess, longer to query Snowflake than it would a more common Postgres database. Were you noticing this performance slowness locally or on production? JOËL: Both places. So, the nice thing is I can reproduce it locally, and locally, I mean running the Rails app locally. I'm still talking to a remote Snowflake data warehouse, which is fine. I can reproduce that slowness locally, which has made it much easier to experiment and try things. And so, from there, it's really just been a bit of a detective case trying to, I guess, narrow the possibility space and try to understand what are the parts that trigger slowness. So, I'm printing timestamps in different places. I've got different things that get measured. I've not done, like, a profiling tool to generate a flame graph or anything like that. That might have been something cool to try. I just did old-school print statements in a couple of places where I, like, time before, time after, print the delta, and that's gotten me pretty far. STEPHANIE: That's pretty cool. What do you think will be an outcome of this? Because I remember you saying you're digging a little bit into ActiveRecord internals. So, based on, like, what you're exploring, what do you think you could do as a developer to increase some of the performance there? JOËL: I think probably what this ends up being is finding that the Snowflake adapter that I'm using for ActiveRecord maybe has some sort of small bug in it or some implementation that's a little bit too naive that needs to be fine-tuned. And so, probably what ends up happening here is that this finishes as, like, an open-source pull request to the Snowflake Adapter gem. STEPHANIE: Yeah, that's where I thought maybe that might go. And that's pretty cool, too, and to, you know, just be investigating something on your app and being able to make a contribution that it benefits the community. JOËL: And that's what's so great about open source because not only am I able to get the source to go source diving through all of this, because I absolutely need to do that, but also, then if I make a fix, I can push that fix back out to the community, and everybody gets to benefit. STEPHANIE: Cool. Well, that's another thing that I look forward to hearing more on the development of [laughs] later if it pans out that way. JOËL: One thing that has been interesting with this Snowflake work is that there are a lot of moving parts and multiple different packages that I need to install to get this all to work. So, I mentioned that I might be doing a pull request against the Snowflake Adapter for ActiveRecord, but all of this talks through a sort of lower-level technology protocol called ODBC, which is a sort of generic protocol for speaking to data stores, and that actually has two different pieces. I had to install two different packages. There is a sort of low-level executable that I had to install on my local dev machine and that I have to install on our servers. And on my Mac, I'm installing that via Homebrew, which is a system package. And then to get Ruby bindings for that, there is a Ruby gem that I install that allows Ruby code to talk to ODBC, and that's installed via RubyGems or Bundler. And that got me thinking about sort of these two separate ecosystems that I tend to work with every day. We've got sort of the system packages and the, I don't know what you want to call them, language packages maybe, things like RubyGems, but that could also be NPM or whatever your language of choice is, and realizing that we kind of have things split into two different zones, and sometimes we need both and wondering a little bit about why is that difference necessary. STEPHANIE: Yeah, I don't have an answer to that [laughs] question right now, but I can say that that was an area that really tripped me up, I think, when I was first a fledgling developer. And I was really confused about where all of these dependencies were coming from and going through, you know, setting up my first project and being, like, asked to install Postgres on my machine but then also Bundler, which then also installs more dependencies [laughs]. The lines between those ecosystems were not super clear to me. And, you know, even now, like, I find myself really just kind of, like, learning what I need to know to get by [laughs] with my day-to-day work. But I do like what you said about these are kind of the two main layers that you're working with in terms of package management. And it's really helpful to have that knowledge so you can troubleshoot when there is an issue at one or the other. JOËL: And you mentioned Postgres. That's another one that's interesting because there are components in both of those ecosystems. Postgres itself is typically installed via a system package manager, so something like Homebrew on a Mac or apt-get on a Linux machine. But then, if you're interacting with Postgres in a Ruby app, you're probably also installing the pg gem, which are Ruby's bindings for Postgres to allow Ruby to talk to Postgres, and that lives in the package ecosystem on RubyGems. STEPHANIE: Yeah, I've certainly been in the position of, you know, again, as consultants, we oftentimes are also setting up new laptops entirely [laughs] like client laptops and such and bundling and the pg gem is installed. And then at least I have, you know, I have to give thanks to the very clear error message that [laughs] tells me that I don't have Postgres installed on my machine. Because when I mentioned, you know, troubleshooting earlier, I've certainly been in positions where it was really unclear what was going on in terms of the interaction between what I guess we're calling the Ruby package ecosystem and our system level one. JOËL: Especially for things like the pg gem, which need to compile against some existing libraries, those always get interesting where sometimes they'll fail to compile because there's a path to some C compiler that's not set correctly or something like that. For me, typically, that means I need to update the macOS command line tools or the Xcode command line tools; I forget what the name of that package is. And, usually, that does the trick. That might happen if I've upgraded my OS version recently and haven't downloaded the latest version of the command line tools. STEPHANIE: Yeah. Speaking of OS versions, I have a bit of a story to share about using...I've never said this name out loud, but I am pretty sure that it would just be pronounced as wkhtmltopdf [laughs]. For some reason, whenever I see words like that in my brain, I want to, like, make it into a pronounceable thing [laughs]. JOËL: Right, just insert some vowels in there. STEPHANIE: Yeah, wkhtmltopdf [laughs]. Anyway, that was being used in an app to generate PDF invoices or something. It's a pretty old tool. It's a CLI tool, and it's, as far as I can tell, it's been around for a long time but was recently no longer maintained. And so, as I was working on this app, I was running into a bug where that library was causing some issues with the PDF that was generated. So, I had to go down this route of actually finding a Ruby gem that would figure out which package binary to use, you know, based off of my system. And that worked great locally, and I was like, okay, cool, I fixed the issue. And then, once I pushed my change, it turns out that it did not work on CI because CI was running on Ubuntu. And I guess the binary didn't work with the latest version of Ubuntu that was running on CI, so there was just so many incompatibilities there. And I was wanting to fix this bug. But the next step I took was looking into community-provided packages because there just simply weren't any, like, up-to-date binaries that would likely work with these new operating systems. And I kind of stopped at that point because I just wasn't really sure, like, how trustworthy were these community packages. That was an ecosystem I didn't know enough about. In particular, I was having to install some using apt from, you know, just, like, some Linux community. But yeah, I think I normally have a little bit more experience and confidence in terms of the Ruby package ecosystem and can tell, like, what gems are popular, which ones are trustworthy. There are different heuristics I have for evaluating what dependency to pull in. But here I ended up just kind of bailing out of that endeavor because I just didn't have enough time to go down that rabbit hole. JOËL: It is interesting that learning how to evaluate packages is a skill you have to learn that varies from package community to package community. I know that when I used to be very involved with Elm, we would often have people who would come to the Elm community from the JavaScript community who were used to evaluating NPM packages. And one of the metrics that was very popular in the JavaScript community is just stars on GitHub. That's a really important metric. And that wasn't really much of a thing in the Elm community. And so, people would come and be like, "Wait, how do I know which package is good? I don't see any stars on GitHub." And then, it turns out that there are other metrics that people would use. And similarly, you know, in Ruby, there are different ways that you might use to evaluate Ruby gems that may or may not involve stars on GitHub. It might be something entirely different. STEPHANIE: Yeah. Speaking of that, I wanted to plug a website that I have used before called the Ruby Toolbox, and that gives some suggestions for open-source Ruby libraries of various categories. So, if you're looking for, like, a JSON parser, it has some of the more popular ones. If you're looking for, you know, it stores them by category, and I think it is also based on things like stars and forks like that, so that's a good one to know. JOËL: You could probably also look at something like download numbers to see what's popular, although sometimes it's sort of, like, an emergent gem that's more popular. Some of that almost you just need to be a little bit in the community, like, hearing, you know, maybe listening to podcasts like this one, subscribing to Ruby newsletters, going to conferences, things like that, and to realize, okay, maybe, you know, we had sort of an old staple for JSON parsing, but there's a new thing that's twice as fast. And this is sort of becoming the new standard, and the community is shifting towards that. You might not know that just by looking at raw stats. So, there's a human component to it as well. STEPHANIE: Yeah, absolutely. I think an extension of knowing how to evaluate different package systems is this question of like, how much does an average developer need to know about package management? [laughs] JOËL: Yeah, a little bit to a medium amount, and then if you're writing your own packages, you probably need to know a little bit more. But there are some things that are really maybe best left to the maintainers of package managers. Package managers are actually pretty complex pieces of software in terms of all of the dependency management and making sure that when you say, "Oh, I've got Rails, and this other gem, and this other gem, and it's going to find the exact versions of all those gems that play nicely together," that's non-trivial. As a sort of working developer, you don't need to know all of the algorithms or the graph theory or any of that that underlies a package manager to be able to be productive in your career. And even as a package developer, you probably don't need to really know a whole lot of that. STEPHANIE: Yeah, that makes sense. I actually had referred to our internal at thoughtbot here, our kind of, like, expectations for skill levels for developers. And I would say for an average developer, we kind of just expect a basic understanding of these more complex parts of our toolchain, I think, specifically, like, command line tools and package management. And I think I'd mentioned earlier that, for me, it is a very need-to-know basis. And so, yeah, when I was going down that little bit of exploration around why wkhtmltopdf [chuckles] wasn't working [chuckles], it was a bit of a twisty and turning journey where I, you know, wasn't really sure where to go. I was getting very obtuse error messages, and, you know, I had to dive deep into all these forums [laughs] for all the various platforms [laughs] about why libraries weren't working. And I think what I did come away with was that like, oh, like, even though I'm mostly working on my local machine for development, there was some amount of knowledge I needed to have about the systems that my CI and, you know, production servers are running on. The project I was working on happened to have, like, a Docker file for those environments, and, you know, kind of knowing how to configure them to install the packages I needed to install and just knowing a little bit about the different ways of doing that on systems outside of my usual daily workflows. JOËL: And I think that gets back to some of the interesting distinctions between what we might call language packages versus system packages is that language packages more or less work the same across all operating systems. They might have a build step that's slightly different or something like that, but system packages might be pretty different between different operating systems. So, development, for me, is a Mac, and I'm probably installing system packages via something like Homebrew. If I then want that Rails app to run on CI or some Linux server somewhere, I can't use Homebrew to install things there. It's going to be a slightly different package ecosystem. And so, now I need to find something that will install Postgres for Linux, something that will install, I guess, wkhtmltopdf [laughs] for Linux. And so, when I'm building that Docker file, that might be a little bit different for Mac versus for...or I guess when you run a Docker file, you're running a containerized system. So, the goal there is to make this system the same everywhere for everyone. But when you're setting that up, typically, it's more of a Linux-like system. And so running inside the Docker container versus outside on the native Mac might involve a totally different set of packages and a different package tool. As opposed to something like Bundler, you've got your gem file; you bundle install. It doesn't matter if you're on Linux or macOS. STEPHANIE: Yes, I think you're right. I think we kind of answered our own question at the top of the show [laughs] about differences and what do you need to know about them. And I also like how you pointed out, oh yeah, like, Docker is supposed to [laughs], you know, make sure that we're all developing in the same system, essentially. But, you know, sometimes you have different use cases for it. And, yeah, when you were talking about installing an application on your native Mac and using Homebrew, but even, you know, not everyone even uses Homebrew, right? You can install manually [laughs] through whatever official installer that application might provide. So, there's just so many different ways of doing something. And I had the thought that it's too bad that we both [chuckles] develop on Mac because it could be really interesting to get a Linux user's perspective in here. JOËL: You mentioned not installing via Homebrew. A kind of glaring example of that in my personal setup is that I use Postgres.app to manage Postgres on my machine rather than using Homebrew. I've just...over the years, the Homebrew version every time I upgrade my operating system or something, it's just such a pain to update, and I've lost too many hours to it, and Postgres.app just works, and so I've switched to that. Most other things, I'll use the Homebrew version, but Postgres it's now Postgres.app. It's not even a command line install, and it works fine for me. STEPHANIE: Nice. Yeah. That's interesting. That's a good tip. I'll have to look into that next time because I have also certainly had to just install so many [laughs] various versions of Postgres and figure out what's going on with them every time I upgrade my OS. I'm with you, though, in terms of the packages world I'm looking for, it works [laughs]. JOËL: So, you'd mentioned earlier that packages is sort of an area that's a bit of a need-to-know basis for you. Are there, like, particular moments in your career that you remember like, oh, that's the moment where I needed to, like, take some time and learn a little bit of the next level of packages? STEPHANIE: That's a great question. I think the very beginnings of understanding how package versions work when you have multiple projects on your machine; I just remember that being really confusing for me. When I started out, like, you know, as soon as I cloned my second repo [laughs], and was very confused about, like, I'm sure I went through the process of not installing gems using Bundler, and then just having so much chaos [laughs] wrecked in my development environment and, you know, having to ask someone, "I don't understand how this works. Like, why is it saying I have multiple versions of this library or whatever?" JOËL: Have you ever sudo gem installed a gem? STEPHANIE: Oh yeah, I definitely have. I can't [laughs], like, even give a good reason for why I have done it, but I probably was just, like, pulling my hair out, and that's what Stack Overflow told me to do. I don't know if I can recommend that, but it is [chuckles] one thing to do when you just are kind of totally stuck. JOËL: There was a time where I think that that was in the READMEs for most projects. STEPHANIE: Yeah, that's a really good point. JOËL: So, that's probably why a lot of people end up doing that, but then it tends to install it for your system Ruby rather than for...because if you're using something like Rbenv or RVM or ASDF to manage multiple Ruby versions, those end up being what's using or even Homebrew to manage your Ruby. It wouldn't be installing it for those versions of Ruby. It would be installing it for the one that shipped with your Mac. I actually...you know what? I don't even know if Mac still ships with Ruby. It used to. It used to ship with a really old version of Ruby, and so the advice was like, "Hey, every repo tells you to install it with sudo; don't do that. It will mess you up." STEPHANIE: Huh. I think Mac still does ship with Ruby, but don't quote me on that [laughter]. And I think that's really funny that, like, yeah, people were just writing those instructions in READMEs. And I'm glad that we've collectively [laughs] figured out that difference and want to, hopefully, not let other developers fall into that trap [laughs]. Do you have a particular memory or experience when you had to kind of level up your knowledge about the package ecosystem? JOËL: I think one sort of moment where I really had to level up is when I started really needing to understand how install paths worked, especially when you have, let's say, multiple versions of a gem installed because you have different projects. And you want to know, like, how does it know which one it's using? And then you see, oh, there are different paths that point to different directories with the installs. Or when you might have an executable you've installed via Homebrew, and it's like, oh yeah, so I've got this, like, command that I run on my shell, but actually that points to a very particular path, you know, in my Homebrew directory. But maybe it could also point to some, like, pre-installed system binaries or some other custom things I've done. So, there was a time where I had to really learn about how the path shell variable worked on a machine in order to really understand how the packages I installed were sometimes showing up when I invoked a binary and sometimes not. STEPHANIE: Yeah, that is another really great example that I have memories of [laughs] being really frustrated by, especially if...because, you know, we had talked earlier about all the different ways that you can install applications on your system, and you don't always know where they end up [laughs]. JOËL: And this particular memory is tied to debugging Postgres because, you know, you're installing Postgres, and some paths aren't working. Or maybe you try to update Postgres and now it's like, oh, but, like, I'm still loading the wrong one. And why does PSQL not do the thing that I think it does? And so, that forced me to learn a little bit about, like, under the hood, what happens when I type brew install PostgreSQL? And how does that mesh with the way my shell interprets commands and things like that? So, it was maybe a little bit of a painful experience but eye-opening and definitely then led to me, I think, being able to debug my setup much more effectively in the future. STEPHANIE: Yeah. I like that you also pointed out how it was interacting with your shell because that's, like, another can of worms, right? [laughs] In terms of just the complexity of how these things are talking to each other. JOËL: And for those of our listeners who are not familiar with this, there is a shell command that you can use called which, W-H-I-C-H. And you can prefix that in front of another command, and it will tell you the path that it's using for that binary. So, in my case, if I'm looking like, why is this PSQL behaving weirdly or seems to be using the old version, I can type 'which space psql', and it'll say, "Oh, it's going to this path." And I can look at it and be like, oh, it's using my system install of Postgres. It's not using the Homebrew one. Or, oh, maybe it's using the Homebrew install, not my Postgres.app version. I need to, like, tinker with the paths a little bit. So, that has definitely helped me debug my package system more than once. STEPHANIE: Yeah, that's a really good tip. I can recall just totally uninstalling everything [laughs] and reinstalling and fingers crossed it would figure out a route to the right thing [laughs]. JOËL: You know what? That works. It's not the, like, most precise solution but resetting your environment when all else fails it's not a bad solution. So, we've been talking a lot about what it's like to interact with a package ecosystem as developers, as users of packages, but what if you're a package developer? Sometimes, there's a very clear-cut place where to publish, and sometimes it's a little bit grayer. So, I could see, you know, I'm developing a database, and I want that to be on operating systems, probably should be a system-level package rather than a Ruby gem. But what if I'm building some kind of command line tool, and I write it in Ruby because I like writing Ruby? Should I publish that as a gem, or should I publish that as some kind of system package that's installed via Homebrew? Any opinions or heuristics that you would use to choose where to publish on one side or the other? STEPHANIE: As not a package developer [laughs], I can only answer from that point of view. That is interesting because if you publish on a, you know, like, a system repository, then yeah, like, you might get a lot more people using your tool out there because you're not just targeting a specific language's community. But I don't know if I have always enjoyed downloading various things to my system's OS. I think that actually, like, is a bit complicated for me or, like, I try to avoid it if I can because if something can be categorized or, like, containerized in a way that, like, feels right for my mental model, you know, if it's written in Ruby or something really related to things I use Ruby in, it could be nice to have that installed in my, like, systems RubyGems. But I would be really interested to hear if other people have opinions about where they might want to publish a package and what kind of developers they're hoping to find to use their tool. JOËL: I like the heuristic that you mentioned here, the idea of who the audience is because, yeah, as a Ruby developer who already has a Ruby setup, it might be easier for me to install something via a gem. But if I'm not a Ruby developer who wants to use the packages maybe a little bit more generic, you know, let's say, I don't know, it's some sort of command line tool for interacting with GitHub or something like that. And, like, it happens to be written in Ruby, but you don't particularly care about that as a user of this. Maybe you don't have Ruby installed and now you've got to, like, juggle, like, oh, what is RubyGems, and Bundler, and all this stuff? And I've definitely felt that occasionally downloading packages sort of like, oh, this is a Python package. And you're going to need to, like, set up all this stuff. And it's maybe designed for a Python audience. And so, it's like, oh, you're going to set up a virtual environment and all these things. I'm like, I just want your command line tools. I don't want to install a whole language. And so, sometimes there can be some frustration there. STEPHANIE: Yeah, that is very true. Before you even said that, I was like, oh, I've definitely wanted to download a command line tool and be like, first install [laughs] Python. And I'm like, nope, I'm bailing out of this. JOËL: On the other hand, as a developer, it can be a lot harder to write something that's a bit more cross-platform and managing all that. And I've had to deal a little bit with this for thoughtbot's Parity tool, which is a command-line tool for working with Heroku. It allows you to basically run commands on either staging or production by giving you a staging command and a production command for common Heroku CLI tasks, which makes it really nice if you're working and you're having to do some local, some development, some staging, and some production things all from your command line. It initially started as a gem, and we thought, you know what? This is mostly command line, and it's not just Rubyists who use Heroku. Let's try to put this on Homebrew. But then it depends on Ruby because it's written in Ruby. And now we had to make sure that we marked Ruby as a dependency in Homebrew, which meant that Homebrew would then also pull in Ruby as a dependency. And that got a little bit messy. For a while, we even experimented with sort of briefly available technology called Traveling Ruby that allowed you to embed Ruby in your binary, and you could compile against that. That had some drawbacks. So, we ended up rolling that back as well. And eventually, just for maintenance ease, we went back to making this a Ruby gem and saying, "Look, you install it via RubyGems." It does mean that we're targeting more of the Ruby community. It's going to be a little bit harder for other people to install, but it is easier for us to maintain. STEPHANIE: That's really interesting. I didn't know that history about Parity. It's a tool that I have used recently and really enjoyed. But yeah, I think I remember someone having some issues between installing it as a gem and installing it via Homebrew and some conflicts there as well. So, I can also see how trying to decide or maybe going down one path and then realizing, oh, like, maybe we want to try something else is certainly not trivial. JOËL: I think, in me, I have a little bit of the idealist and the pragmatist that fight. The idealist says, "Hey, if it's not, like, aimed for Ruby developers as a, like, you can pull this into your codebase, if it's just command line tools and the fact that it's written in Ruby is an implementation detail, that should be a system package. Do not distribute binaries via RubyGems." That's the idealist in me. The pragmatist says, "Oh, that's a lot of work and not always worth it for both the maintainers and sometimes for the users, and so it's totally okay to ship binaries as RubyGems." STEPHANIE: I was totally thinking that I'm sure that you've been in that position of being a user and trying to download a system package and then seeing it start to download, like, another language. And you're like, wait, what? [laughter] That's not what I want. JOËL: So, you and I have shared some of our heuristics in the way we approach this problem. Now, I'm curious to hear from the audience. What are some heuristics that you use to decide whether your package is better shipped on RubyGems versus, let's say, Homebrew? Or maybe as a user, what do you prefer to consume? STEPHANIE: Yes. And speaking of getting listener feedback, we're also looking for some listener questions. We're hoping to do a bit of a grab-bag episode where we answer your questions. So, if you have anything that you're wanting to hear me and Joël's thoughts on, write us at hosts@bikeshed.fm. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Stephanie recommends "Blue Eye Samurai" and a new ceramic pot (donabe) for cooking. Joël talks about the joy of holding a warm beverage in a unique mug. Stephanie discusses her shift to a part-time support and maintenance role at thoughtbot, contrasting it with her full-time development work. She highlights the importance of communication, documentation, and workplace flexibility in this role. Stephanie appreciates the professional growth opportunities and aligns this flexible work style with her long-term career goals. Blue Eye Samurai (https://www.netflix.com/title/81144203) Donabe pots (https://jinenstore.com/collections/nagatani-en) thoughtbot's Support & Maintenance services (https://thoughtbot.com/services/rails-maintenance) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: I have a TV show recommendation this week. I think this is my first time having TV or movies to recommend, so this will be fun. My partner and I just finished watching Blue Eye Samurai on Netflix, which is an animated historical Samurai drama. But the really cool thing about it is that the protagonist she's a woman who is disguising herself as a man, and she is half Japanese and half White, which the show takes place during Edo, Japan. And so that was a time when Japan was locked down, and there were no outsiders allowed in the country. And so, to be mixed race like that was to be, like, kind of, like, demonized and to be really excluded and shamed. And so, the main character is on, like, a revenge mission. And it was such a cool show. I was kind of, like, on the edge of my seat the whole time. And it's very beautifully animated. There were just a lot of really awesome things about it. And I think it's very different from what I've been seeing on TV these days. JOËL: Is this a single-season show? STEPHANIE: So far, there's just one season. I think it's pretty new, yeah. It's very watchable in a couple of weekends. [laughter] JOËL: Dangerously so. STEPHANIE: Yeah, exactly [laughs]. JOËL: How do you feel about the way they end the arc in season one? Do they kind of leave you on a cliffhanger, or does it feel like a pretty satisfying place? STEPHANIE: Ooh, I think both, which is the sweet spot, in my opinion, where it's not, like, cliffhanger for the sake of, like, ugh, now I feel like I have to just watch the next part to see what happens because I was left unsatisfied. I like when seasons are kind of like chapters of the story, right? And the characters are also well written, too, and really fleshed out even, you know, some of the side characters. They all have their arcs that are really satisfying. And, again, I just was left very impressed. JOËL: I guess that's the power of good storytelling. STEPHANIE: Yeah. I was reading a review of the show. And that was kind of the theme of–it was just that, like, this is really good storytelling, and I would have to agree. Yeah, I highly recommend checking it out. It was very fun. It was very bloody, but [chuckles], for me, it being animated actually made it a little more palatable for me [laughs]. The fight scenes, the action scenes were really cool. I think the way that it's been described is kind of, like, you know, if you like historical dramas, or if you like things like Game of Thrones, there's kind of something for everyone. I recommend checking it out. Joël, what's new in your world? JOËL: Listeners of the show don't know this, but you and I are on a video call while we're recording this. And you'd commented earlier that I was holding a cool mug. It's got a rock climbing hold as a handle, which is pretty fun. I enjoy a lot of bouldering. That makes it a fun mug. But I was recently thinking about just how much pleasure I get from holding a mug with a warm beverage. It's such a small thing, but it makes me so happy. And that got me thinking more broadly about what are things in life that are kind of like that. They're small things that have, like, an outsized impact on your happiness. Do you have anything like that? STEPHANIE: Oh yes, absolutely. You were talking about the warmth of a hot beverage in your hands. And I was thinking about something similar, too, because I'm pretty sure this time of year last year, I talked about something that was new in my world that was just, like, a thing that I got to make winter more tolerable for me here in Chicago, and I think it was, like, a heated blanket [laughs]. And I am similarly in that space this year of like, what can I do or get to make this winter better than last winter? So, this year, what I got that I'm really excited to use— it actually just came in the mail—is this ceramic pot called the donabe that's kind of mainly used for Japanese cooking, especially, like, hot pot. And so, it will be a huge improvement to my soup game this year [laughs]. Similarly, it's kind of, like, one of those small things where you can take it from the stovetop where you're cooking straight to the table, and I'm so looking forward to that. It's kind of like your hot beverage in your hand but, like, three times the size [laughs]. JOËL: Right. The family-style version of it. STEPHANIE: Yeah, exactly. So, that's what I'm really looking forward to this year as something that is just, like, I don't know, a little small upgrade to my regular soup routine. But I think I will get a lot of pleasure [laughs] out of it. JOËL: What do you normally cook in that style of pot? Is it typically you do a hot pot in there, or is it meant for soups? STEPHANIE: Yeah, it holds heat really well, so I think that's why it's used for soup a lot. And the one that I got specifically has a little ceramic steamer plate as well. And so, I'm looking forward to having, like, this setup that's made for steaming, where you don't have to have any, like, too many extra bits. And, again, it can go from stove to table, and that's one less thing I [chuckles] need to wash. JOËL: I love it. So, something else that is kind of new in your world is you'd mentioned on a recent episode you'd wrapped up with your current client. And you've rotated on to not exactly a new client but a new almost line of business. You're doing a rotation with our support and maintenance team. Can you tell us a little bit about what that is like? STEPHANIE: Yeah. I'm excited to share more about it because this is my first time on this team doing this work. And it's pretty new for thoughtbot, too. I think it's only, like, a year old that we have had this sub-team of the one that you and I are on, Boost. In the sub-team, support and maintenance is focused on providing flexible part-time work for clients who are just needing some dedicated hours, not necessarily for, you know, a lot of, like, intense new feature work, but making sure that things are running smoothly. A lot of the clients, you know, have had Rails apps that are several years old, that are chugging along [chuckles], just need that, like, attention every now and then to make sure that upgrades are happening, fix any bugs, kind of as the app just continues to work and provide value. And then, occasionally, there is a little bit of feature work. But the interesting thing about being on this team is that instead of being on one client full-time, you are working on a lot of different clients at the same time, and a lot of them are on retainers. So, they maybe have, like, 20 hours a month of work that gets filled with kind of whatever tasks need to be done during that time. So yeah, I recently joined a few days ago and have been very surprised by kind of this style of work. It's different from what I'm used to. JOËL: That seems pretty different than the sort of traditional thoughtbot client engagement. Typically, if I'm a client and I'm hiring a team from thoughtbot, as a client, I get sort of a dedicated team. And they're probably either building some things for me or maybe working with my team and sort of full-time building features. Whereas if I hire the support and maintenance team, it sounds like it's a bit more ad hoc. And it's things I assume it's like, oh, we probably need to upgrade our Rails version since a new release came out last month. Can you do that? Here's a small bug that was reported. Can somebody fix that? Things along those lines. Is that pretty approximate of what the experience is for a client? STEPHANIE: Yeah, I would say so. I think the other surprising thing has been there have been a little bit of more DevOps type of tasks as well mixed in there. Because oftentimes, these are smaller clients who maybe have, like, a few developers actively working on new features and that type of stuff. But there is, like, so much of the connecting work that needs to happen when you have an application. And if you don't have a full in-house team for that, that often gets put on developers' plates. But it's kind of nice to have this flexible support and maintenance team, again, to, like, do the work as it comes up. A lot of it is not necessarily, like, stuff that can be planned in advance. It's kind of like, oh, we're hitting, like, our usage limit for this Heroku add-on. Let's evaluate if this is still working for us, if this is a good tier to be on. Like, should we upgrade? Are there other levers we could pull or adjustments we can make? So, that's actually been some of the stuff that I've been working on, too, which is, again, a little bit different from normal development work but also still very much related. And it's all kind of part of the job. And, you know, a lot of the skills are transferable. And to know how to do development in a framework then sets you up, I think, really well to, like, be able to make those kinds of evaluations. JOËL: So, it sounds like you almost, in a sense, provide a bit of a velocity cushion for clients so that if something does come up where they would maybe normally need to pull a dev off of feature work to do some side thing for a couple of days, you can come in and handle that so that their dev team stays focused on shipping features. STEPHANIE: Yeah, I like that phrase you used: velocity cushion. That's cool. I like it. The other surprising thing that I have kind of quite enjoyed, at least for now, is because we bill a little bit differently on this work; we have to track our hours more explicitly. And that has actually helped me focus a lot more on what I'm doing and if I should continue to be doing what I'm doing. I'm timeboxing things a lot more because I know that if there is a ceiling on the number of hours, I want to make sure that that time is spent in the most valuable way. And I also really enjoy, like, the boundaries of timeboxing, yes, but also, like, the tasks are usually scoped pretty narrowly so that they are things that you can accomplish, definitely in the week, because you don't know if you'll kind of still be working for this client next week but even more so, like, within a few days. And that is nice because I can kind of, like, you know, track my hours, finish the task, and then feel a little bit more free to go do something else without being, like, okay, like, what's the next thing that I need to be doing? There's a little bit more freedom, I think, when you're kind of, like, optimizing towards, like, finishing each item. JOËL: Do the stories of the work that you have to do does it typically come kind of pre-scoped? Are you involved in making sure that it has, like, very aggressive scoping? STEPHANIE: Yeah. So far, I've not been involved in doing the scoping work, and it has come pre-scoped, which has been nice. This was also, again, just different. Because I was on a client team previously, a lot of the work to be done was the disambiguating, the, like, figuring out what to be doing. Whereas here, because, again, we're kind of optimized for people coming in and out, if there is uncertainty or lack of clarity, it's pointed out early, and someone is like, "Okay, I will take care of this. Like, I'll take the lead on this so that it can be handed off." One client that I'm working on is using Basecamp's Shape Up methodology, which I actually hadn't worked with in a very explicit way before. And that has been interesting to learn about a little bit, too. One thing that I have enjoyed about it is instead of sprints, they're called cycles. And I like that a lot because, you know, sprints kind of have the connotation of, like, you're running as fast as you can but also, like, you can't run that way forever [laughs]. And so, even that, like, little bit of rewording change is really nice. The variable part is scope, right? It's we're focused on delivering something completely and very intentionally cutting scope as kind of the main lever. JOËL: How do you maintain sort of focus and flow if you're jumping across multiple clients? Because you said, you work with multiple clients as part of this team. And I feel like I can get a little bit frustrated sometimes, even just jumping between, like, tickets within one project. And so, I could imagine that jumping between different clients during the week or even the day might be really disruptive. Have you found techniques to help you stay in the flow? STEPHANIE: Yeah, that is a tough one because, also, every client has their different application; you then have to start up on [laughs] your local machine, and that is kind of annoying. You know, I do still tend to kind of, like, bundle similar work together. If, like, there's a few things I can do for a client on one day, I'll make sure to focus on that. But what I mentioned earlier about, like, seeing something to completion has been really, I want to say, fun even. Because it then kind of, like, frees up that mental space of, like, okay, I don't have to, like, have this thing that I'm working on lingering in my head about, like, oh, did I forget to do something? Or, you know, have, like, shower thoughts of like, oh, I just thought of a new way to implement this [laughs] feature because it doesn't spill over as much as maybe larger initiatives anyway. And so, I am context-switching, but it's only kind of after I've gotten something to a good place where I've left all of the notes. And that's another thing that I'm now kind of compelled to do a little more actively. It's like, every single day, I'm kind of making sure that the work that I've done has been reported on, one, because I have to track my hours, so, you know, and I sometimes leave notes about what that time was spent on doing. And also, when the expectation is that someone else will be picking up, then there's no, like, oh, like, let me hold on to this, and only when I know that I have to hand off something that's when I'll do the, like, dedicated knowledge dumping. It's kind of just built into the process a little more frequently. JOËL: So, you're setting up for, like, an imminent vacation factor. STEPHANIE: Yeah. Which I kind of like because then I can take a vacation [laughs] whenever I want and not have to worry too much about, oh, did I do everything I needed to do before I leave? JOËL: So, you know, these practices that you're doing are specifically adapted for the style of work that you have. Are there any that you think you would bring to your own practice if you ever rotated back on to a dedicated client project, anything that you would do there that you would want to include from your practice here? STEPHANIE: Yeah. It does sound kind of weird because part of what's nice about being on a full-time team is that there is less, oh, if I don't get something done today, I have tomorrow to do it [laughs]. And it seems like that would be like, oh, like, kind of take the pressure off a little bit. But I would be really curious to continue having, like, such an intense awareness about how I'm spending my time. Because I've certainly gotten a little bit lax on, like, full-time development work when you just go down a rabbit hole [laughs] and you come out, like, three hours later, and you're like, "What did I just do?" [laughs] And, you know, maybe that's what needed to be done, and that's fine. But if you have the information that it took you three hours, you can at least make a better-informed decision about, like, oh, maybe I should have stopped a little earlier or, like, yeah, it took about three hours, and that's okay. I think that would be an interesting area to incorporate and to be able to report more frequently. And I also like to know how other people spend their time, too. So, just, like, that sharing of information would also be really beneficial even to, like, a team. JOËL: What about the more aggressive documentation? Is that something that...because that can be really time-consuming, I imagine, as well. Is that something that you would value in a kind of, more focused full-time project context? STEPHANIE: Yeah. One part I've enjoyed about it is that I'm documenting, like, decision-making a lot more actively where, you know, I'm kind of, like, surfacing to be like, hey, here's the outcomes of, like, my research. We're not as, you know, embedded in the business, and we don't have as much of that, like, context and knowledge about what the best solutions are all the time. I'm documenting all of that, you know, usually, for the client stakeholder to be like, "Hey, here's my recommendations, like, how do you want to...what do you think is the best way to go? On one hand, it's kind of nice not to have to, like, be solely responsible for making that decision, right? And I'm kind of, like, leaning on, like, hey, like, you're the expert of your application and your product, you know, here's what I've learned. And now I've, like, put this all, like, for you and presented it to you. And I think that, for me, has gotten lost sometimes when I end up being the same person of, like, doing the research and then deciding, and it just kind of ends up being held in my head. And that, I think, is something really important to document, even if it's just for other people to, like, see how that process might work or, like, what things I already considered or didn't try. That exercise, I think, can be really important. So, so far, the documentation has not necessarily been, like, code level, but more, like, for each task, it's, like, showing your work, right? And not in a, like, you're being monitored [laughs] sort of way but in a way that supports it getting done with a lot of that turnover. JOËL: It's almost like a mini report that you're doing. So, you'd mentioned, for example, an application running into memory problems on Heroku. It sounds like you would then go maybe investigate that and then make some recommendations on whether they need to increase some dynos or maybe make some internal changes. It sounds like you may or may not be the one to execute those changes. But you would write up some, like, a mini report and submit that to the client, and then they can make their own execution choices. STEPHANIE: Yeah, exactly. And they can execute it themselves or then create a new ticket for the next person rotating on to support and maintenance to tackle it in a different cycle. JOËL: So, support and maintenance doesn't just do the investigation. Your team might do the execution as well. It's just that the sort of more research-y stuff and the execution stuff gets split out into different tickets because it's so tightly scoped. STEPHANIE: Yeah, that sounds right. JOËL: I like that. STEPHANIE: One area that I wasn't sure that I was going to like so much about this kind of work is, you know, when you're not kind of embedded on a team, I was thinking that I might not feel as connected, or I would miss a bit of that getting to know people and just, like, seeing people face to face on a daily basis. I'm still evaluating how that would go so far because it has definitely been, like, mostly asynchronous communication, you know, which is what works well for this type of the style of team or project. But I think what has been helpful is realizing that, like, oh yeah, like, I can also get that elsewhere, you know, with thoughtbot folks like with you doing this podcast every week. And right now, there are, like, two Boost members who are doing support and maintenance full time, and folks who are unbooked kind of come in and out. And I can see that there's still a team. So, it's not nearly as kind of, like, isolating as what I had thought it would be. JOËL: There's something that's really curious to me, I think, sitting at the intersection of the idea of fostering more team interactions and the sort of, like, mini reports that you write. And that's that I would love to see more sharing among all of us at thoughtbot about different interesting problems that we've had to solve or that we're tackling on different client work. Because I think in that case, it's a situation where we all just learn something, you know, maybe I've never had to deal with a memory leak or might not even have an idea of, like, how to approach memory issues on Heroku. So, seeing your little mini report, if you'd maybe share that, and, you know, maybe it can be anonymized in some way if needs to, I think would be really nice, at the very least, something that could be done, like, internally. So, I almost wonder if, like, building that practice of, you know, maybe not for every ticket that I do because, you know, I don't want to just be dumping my tickets in the thoughtbot Slack. But I run into something interesting and be like, oh, let me tell a little story about this and do a little write-up. That might be something that's good for the whole team and not just for folks who are on support and maintenance. STEPHANIE: Yeah, absolutely. As you were saying that, I was thinking about how it does kind of encourage me to find support outside of my, like, immediate team, right? Because I don't necessarily have one with the client and to, I don't know, I'm imagining, like, these roots growing in terms of different communities I'm a part of and bringing those problems just outside of my internal world, and kind of getting that outside feedback because by necessity a little bit, right? But also, with the added benefit of, you know, I think that's also how a lot of people end up writing content that gets shared with the world. So, I had the misconception that I would be kind of just, like, on my own off doing things like just tickets and being a little coding robot, but I've been surprised by it feels very fresh and new. So, I think, I guess, I was needing a little bit of that [laughs]. JOËL: I was having a conversation with another thoughtboter recently about how valuable sometimes change can be for its own sake and how that can sort of refresh. You want it just at the rate where you have a chance to build some stability. You don't want chaos. But sometimes change can sort of take you out of a rut, give you energy, maybe sort of restart some good habits that you had sort of let atrophy. And that finding, like, just that right level of shaking things up can really help a team, you know, get their effectiveness to the next level. STEPHANIE: Yeah. I like what you said about good habits, for sure. A couple of other random, little things that I just thought of about what I've liked is, I don't know, maybe this is a little silly. But we, you know, use shared credentials for logging into different services and applications or third parties that clients are using. And that has actually been something that has been so easy [laughs] and very low friction compared to, you know, joining a new project and manually be added as, like, your individual account to all of the different things. And things inevitably get forgotten, and then you have to rely on someone else to do it. And sometimes they don't get back to you [laughs] for a while. The self-serviceness of this work has been cool, too. And I just, yeah, wanted to say that I really appreciated the thought that went into making it as easy as possible to be like, yeah, I can find the credentials here. It is, you know, a bit more anonymized because I'm just using, like, a shared account. JOËL: Like a generic thoughtbot account on a client system rather than stephanie@thoughtbot. STEPHANIE: Yeah, exactly. But I think I saved so much time [laughs] this week just being able to do all of that myself and, you know, knowing where to look first before having to ask. JOËL: I guess you'd need something like that, right? If you're only jumping in on a project for the first time, for a couple of hours or something like that, you don't want to go through a whole onboarding process because that might then, like, easily double. You know, instead of doing two hours on this project, you're now doing four. STEPHANIE: Yeah, exactly. I guess the other takeaway, for me, was like, oh, definitely, if I were to have to set up accounts [laughs] for an application, you know, I've obviously seen where it was like, very clearly, like, the founder having created all these personal accounts for this services, and people are still using their credentials many years later [laughs], even though they probably, like, maybe may not even work for the company anymore. But yeah, the shared credentials and using that generic account that anyone can kind of get into when needed has really lowered the barrier to jump into doing that work, right? And especially because, like you said, it reduces that time. And we're, you know, billing by the hour anyway. So, it's kind of a win-win situation. JOËL: And I totally understand why you would not want something like that for a longer engagement. But for something like support and maintenance, it sounds like it was the right choice. STEPHANIE: Yeah, yeah. Again, I just mentioned it because it's just different. And so, maybe if this sparks any ideas for our listeners about how processes could be different or, like, the styles or ways of working can be different, I think that would be cool. JOËL: And just to be clear here, it sounds like what you're doing is for sort of each client; you create a separate set of credentials that are for that client but that are about thoughtbot generically. You don't have, like, one thoughtbot email and password that we reuse for every client. STEPHANIE: [laughs] Oh yes. That would be not so good [laughs] if we got hacked and suddenly, now they have access to everything. JOËL: So, every client gets its own unique email password combo. We're using security best practices here. And then, since you do have to share them through a team, are you doing some sort of, like, shared 1Password vault or something along those lines? STEPHANIE: Yeah, we are using a shared 1Password vault. That is definitely what I meant [laughs] the first time when I was mentioning the shared credentials, where that was basically the only thing I had to get onboarded to, the vault, for support and maintenance to be able to hit the ground running. JOËL: So, this sounds like a pretty exciting new style of project for you. Is this something that you would see yourself preferring to do longer term, to sort of focus on this style of project? Or do you think that you'd like to come back to more classic project work in the near future? STEPHANIE: I'm not sure yet, but I'm also hoping to have an answer to that question. And it definitely does feel like an experiment for me personally. I can see liking it, and that also fitting well with some of my longer-term goals of being able to, like, step back from work. Maybe working fewer days a week is something that I've, like, thought about in terms of, like, a long-term goal of mine because I'm not as needed [laughs] on a team. Which I think, in the past, I also had a bit of a misconception that, like, in order to be a good developer, I had to have all the domain knowledge, and be indispensable, and, like, be the go-to person to answer all the questions. But now I'm at a point where I don't want to [laughs] necessarily have to answer, like, every question because that creates, like, a dependency on me. And if I need to step away from work, then that could be tough, right? The vacation factor that you mentioned. So, this style of work is very interesting in terms of if it might provide me a little bit more of that, not exactly work-life balance, but just kind of be closer to my goals in terms of what I want out of work and my time. And, hopefully, I'm going to be doing this next week, but I don't know because that's the nature of it [laughs]. But if I am, then I'll definitely have more to say about it. Probably. JOËL: Well, it definitely sounds like we'll have to check in again on what's, I guess, not so new in your world on a future episode. On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

A platform as a service, or PaaS, is the concept of a complete development and deployment environment in the cloud. One of the best examples is Heroku, which was created in 2007 and later acquired by Salesforce. Although these services are great for helping startups get off the ground quickly, they can ultimately become a The post Flightcontrol and Going Beyond Heroku with Brandon Bayer appeared first on Software Engineering Daily.