Podcasts about staff software engineer

In this episode, we dive into a topic that many teams only start paying attention to when it's already too late: Garbage Collection in Java microservices. And we do so together with Usama Nasir, Staff Software Engineer at GetYourGuide.While you might think Kubernetes solves everything, Usama shares how his team at GetYourGuide was still caught off guard by mysterious Out of Memory errors. The culprit? Microservices may be small, but that doesn't mean Java's memory management just takes care of itself.We talk about how Java's memory model really works, why different garbage collectors (like G1GC or ZGC) perform completely differently under pressure, and how small decisions can have a big impact on performance. Usama explains how observability with tools like Datadog turned out to be essential, and why sometimes it's actually smarter to allocate less memory to your containers.But the most important takeaway? Garbage Collection isn't just “a Java thing.” It's a shared responsibility between developers and DevOps/SREs. Only together can you find that sweet spot between speed, stability, and scalability.-----------In deze aflevering duiken we samen met Usama Nasir, Staff Software Engineer bij GetYourGuide, in een onderwerp dat in veel teams pas aandacht krijgt als het al te laat is: Garbage Collection in Java microservices.Hoewel je misschien denkt dat Kubernetes alles oplost, vertelt Usama hoe zijn team bij GetYourGuide tóch werd verrast door mysterieuze Out of Memory-errors. Wat bleek? Microservices mogen dan klein zijn, maar dat betekent niet dat Java's geheugenhuishouding vanzelf goed gaat.We praten over hoe Java's memory model echt werkt, waarom verschillende garbage collectors (zoals G1GC of ZGC) totaal anders presteren onder druk, en hoe kleine keuzes grote impact hebben op performance. Usama legt uit hoe observability met tools als Datadog onmisbaar bleek, en waarom het soms slimmer is om minder geheugen toe te kennen aan je containers.Maar het belangrijkste inzicht? Garbage Collection is geen “Java-dingetje”. Het is een verantwoordelijkheid van zowel developers als DevOps/SRE's. Alleen samen vind je die sweet spot tussen snelheid, stabiliteit en schaalbaarheid.Stuur ons een bericht.https://acc-ict.com/liveSupport the showLike and subscribe! It helps out a lot.You can also find us on:De Nederlandse Kubernetes Podcast - YouTubeNederlandse Kubernetes Podcast (@k8spodcast.nl) | TikTokDe Nederlandse Kubernetes PodcastWhere can you meet us:EventsThis Podcast is powered by:ACC ICT - IT-Continuïteit voor Bedrijfskritische Applicaties | ACC ICT

Kalifornská firma SentinelOne stojí za platformou, která si klade za cíl kompletně zajistit firemní kybernetickou bezpečnost. Spoléhá z velké části na vlastní umělou inteligenci Purple AI a používají ji tři z deseti největších firem světa

Hoje o papo é sobre evolução. Neste episódio, conversamos com o famoso VGO do Nubank sobre as mudanças pelas quais a empresa passou desde o primeiro episódio do podcast, incluindo a evolução do próprio mercado e das tecnologia que o toca — incluindo IA, é claro. Vem ver quem participou desse papo: André David, o host que o Soutinho não enganou Fabrício Carraro, Program Manager da Alura, autor de IA e host dos podcast Dev Sem Fronteiras e IA Sob Controle Mário Souto, o Dev Soutinho, Staff Software Engineer no Nubank Paulo Silveira, Chief Vision Officer do ecossistema Alura, FIAP e PM3 Vitor “VGO” Olivier, CTO do Nubank

Based in Los Angeles, Dave has dedicated his career to solving complex technical challenges across various domains. His professional journey includes roles as Principal Software Architect at PKWARE, Senior Backend Engineer at Fetch Rewards, and Staff Software Engineer at Bold Penguin, where he consistently designed high-performance, scalable systems.Dave's current passion project, Contextium, represents the culmination of his technical expertise and intellectual interests. This system transforms natural language into deep semantic graphs -- and vice versa -- through innovative knowledge representation techniques. Contextium employs a symbolic, rules-based approach to NLP rather than relying solely on statistical methods, allowing for precise semantic understanding and addressing critical limitations in current AI systems, for example hallucinations in large language models.A published author with O'Reilly Media, Dave wrote 'Programming Visual Basic .NET' (2001) and 'CDO & MAPI Programming with Visual Basic' (2000), demonstrating his ability to communicate complex technical concepts clearly.Over his long career, Dave has worked in many languages and tech stacks. His interests extend beyond pure engineering to theoretical aspects of AI, consciousness, and the intersection of symbolic and neural approaches to machine intelligence.You can find Dave on the following sites:LinkedInPLEASE SUBSCRIBE TO THE PODCASTSpotifyApple PodcastsYouTube MusicAmazon MusicRSS FeedYou can check out more episodes of Coffee and Open Source on https://www.coffeeandopensource.comCoffee and Open Source is hosted by Isaac Levin

In this episode, Dipendra Kumar, Staff Research Scientist, and Alnur Ali, Staff Software Engineer at Databricks, discuss the challenges of applying AI in enterprise environments and the tools being developed to bridge the gap between research and real-world deployment.Highlights include:- The challenges of real-world AI—messy data, security, and scalability.- Why enterprises need high-accuracy, fine-tuned models over generic AI APIs.- How QuickFix learns from user edits to improve AI-driven coding assistance.- The collaboration between research & engineering in building AI-powered tools.- The evolving role of developers in the age of generative AI.

Mercedes Bernard, Staff Software Engineer at Kit, joins Robby to talk about what it really means to write code that lasts—and who it should be written for.In this episode of Maintainable, Mercedes shares a thoughtful and practical perspective on working with legacy codebases, managing technical debt, and creating a team culture that values maintainability without fear or shame. Her guiding principle? Well-maintained software is friendly software—code that is understandable and approachable, especially for early-career developers.Together, they discuss how to audit and stabilize older systems, avoid full rewrites, and create consistent developer experiences in large applications. Mercedes reflects on her decade in consulting and how that shaped her approach to navigating incomplete documentation, missing historical context, and multiple competing patterns in a codebase. She breaks down different types of technical debt, explains why not all of it is inherently bad, and offers strategies for advocating for maintenance work across engineering and product teams.The conversation also touches on architecture patterns like job fan-out, measuring performance regressions, reducing infrastructure load, and building momentum for improvements even when leadership isn't actively prioritizing them.If you've ever felt overwhelmed by a messy project or struggled to justify maintenance work, this episode will leave you with a fresh mindset—and a few practical tactics—for making code more sustainable and inclusive.Episode Highlights[00:01:08] Defining Well-Maintained SoftwareMercedes explains her top metric: software that feels friendly, especially to early-career developers navigating the codebase for the first time.[00:03:00] What Friendly Code Actually Looks LikeShe shares why consistency, discoverability, and light documentation (like class comments or UML snippets) can make a huge difference.[00:05:00] Assessing Code Like a House TourMercedes introduces her metaphor of giving a house tour to evaluate code: does everything feel like it's in the right place—or is the stove in the cabinet?[00:06:53] Consulting Mindset: Being a Guest in the CodebaseWith a decade of consulting experience, Mercedes shares how she navigates legacy systems when historical context is long gone.[00:10:40] Stabilizing a Startup's Tangled ArchitectureShe walks through an in-depth case study where she helped a client with multiple abandoned services get back to stability—without a rewrite.[00:17:00] The Power of a One-Line FixMercedes shares how a missing check caused a job to fan out 30 million no-op background jobs a day—and how one line of code reduced that by 75%.[00:23:40] Why State Checks Belong EverywhereShe explains how defense-in-depth patterns help avoid job queue flooding and protect system resources early in the fan-out process.[00:24:59] Reframing Technical DebtNot all debt is bad. Mercedes outlines three types—intentional, evolutionary, and time-based—and how to approach each one differently.[00:28:00] Why Teams Fall Behind Without Realizing ItMercedes and Robby talk about communication gaps between engineers and product stakeholders—and why it's not always clear when tech debt starts piling up.[00:34:00] Quantifying Developer FrictionMercedes recommends expressing technical debt in terms of lost time, slow features, and increased cost rather than vague frustrations.[00:42:00] Getting Momentum Without PermissionHer advice to individual contributors: start small. Break down your frustrations into bite-sized RFCs or tickets and show the impact.[00:45:40] Letting the Team Drive StandardsMercedes encourages team-led conventions over top-down declarations, and explains why having any decision is better than indecision.[00:47:54] Recommended ReadingShe shares a surprising favorite: The Secret Life of Groceries, a systems-thinking deep dive into the grocery industry by Benjamin Lorr.Resources & Links

No episódio 99 do podcast OsProgramadores, conversamos com André Albino, Staff Software Engineer na HashiCorp, empresa referência em infraestrutura como código, automação e segurança na nuvem.Neste papo, André compartilhou sua trajetória profissional, os bastidores do trabalho com ferramentas como Terraform, além de dicas valiosas para quem deseja seguir carreira na área..Se você se interessa por infraestrutura moderna, boas práticas de automação e como grandes empresas estão lidando com desafios de escala, esse episódio é pra você!

How you learn is important. Corey Quinn is joined by Aditya Bhargava, a Staff Software Engineer at Etsy and the author of Grokking Algorithms. They talk about the nuances of technical learning and the contrasting philosophies of "just in time" versus "just in case" learning. In this episode, Aditya emphasizes the importance of effective teaching methods and the value of incorporating fun things like drawings into technical explanations. This approach also bleeds into his illustrated Substack, DuckTypes. As Corey and Aditya discuss, a good, informative book doesn't need to drag on, and this quick, insightful, 30-minute conversation is no different.Show Highlights(0:00) Intro(1:24) The Duckbill Group sponsor read(1:58) Corey's admiration for Aditya's writing(5:40) How Aditya clearly explains AWS networking(8:06) “Just in case” vs. “just in time”(10:15) Why business books don't need to be hundreds of pages long(14:19) Reading for pleasure vs. reading for work(16:57) The Duckbill Group sponsor read(17:24) Explaining Aditya's book on algorithms(20:07) The great editor behind Aditya's book(22:20) DuckTyped and how Aditya got into AWS networking(25:16) Where networking folks fall in the era of the cloud(28:12) The importance of staying up-to-date in your field(31:46) Where you can find more from AdityaAbout Aditya BhargavaAditya Bhargava is a Software Engineer with a dual background in Computer Science and Fine Arts. He blogs on programming at adit.io.LinksAditya's blog: https://www.adit.io/Grokking Algorithms, Second Edition: https://www.manning.com/books/grokking-algorithms-second-editionDuckTyped: https://www.ducktyped.org/Last Skeet in AWS: https://lastskeetinaws.com/SponsorThe Duckbill Group: duckbillgroup.com 

Stats On Stats NotesIn this episode of Stats on Stats, we welcome William Hill, a Staff Software Engineer at Maroxa, for an insightful conversation on AI, software engineering, and the evolving tech landscape. William shares his journey from a small town in Mississippi to becoming a leader in data engineering, discussing how gaming sparked his interest in tech and how AI is reshaping the industry.Guest ConnectLinkedIn: https://www.linkedin.com/in/whill3/ Stats on Stats ResourcesMerch: https://www.statsonstats.io/shop LinkTree: https://linktr.ee/statsonstatspodcast Stats on Stats Partners & AffiliatesIntelliCON 2025Website: https://www.intelliguards.com/intellic0n-speakers Register: https://www.eventbrite.com/e/intellic0n-2025-tickets-1002600072807 Use Discount Code for 20% off Tickets: STATSONSTATSPath AIWebsite: https://yourpath.ai Discount Code: Join our Discord community for access!Antisyphon TrainingWebsite: https://www.antisyphontraining.com MAD20 TrainingWebsite: https://mad20.io Discount Code: STATSONSTATS15Ellington Cyber Academy: https://kenneth-ellington.mykajabi.com Discount Code: STATSONSTATSKevtech AcademyWebsite: https://www.kevtechitsupport.com Dream Chaser's Coffee Website: https://dreamchaserscoffee.com Discount code: STATSONSTATSPodcasts We LikeDEM Tech FolksWebsite: https://linktr.ee/developeverymind YouTube: https://www.youtube.com/@demtechfolks IntrusionsInDepthWebsite: https://www.intrusionsindepth.com YouTube: https://www.youtube.com/@IntrusionsInDepth  Elastic DoD ArchitectsYouTube: https://www.youtube.com/@elasticdod -----------------------------------------------------Episode was shot and edited at BlueBox Studio Tampahttps://blueboxdigital.com/bluebox-studio/

The Daily Gwei Refuel gives you a recap every week day on everything that happened in the Ethereum and crypto ecosystems over the previous 24 hours - hosted by Anthony Sassano. Timestamps and links to topics discussed: https://daily-gwei-links.vercel.app/recent 00:00 Introductory song 00:10 Ethereum Strategic Reserve https://x.com/sassal0x/status/1884193626642866318 08:00 Geth looking for a Staff Software Engineer https://x.com/lightclients/status/1884256102000599175 13:08 New Stateless Consensus twitter account https://x.com/StatelessEth/status/1883860876618543295 15:26 Ethproofs.org now live https://x.com/eth_proofs/status/1883907113220739102 17:47 Validator education https://x.com/squadstaking/status/1883848541480841544 19:47 'Powered by Ethereum' branding update https://x.com/sassal0x/status/1884022562604343645 21:30 ETH Strategy explained https://x.com/Ceazor7/status/1884387256720585191 24:38 All about blobs https://dune.com/hildobby/blobs 29:23 Abstract mainnet now live https://x.com/AbstractChain/status/1883939915169423777 This episode is also available on YouTube: https://youtu.be/gluL6a-TanQ Subscribe to the newsletter: https://thedailygwei.substack.com/ Subscribe on YouTube: https://www.youtube.com/channel/UCvCp6vKY5jDr87htKH6hgDA/ Follow Anthony on Twitter: https://twitter.com/sassal0x Follow The Daily Gwei on Twitter: https://twitter.com/thedailygwei Join the Discord Channel: https://discord.gg/4pfUJsENcg DISCLAIMER: All information presented across all of The Daily Gwei's communication channels is strictly for educational purposes and should not be taken as investment advice.

Machine Learning, AI Agents, and Autonomy // MLOps Podcast #283 with Zach Wallace, Staff Software Engineer at Nearpod Inc. // Abstract Demetrios chats with Zach Wallace, engineering manager at Nearpod, about integrating AI agents in e-commerce and edtech. They discuss using agents for personalized user targeting, adapting AI models with real-time data, and ensuring efficiency through clear task definitions. Zach shares how Nearpod streamlined data integration with tools like Redshift and DBT, enabling real-time updates. The conversation covers challenges like maintaining AI in production, handling high-quality data, and meeting regulatory standards. Zach also highlights the cost-efficiency framework for deploying and decommissioning agents and the transformative potential of LLMs in education. // Bio Software Engineer with 10 years of experience. Started my career as an Application Engineer, but I have transformed into a Platform Engineer. As a Platform Engineer, I have handled the problems described below - Localization across 6-7 different languages - Building a custom local environment tool for our engineers - Building a Data Platform - Building standards and interfaces for Agentic AI within ed-tech. // MLOps Swag/Merch https://shop.mlops.community/ // Related Links https://medium.com/renaissance-learning-r-d/data-platform-transform-a-data-monolith-9d5290a552ef --------------- ✌️Connect With Us ✌️ ------------- Join our slack community: https://go.mlops.community/slack Follow us on Twitter: @mlopscommunity Sign up for the next meetup: https://go.mlops.community/register Catch all episodes, blogs, newsletters, and more: https://mlops.community/ Connect with Demetrios on LinkedIn: https://www.linkedin.com/in/dpbrinkm/ Connect with Zach on LinkedIn: https://www.linkedin.com/in/zachary-wallace/

Primeira terça-feira do mês é dia de falar sobre carreira! No segundo episódio da série especial do podcast, conversamos com Mano Deyvin sobre a expectativa versus realidade do começo e da evolução da carreira da pessoa dev. Vem ver quem participou desse papo: Paulo Silveira, o host que conhece um pouco do CSS raiz André David, o co-host que não é contra testes Mário Souto, o Dev Soutinho, Staff Software Engineer no Nubank Mano Deyvin, rei do chorume da bolha tech (YouTube)

Neste episódio do *Elixir em Foco*, Adolfo Neto e Zoey Pessanha conversaram com David Alencar, Staff Software Engineer na Trio Pagamentos. Com mais de 15 anos de experiência em tecnologia, incluindo uma passagem pela Microsoft, David compartilhou sua transição para o mundo open source e sua paixão por Elixir, que ele utiliza amplamente na Trio para soluções financeiras em produção. Ele destacou os desafios e aprendizados em ambientes de alta escala, além das bibliotecas e frameworks que a empresa utiliza para manter a eficiência e a qualidade dos sistemas. David também falou sobre sua motivação para criar conteúdo educacional no YouTube, em português e inglês, como forma de contribuir com a comunidade Elixir. No bloco final, comentou sobre sua participação no evento Elixir Curitiba 2024, organizado na sede da Trio, e mostrou entusiasmo com a possibilidade de uma edição em 2025. David Alencar (Linkedin): https://www.linkedin.com/in/davidalencar/ Canal no YouTube: https://www.youtube.com/@odavidalencar/  Elly Academy https://www.youtube.com/c/ELLYACADEMY/  https://www.instagram.com/elly.academy/  Rede Emílias de Podcasts no Bluesky - https://bsky.app/profile/redeemilias.bsky.social  Rede Emílias de Podcasts no Mastodon - https://bertha.social/@redeemilias  Elixir em Foco no YouTube - https://www.youtube.com/@elixiremfoco  Elixir em Foco no Spotify - https://open.spotify.com/show/43aDX4kajkNCKaCYpGPooJ  Elixir em Foco no Spotify for Podcasters - https://podcasters.spotify.com/pod/show/elixiremfoco  Elixir em Foco na Apple Podcasts - https://podcasts.apple.com/us/podcast/elixir-em-foco/id1560944119  Associe-se à Erlang Ecosystem Foundation - https://bit.ly/3Sl8XTO  Site da Erlang Ecosystem Foundation - https://bit.ly/3Jma95g  Nosso site - https://elixiremfoco.com  Estamos no X (@elixiremfoco) - https://x.com/elixiremfoco  Nosso email - elixiremfoco@gmail.com

Goran Petrovic, a Staff Software Engineer at Google, speaks with host Gregory M. Kapfhammer about how to perform mutation testing on large software systems. They explore the design and implementation of the mutation testing infrastructure at Google, discussing the strategies for ensuring that it enhances both developer productivity and software quality. They also investigate the findings from experiments that quantify how mutation testing enables software engineers at Google to write better tests that can detect defects and increase confidence in software correctness. Brought to you by IEEE Computer Society and IEEE Software magazine.

On this episode, we explore how Kong, a cloud-native API gateway, leverages Apache Druid for real-time data processing and analytics in their platform, Kong Konnect. Hiroshi Fukada, Staff Software Engineer at Kong, shares his insights on managing customer data through Kong Gateway and transitioning to Imply's managed Druid services to simplify their infrastructure. Discover the benefits of Druid, like low latency and ease of use, and learn about Kong's contributions to open source Druid, including the DDSketch extension for improved handling of long-tail distributions. Want to learn more about Druid and meet the community behind it? Registration for Druid Summit is now open! Register at https://druidsummit.org/

Hey Angular enthusiasts!

Stack Overflow is a legendary question-and-answer site for programmers, and is likely well known to most SEDaily listeners. Svelte is an open-source front-end framework that was released in 2016 and continues to grow rapidly in popularity. Giamir Buoncristiani is a Staff Software Engineer at Stack Overflow. He is also the tech lead for the Stacks The post Why Stack Overflow Uses Svelte with Giamir Buoncristiani appeared first on Software Engineering Daily.

Stack Overflow is a legendary question-and-answer site for programmers, and is likely well known to most SEDaily listeners. Svelte is an open-source front-end framework that was released in 2016 and continues to grow rapidly in popularity. Giamir Buoncristiani is a Staff Software Engineer at Stack Overflow. He is also the tech lead for the Stacks The post Why Stack Overflow Uses Svelte with Giamir Buoncristiani appeared first on Software Engineering Daily.

Aravind was a Staff Software Engineer at Uber, and currently works at OpenAI.Apple Podcasts | Spotify | Google PodcastsEdited TranscriptCan you tell us about the scale of data Uber was dealing with when you joined in 2018, and how it evolved?When I joined Uber in mid-2018, we were handling a few petabytes of data. The company was going through a significant scaling journey, both in terms of launching in new cities and the corresponding increase in data volume. By the time I left, our data had grown to over an exabyte. To put it in perspective, the amount of data grew by a factor of about 20 in just a three to four-year period.Currently, Uber ingests roughly a petabyte of data daily. This includes some replication, but it's still an enormous amount. About 60-70% of this is raw data, coming directly from online systems or message buses. The rest is derived data sets and model data sets built on top of the raw data.That's an incredible amount of data. What kinds of insights and decisions does this enable for Uber?This scale of data enables a wide range of complex analytics and data-driven decisions. For instance, we can analyze how many concurrent trips we're handling throughout the year globally. This is crucial for determining how many workers and CPUs we need running at any given time to serve trips worldwide.We can also identify trends like the fastest growing cities or seasonal patterns in traffic. The vast amount of historical data allows us to make more accurate predictions and spot long-term trends that might not be visible in shorter time frames.Another key use is identifying anomalous user patterns. For example, we can detect potentially fraudulent activities like a single user account logging in from multiple locations across the globe. We can also analyze user behavior patterns, such as which cities have higher rates of trip cancellations compared to completed trips.These insights don't just inform day-to-day operations; they can lead to key product decisions. For instance, by plotting heat maps of trip coordinates over a year, we could see overlapping patterns that eventually led to the concept of Uber Pool.How does Uber manage real-time versus batch data processing, and what are the trade-offs?We use both offline (batch) and online (real-time) data processing systems, each optimized for different use cases. For real-time analytics, we use tools like Apache Pinot. These systems are optimized for low latency and quick response times, which is crucial for certain applications.For example, our restaurant manager system uses Pinot to provide near-real-time insights. Data flows from the serving stack to Kafka, then to Pinot, where it can be queried quickly. This allows for rapid decision-making based on very recent data.On the other hand, our offline flow uses the Hadoop stack for batch processing. This is where we store and process the bulk of our historical data. It's optimized for throughput – processing large amounts of data over time.The trade-off is that real-time systems are generally 10 to 100 times more expensive than batch systems. They require careful tuning of indexes and partitioning to work efficiently. However, they enable us to answer queries in milliseconds or seconds, whereas batch jobs might take minutes or hours.The choice between batch and real-time depends on the specific use case. We always ask ourselves: Does this really need to be real-time, or can it be done in batch? The answer to this question goes a long way in deciding which approach to use and in building maintainable systems.What challenges come with maintaining such large-scale data systems, especially as they mature?As data systems mature, we face a range of challenges beyond just handling the growing volume of data. One major challenge is the need for additional tools and systems to manage the complexity.For instance, we needed to build tools for data discovery. When you have thousands of tables and hundreds of users, you need a way for people to find the right data for their needs. We built a tool called Data Book at Uber to solve this problem.Governance and compliance are also huge challenges. When you're dealing with sensitive customer data, you need robust systems to enforce data retention policies and handle data deletion requests. This is particularly challenging in a distributed system where data might be replicated across multiple tables and derived data sets.We built an in-house lineage system to track which workloads derive from what data. This is crucial for tasks like deleting specific data across the entire system. It's not just about deleting from one table – you need to track down and update all derived data sets as well.Data deletion itself is a complex process. Because most files in the batch world are kept immutable for efficiency, deleting data often means rewriting entire files. We have to batch these operations and perform them carefully to maintain system performance.Cost optimization is an ongoing challenge. We're constantly looking for ways to make our systems more efficient, whether that's by optimizing our storage formats, improving our query performance, or finding better ways to manage our compute resources.How do you see the future of data infrastructure evolving, especially with recent AI advancements?The rise of AI and particularly generative AI is opening up new dimensions in data infrastructure. One area we're seeing a lot of activity in is vector databases and semantic search capabilities. Traditional keyword-based search is being supplemented or replaced by embedding-based semantic search, which requires new types of databases and indexing strategies.We're also seeing increased demand for real-time processing. As AI models become more integrated into production systems, there's a need to handle more GPUs in the serving flow, which presents its own set of challenges.Another interesting trend is the convergence of traditional data analytics with AI workloads. We're starting to see use cases where people want to perform complex queries that involve both structured data analytics and AI model inference.Overall, I think we're moving towards more integrated, real-time, and AI-aware data infrastructure. The challenge will be balancing the need for advanced capabilities with concerns around cost, efficiency, and maintainability. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.softwareatscale.dev

We talk with Nikhita Raghunath, Nabarun Pal, and Paco Xu. Nikhita, Nabarun, and Paco have each held various leadership positions related to the Kubernetes project. They talk about their journeys, the various leadership roles they've been in, and offer advice for new contributors and those who want to move into leadership in the project.   Nikhita is a Staff Software Engineer at Broadcom. She is currently a member of the CNCF Technical Oversight Committee (TOC) overseeing all technical matters of the CNCF. In the past, she was a member of the Kubernetes Steering Committee, a technical lead for SIG Contributor Experience and has also won the CNCF Top Committer Award. Currently, she is also a co-chair of the KubeCon+CloudNativeCon conference. Nabarun is a Staff Software Engineer at Broadcom, a maintainer of the Kubernetes project, a member of the Kubernetes Steering Committee and a chair of Kubernetes SIG Contributor Experience. In the past, he was the release lead for Kubernetes 1.21 and has served eight release teams. Nabarun also works actively with the Python community by organizing PyCon India and has been recognized in media publications for his work. Paco is an open source team lead in DaoCloud. He started to work on container/docker in 2016 and later started to participate in the Kubernetes Community in 2018. He is a current member of Kubernetes Steering Committee and works mainly on kubeadm and sig-node. He is Co-chair of KubeCon+CloudNativeCon China 2024.   Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod   News of the week Blog: 10 Years of Kubernetes CNCF-Hosted Co-Located Events Overview CFP for CNCF-hosted Co-located Events Kubernetes Community Days Links from the interviews CNCF Technical Oversight Committee SIG ContribEx Google Summer of Code CNCF Top Committer Award 2021 - Nikhita Raghunath Blog Post: Google Summer of Code with Kubernetes by Nikhita Raghunath Kubernetes Docs: Extend the Kubernetes API with CustomResourceDefinitions SIG API Machinery SIG Testing SIG Release CNCF Chop Wood Carry Water Award 2018 - Nikhita Raghunath Kubernetes Steering Committee KubeCon India KubeCon NA Kubernetes 1.21: Power to the Community Pycon India Kubernetes Python Client on GitHub Kubernetes Contributor Summit 2019 YouTube Playlist Kubernetes Release Team KubeCon NA 2024 Scholarships (applications due by September 1, 2024) Kubeadm SIG Node KubeCon China 2024 Kubelet Kubernetes Production Readiness Review Process Kubernetes Release Team CI Signal Lead Runbook  

Relationships with stakeholders can make or break your job.Not to mention your promotion.Nick Cosentino, a Principal Software Engineering Manager at Microsoft breaks down how to do it well — whether the stakeholder is a Staff Software Engineer or they don't know the difference between Java and JavaScript. (the names are confusing, I hear ya)Additionally, we talk about how to debug well (and frame it better during standups when you're stuck), feel better about giving people feedback, and how to start getting better at it all starting tomorrow.   Working well with others is a skill that can be learned. Tune in as we dive into how we can improve at work, especially as software engineers.✨ Connect with Nick below!His newsletter: https://www.devleader.ca/newsletter/His YouTube: https://www.youtube.com/@devleaderHis LinkedIn: https://www.linkedin.com/in/nickcosentinoSend me a message!Thanks for listening! And for checking out these show notes

In this episode of Maintainable, Robby chats with Stig Brautaset, Staff Software Engineer at CircleCI. Stig shares his insights on maintaining well-documented but complex legacy code, the impact of team dynamics on software maintenance, and his experiences with the SBJSON library.Stig discusses the characteristics of well-maintained software, emphasizing the importance of team experience, domain knowledge, and risk appetite. He reflects on his own career journey, highlighting the transition from overconfidence to a balanced approach to risk-taking.A significant portion of the conversation delves into Stig's concept of "Alien Artifacts," which describes highly resistant legacy code written by highly skilled engineers. He explains the challenges of modifying such code and shares examples from his own experiences.Stig also talks about his work on the SBJSON library, addressing the complexities of handling multiple versions and dependency conflicts. He advocates for developers maintaining the software they ship and discusses the balance between shipping features quickly and maintaining long-term code quality.Key TakeawaysThe influence of team dynamics on software maintenanceUnderstanding the concept of "Alien Artifacts" in legacy codeStrategies for handling multiple versions of a software libraryThe importance of developers being on call for the software they shipManaging different types of technical debtBook Recommendation:The Scout Mindset by Julia GalefStig Brautaset on LinkedInAlien Artifacts Blog PostSBJSON Library CircleCIThe Confident Commit PodcastHelpful Links:Stig Brautaset on LinkedInAlien Artifacts Blog PostSBJSON Library CircleCIThe Confident Commit PodcastWant to share your thoughts on this episode? Reach out to Robby at robby@maintainable.fm.Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Valkey, a Redis fork supported by the Linux Foundation, challenges Redis' new license. In this episode, Madelyn Olson, a lead contributor to the Valkey project and former Redis core contributor, along with Ping Xie, Staff Software Engineer at Google and Dmitry Polyakovsky, Consulting Member of Technical Staff at Oracle highlights concerns about the shift to a more restrictive license at Open Source Summit 2024 in Seattle. Despite Redis' free license for end users, many contributors may not support it. Valkey, with significant industry backing, prioritizes continuity and a smooth transition for Redis users. AWS, along with Google and Oracle maintainers, emphasizes the importance of open, permissive licenses for large tech companies. Valkey plans incremental updates and module development in Rust to enhance functionality and attract more engineers. The focus remains on compatibility, continuity, and consolidating client behaviors for a robust ecosystem.  Learn more from The New Stack about the Valkey Project and changes to Open Source licensingLinux Foundation Backs 'Valkey' Open Source Fork of Redis Redis Pulls Back on Open Source Licensing, Citing Stingy Cloud ServicesHashiCorp's Licensing Change is only the Latest Challenge to Open Source Join our community of newsletter subscribers to stay on top of the news and at the top of your game.  

In this episode, JB is joined by Diontre Pate, a Staff Software Engineer for Prove and Founder of a tech startup and development agency. Diontre and JB talked about shining the light of Christ in dark places, balancing load plates of responsibilities, and how one can make an impact within the world around us through human connection. Enter to Win a 3-Day Camper Ticket to THAT Conference WI 2024 - https://kingsumo.com/g/xyqpkq/that-conference-3-day-ticket-giveaway Connect Diontre via LinkedIn - https://dub.sh/jo3qjla Passing of the Bread: Next.js - https://nextjs.org/ (Diontre's Breadcrumb) Nuxt.js - https://nuxt.com/ (JB's Breadcrumb) You are invited to join us over at the codeFellowship( ) Community - https://discord.gg/eK97ZnECPk Follow us on Social Media: X - https://x.com/code_fellowship LinkedIn - https://www.linkedin.com/company/codefellowship/ Other ways to consume the podcast: Spotify - https://podcasters.spotify.com/pod/show/codefellowship Apple Podcasts - https://podcasts.apple.com/us/podcast/codefellowship/id1609574437 Thanks for Listening. God Bless! --- Support this podcast: https://podcasters.spotify.com/pod/show/codefellowship/support

Ian and Aaron are joined by Adam Wathan (our first returning guest!) to talk about Aaron's future plans for courses & consulting, Adam's plans for hiring at Tailwind, & a lot more.Sponsored by Laracasts, LaraJobs, & Screencasting.com.Send questions or feedback to mostlytechnicalpodcast@gmail.com.(00:00) - The Interloper (01:49) - Hiring at Tailwind (09:00) - Extra Effort Matters (19:47) - Magic Company Money (23:02) - Jerry Seinfeld's Voice (27:45) - Nothing Sexier Than a Database (43:49) - Taste as a Service (54:34) - Courses vs. Consulting (01:07:56) - The Aaron Francis Experience (01:13:33) - The Master Plan (01:28:53) - Price of Admission (01:33:17) - En Route To Mars Links:Subscribe to Laracasts! Seriously.Adam's tweets announcing the Design Engineer & Staff Software Engineer jobs at TailwindAdam's tweet about 90% of applicants not following instructionsTest Driven LaravelSandwich VideoKevin Shen's Dream Studio Course on lightingJonathan Reinink on Twitter

Metrics are hard. Identifying which metrics to measure is even harder. So how do you get started? And how do you know when you have achieved true developer productivity zen? Like anything in life the path to mastery is a journey and today we are joined by a passionate staff engineer from Meta to share with us his theory on a developer productivity maturity model which paints a wonderful mental picture on knowing where we stand in our developer productivity journey and how companies can move through the stages. We also discuss productivity dashboards, if you actually need dashboards, how Meta thinks about developer productivity and more. Our guest, Karim Nakad, has his Masters of Computer Science from University of Wisconsin and previously worked for Amazon for SageMaker and Prime. He is currently a Staff Software Engineer at Meta making an impact in the productivity organization. He is dedicated to improving developer efficiency across the board and paving the way by generating and exposing productivity and code quality metrics across the tech industry and alongside leading experts and researchers. His excitement around improving the daily working lives of software engineers is palatable and contagious and I can't wait to dig in. I met our guest at a developer productivity engineering conference last year and when he summarized back to me the purpose of a project I was working on in such an eloquent manner I knew then he had to come on the podcast to share his thoughts and efforts around bringing happiness to engineers and building products for people. When our guest is not helping engineers move fast and be productive, he games and travels the world. He also two Macaws a green wing and a blue and gold. Enjoy! Connect with Karim: LinkedIn Twitter Threads Sponsor: Get Space: Do you know what pain points exist in your company? Install Get Space's real-time survey iteration tool now with code "buildwithpeople" and get 20% off your first year Episode correction: Karim wanted to clarify the difference and intersection between qualitative/quantitative and objective/subjective: Qualitative: Non-number data such as the subjective free-form text in surveys. Quantitative: Data that can be counted, such as subjective multiple-choice in surveys or objective system measurements. Show notes and helpful resources: DORA The SPACE framework Karim's best advice: “Anyone can be an expert you just need to read the code” Karim's everyday tool: Obsidian - note taking app Reflect note taking app The Hack language Karim says developer productivity is about creating an efficient and enjoyable experience as that is what encourages devs to do their best work To measure, rely on frameworks our there like DORA or SPACE and Karim recommends using metrics you already have to start with AutoFocus paper: Workgraph: personal focus vs. interruption for engineers at Meta - improved personal focus by over 20% KPIs rule of thumb takes two forms: Latency and Reliability An example of latency is test latency and how quickly do they complete An example of reliability is test reliability and how often your test delivers good signal Productivity Engineering Maturity Model (5 stages): Ignorance: Not know about or not prioritizing developer productivity Awareness: Forming a team focused on addressing highest pain points for example around continuous integration or testing Initiation: Merging KPIs into a common productivity goal and creating dashboards Refinement: Making recommendations on dashboards to improve productivity Mastery: Automating and integrating productivity improvements into workflows Advice for smaller companies: Keep an ear on the ground for industry research from companies like Google and Microsoft, and leverage frameworks like SPACE and DevEx to measure and improve productivity. The importance of nudging teams in the right direction rather than mandating productivity solutions, allowing teams to find their own paths to improvement. Building something cool or solving interesting problems? Want to be on this show? Send me an email at jointhepodcast@unfilteredbuild.com Podcast produced by Unfiltered Build - dream.design.develop.

Michael is joined by Chelsea Dole, Staff Software Engineer and Tech Lead of the Data Storage Team at Brex, to discuss bloat. They cover what it is, why it's a problem, strategies for minimising it, and the options when it's really bad. Here are some links to things they mentioned:Managing your tuple graveyard (talk by Chelsea) https://www.youtube.com/watch?v=gAgbzvGT6ckpgstattuple https://www.postgresql.org/docs/current/pgstattuple.html pg_class https://www.postgresql.org/docs/current/catalog-pg-class.html Bloat in PostgreSQL: a taxonomy (talk by Peter Geoghegan) https://youtube.com/watch?v=JDG4bMHxCH8 It's Not You, It's Me: Breaking Up with Massive Tables via Partitioning (talk by Chelsea) https://youtube.com/watch?v=TafwSuLNxe8 pg_repack https://github.com/reorg/pg_repackpg_squeeze https://github.com/cybertec-postgresql/pg_squeeze VACUUM https://www.postgresql.org/docs/current/sql-vacuum.htmlautovacuum https://www.postgresql.org/docs/current/runtime-config-autovacuum.html CLUSTER https://www.postgresql.org/docs/current/sql-cluster.html HOT updates https://www.postgresql.org/docs/current/storage-hot.html Our episode on BUFFERS https://postgres.fm/episodes/buffers-by-default Our episode on TOAST https://postgres.fm/episodes/toast Our episode on index maintenance https://postgres.fm/episodes/index-maintenance Chelsea's website: https://chelseadole.com/~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Michael Christofides, founder of pgMustardNikolay Samokhvalov, founder of Postgres.aiWith special thanks to:Jessie Draws for the amazing artwork 

In the first episode of Season 4 for the Kubernetes Bytes podcast, Bhavin sits down with Ahmed Bebars, Staff Software Engineer at NYTimes to talk about how the times uses Kubernetes and Platform Engineering to accelerate their developer productivity and improve developer experience. They talk about what the technology stack at NYTimes looks like, how the platform team has built a resilient platform on Amazon EKS and share some best practices for anyone starting their journey with Platform Engineering.Check out our website at https://kubernetesbytes.com/Timestamps: 01:20 Cloud Native News 09:55 Interview with Ahmed 50:04 Key takeawaysCloud Native News: https://www.aquasec.com/news/60m-additional-funding/ https://devclass.com/2023/12/12/docker-buys-atomicjar-to-integrate-container-based-test-automation/ https://www.businessinsider.com/armory-acquired-startup-harness-7-million-2023-12 https://techcrunch.com/2023/12/19/scaleops-looks-to-cut-cloud-bills-by-automating-kubernetes-configurations https://wraltechwire.com/2023/12/21/ciscos-latest-cloud-play-exec-explains-the-deal-for-tech-startup-isovalent/ https://www.kubernetes.dev/resources/release/Show links: https://open.nytimes.com/ https://tickets.kcdnewyork.com/ https://github.com/abebars https://www.linkedin.com/in/ahmedbebars/ https://github.com/nytimes

In this episode, host Katherine Druckman chats with Nikhita Raghunath, a Staff Software Engineer at VMWare leading the Kubernetes engineering team. Nikhita shares her journey into open source contribution, her experiences with Kubernetes, and the importance of diversifying roles in open source communities beyond coding. She also discusses the challenges many face when contributing to open source, from time constraints to language barriers, and provides practical advice on navigating these hurdles. The conversation takes an exciting turn as Nikhita expresses her enthusiasm about the intersection of AI and cloud native technology and their potential to benefit each other. She concludes the episode with valuable advice for new contributors, emphasizing the importance of personal research and initiative when approaching open source projects. This episode is a must-listen for those interested in open source contribution, Kubernetes, and the future of AI in cloud native technology. 00:00 Introduction and Guest Background 01:23 Journey into Programming 03:29 Getting Involved in Open Source 12:27 Challenges in Open Source Contribution 16:43 Advice for New Contributors 18:59 Addressing Limitations in Open Source Communities 22:00 Exciting Developments in Open Source Technology 24:32 Final Thoughts and Advice for New Contributors   Guest: Nikhita Raghunath is a senior member of technical staff at VMware, a member of the Kubernetes Steering Committee, and is responsible for the overall governance of the Kubernetes project. She is also a Cloud Native Computing Foundation (CNCF) Ambassador and an international public speaker.

Robby has a chat with Staff Software Engineer at Lightstep from ServiceNow, Jacob Aronoff. Their conversation delves into the vital signs of a thriving open source software project. They unpack the characteristics of well-maintained open source endeavors, emphasizing the importance of a passionate community behind the project, rather than misleading indicators like GitHub stars. They discuss the nuances of evaluating a project's health through performance metrics, suggesting that a more holistic view that includes the scrutiny of open issues can provide better insights into the project's robustness and responsiveness to community needs. Furthermore, their discussion highlights a critical, yet often overlooked, aspect of open source software: the project's own dependencies. Jacob argues that understanding these dependencies is crucial before adopting an open source solution, as it could have far-reaching implications on the stability and security of one's own project. They also take a deep dive into the organizational dynamics of the OpenTelemetry community, examining its structured approach to scaling and sustaining the project over time. Their discussion then transitions into the philosophical debate of balancing between the extremes of premature abstraction and delivering a fully opinionated software project. Jacob shares his penchant for “building in the open”, advocating for transparency and community involvement in the development process. He provides valuable advice for both newcomers looking to contribute to open source projects and maintainers seeking to attract new talent. In a personal touch, he extends his gratitude to Robby for creating Oh My Zsh, sharing his own journey in developing a custom theme for it. Moreover, Jacob expresses his preference for pure functional languages, hinting at the broader discussion around programming paradigms and their influence on open source software development. Stay tuned for that and more!Book Recommendations:Killers of the Flower Moon By David Grann and The Hitchhiker's Guide to the Galaxy By Douglas AdamsHelpful Links:Jacob on LinkedInLightstep from ServiceNowJaronoff97 on GitHubJacob's WebsiteJacob on TwitterSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out!

Mike Goldsmith, Staff Software Engineer at Honeycomb, joins Corey on Screaming in the Cloud to talk about Open Telemetry, company culture, and the pros and cons of Go vs. .NET. Corey and Mike discuss why OTel is such an important tool, while pointing out its double-edged sword of being fully open-source and community-driven. Opening up about Honeycomb's company culture and how to find a work-life balance as a fully-remote employee, Mike points out how core-values and social interaction breathe life into a company like Honeycomb.About MikeMike is an OpenSource focused software engineer that builds tools to help users create, shape and deliver system & application telemetry. Mike contributes to a number of OpenTelemetry initiatives including being a maintainer for Go Auto instrumentation agent, Go proto packages and an emeritus .NET SDK maintainer..Links Referenced: Honeycomb: https://www.honeycomb.io/ Twitter: https://twitter.com/Mike_Goldsmith Honeycomb blog: https://www.honeycomb.io/blog LinkedIn: https://www.linkedin.com/in/mikegoldsmith/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends at Honeycomb who I just love talking to. And we've gotten to talk to these folks a bunch of different times in a bunch of different ways. They've been a recurring sponsor of this show and my other media nonsense, they've been a reference customer for our consulting work at The Duckbill Group a couple of times now, and we just love working with them just because every time we do we learn something from it. I imagine today is going to be no exception. My guest is Mike Goldsmith, who's a staff software engineer over at Honeycomb. Mike, welcome to the show.Mike: Hello. Thank you for having me on the show today.Corey: So, I have been familiar with Honeycomb for a long time. And I'm still trying to break myself out of the misapprehension that, oh, they're a small, scrappy, 12-person company. You are very much not that anymore. So, we've gotten to a point now where I definitely have to ask the question: what part of the observability universe that Honeycomb encompasses do you focus on?Mike: For myself, I'm very focused on the telemetry side, so the place where I work on the tools that customers deploy in their own infrastructure to collect all of that useful data and make—that we can then send on to Honeycomb to make use of and help identify where the problems are, where things are changing, how we can best serve that data.Corey: You've been, I guess on some level, there's—I'm trying to make this not sound like an accusation, but I don't know if we can necessarily avoid that—you have been heavily involved in OpenTelemetry for a while, both professionally, as well as an open-source contributor in your free time because apparently you also don't know how to walk away from work when the workday is done. So, let's talk about that a little bit because I have a number of questions. Starting at the very beginning, for those who have not gone trekking through that particular part of the wilderness-slash-swamp, what is OpenTelemetry?Mike: So, OpenTelemetry is a vendor-agnostic set of tools that allow anybody to collect data about their system and then send it to a target back-end to make use of that data. The data, the visualization tools, and the tools that make use of that data are a variety of different things, so whether it's tracing data or metrics or logs, and then it's trying to take value from that. The big thing what OpenTelemetry is aimed at doing is making the collection of the data and the transit of the data to wherever you want to send it a community-owned resource, so it's not like you get vendor lock-in by going to using one competitor and then go to a different—you want to go and try a different tool and you've got to re-instrument or change your application heavily to make use of that. OpenTelemetry abstracts all that away, so all you need to know about is what you're instrumented with, what [unintelligible 00:03:22] can make of that data, and then you can send it to one or multiple different tools to make use of that data. So, you can even compare some tools side-by-side if you wanted to.Corey: So, given that it's an open format, from the customer side of the world, this sounds awesome. Is it envisioned that this is something—an instrument that gets instrumented at the application itself or once I send it to another observability vendor, is it envisioned that okay, if I send this data to Honeycomb, I can then instrument what Honeycomb sees about that and then send that onward somewhere else, maybe my ancient rsyslog server, maybe a different observability vendor that has a different emphasis. Like, how is it envisioned unfolding within the ecosystem? Like, in other words, can I build a giant ring of these things that just keep building an infinitely expensive loop?Mike: Yeah. So ideally, you would try and try to pick one or a few tools that will provide the most value that you can send to, and then it could answer all of the questions for you. So, at Honeycomb, we try to—we are primarily focused on tracing because we want to do application-level information to say, this user had this interaction, this is the context of what happened, these are the things that they clicked on, this is the information that flowed through your back-end system, this is the line-item order that was generated, the email content, all of those things all linked together so we know that person did this thing, it took this amount of time, and then over a longer period of time, from the analytics point of view, you can then say, “These are the most popular things that people are doing. This is typically how long it takes.” And then we can highlight outliers to say, “Okay, this person is having an issue.” This individual person, we can identify them and say, “This is an issue. This is what's different about what they're doing.”So, that's quite a unique tracing tool or opportunity there. So, that lets you really drive what's happening rather than what has happened. So, logs and metrics are very backward-looking to say, “This is the thing that this thing happened,” and tries to give you the context about it. Tracing tries to give you that extra layer of context to say that this thing happened and it had all of these things related to it, and why is it interesting?Corey: It's odd to me that vendors would be putting as much energy into OpenTelemetry—or OTel, as it seems to always be abbreviated as when I encounter it, so I'm using the term just so people, “Oh, wait, that's that thing I keep seeing. What is that?” Great—but it seems odd to me that vendors would be as embracing of that technology as they have been, just because historically, I remember whenever I had an application when I was using production in anger—which honestly, ‘anger' is a great name for the production environment—whenever I was trying to instrument things, it was okay, you'd have to grab this APM tools library and instrument there, and then something else as well, and you wound up with an order of operations where which one wrapped the other. And sometimes that caused problems. And of course, changing vendors meant you had to go and redeploy your entire application with different instrumentation and hope nothing broke. There was a lock-in story that was great for the incumbents back when that was state of the art. But even some of those incumbents are now embracing OTel. Why?Mike: I think it's because it's showing that there's such a diverse group of tools there, and [unintelligible 00:06:32] being the one that you've selected a number of years ago and then they could hold on to that. The momentum slowed because they were able to move at a slower pace because they were the organizations that allowed us—they were the de facto tooling. And then once new companies and competitors came around and we're open to trying to get a part of that market share, it's given the opportunity to then really pick the tool that is right for the job, rather than just the best than what is perceived to be the best tool because they're the largest one or the ones that most people are using. OpenTelemetry allows you to make an organization and a tool that's providing those tools focus on being the best at it, rather than just the biggest one.Corey: That is, I think, a more enlightened perspective than frankly, I expect a number of companies out there to have taken, just because it seems like lock-in seems to be the order of the day for an awful lot of companies. Like, “Okay, why are customers going to stay with us?” “Because we make it hard to leave,” is… I can understand the incentive, but that only works for so long if you're not actively solving a problem that customers have. One of the challenges that I ran into, even with OTel, was back when I was last trying to instrument a distributed application—which was built entirely on Lambda—is the fact that I was doing this for an application that was built entirely on Lambda. And it felt like the right answer was to, oh, just use an OTel layer—a Lambda layer that wound up providing the functionality you cared about.But every vendor seemed to have their own. Honeycomb had one, Lightstep had one, AWS had one, and now it's oh, dear, this is just the next evolution of that specific agent problem. How did that play out? Is that still the way it works? Is there other good reasons for this? Or is this just people trying to slap a logo on things?Mike: Yeah, so being a fully open-source project and a community-driven project is a double-edged sword in some ways. One it gives the opportunity for everybody to participate, everybody can move between tools a lot easier and you can try and find the best fit for you. The unfortunate part around open-source-driven projects like that means that it's extremely configuration-heavy because it can do anything; it's not opinionated, which means that if you want to have the opportunity to do everything, every possible use case is available to everyone all of the time. So, if you might have a very narrow use case, say, “I want to learn about this bit of information,” like, “I'm working with the [unintelligible 00:09:00] SDK. I want to talk about—I've got an [unintelligible 00:09:03] application and I want to collect data that's running in a Lambda layer.” The OpenTelemetry SDK that has to serve all of the [other 00:09:10] JavaScript projects across all the different instrumentations, possibly talking about auto-instrumentation, possibly talking about lots of other tools that can be built into that project, it just leads to a very highly configurable but very complicated tool.So, what the vendor specifics, what you've suggested there around like Honeycomb, or other organizations providing the layers, they're trying to simplify the usage of the SDK to make some of those assumptions for you that you are going to be sending telemetry to Honeycomb, you are going to be talking about an API key that is going to be in a particular format, it is easier to pass that information into the SDK so it knows how to communicate rather than—as well as where it's going to communicate that data to.Corey: There's a common story that I tend to find myself smacking into almost against my will, where I have found myself at the perfect intersection of a variety of different challenges, and for some reason, I have stumbled blindly and through no ill intent into ‘this is terrible' territory. I wound to finally getting blocked and getting distracted by something else shiny on this project about two years ago because the problem I was getting into was, okay, I got to start sending traces to various places and that was awesome, but now I wanted to annotate each span with a user identity that could be derived from code, and the way that it interfaced with the various Lambda layers at that point in time was, ooh, that's not going to be great. And I think there were a couple of GitHub issues opened on it as feature enhancements for a couple of layers. And then I, again, was still distracted by shiny things and never went back around to it. But I was left with the distinct impression that building something purely out of Lambda functions—and also probably popsicle sticks—is something of an edge case. Is there a particular software architecture or infrastructure architecture that OTel favors?Mike: I don't think it favors any in particular, but it definitely suffers because it's, as I said earlier, it's trying to do that avail—the single SDK is available to many different use cases, which has its own challenges because then it has to deal with so many different options. But I don't think OpenTelemetry has a specific, like, use case in mind. It's definitely focused on, like—sorry, telemetry tracing—tracing is focused on application telemetry. So, it's focused on about your code that you build yourself and then deploy. There are other tools that can collect operational data, things like the OpenTelemetry Collector is then available to sit outside of that process and say, what's going on in my system?But yeah, I wouldn't say that there's a specific infrastructure that it's aimed at doing. A lot of the cloud operators and tools are trying to make sure that that information is available and OpenTelemetry SDKs are available. But yeah, at the moment, it does require some knowledge around what's best for your application if you're not in complete control of all of the infrastructure that it's running in.Corey: It feels that with most things that are sort of pulled into the orbit of the CNCF—and OTel is no exception to this—that there's an idea that oh, well, everything is going to therefore be running in containers, on top of Kubernetes. And that might be unfair, but it also, frankly, winds up following pretty accurately what a lot of applications I'm seeing in client environments have been doing. Don't take it as a criticism. But it does seem like it is designed with an eye toward everything being microservices running on containers, scheduled which, from a infrastructure perspective, what appears to be willy-nilly abandoned, and how do you wind up gathering useful information out of that without drowning in data? That seems to be, from at least my brief experience with OTel, the direction it heads in. Is that directionally correct?Mike: Yeah, I think so. I think OpenTelemetry has a quite strong relationship with CNCF and therefore Kubernetes. That is a use case that we see as a very common with customers that we engage with, both at the prospect level and then just initial conversations, people using something like Kubernetes to do the application orchestration is very, very common. It's something that OpenTelemetry and Honeycomb are wanting to improve on as well. We want to get by a very good experience because it is so common when we come up to it that we want to have a very good, strong opinion around, well, if you're running in Kubernetes, these are the tools and these are the right ways to use OpenTelemetry to get the best out of it.Corey: I want to change gears a little bit. Something that's interested me about Honeycomb for a while has been its culture. Your founders have been very public about their views on a variety of different things that are not just engineering-centric, but tangential to it, like, engineering management: how not to be terrible at it. And based on a huge number of conversations I've had with folks over there, I'm inclined to agree that the stories they tell in public do align with how things go internally. Or at least if they're not, I would not expect you to admit it on the record, so either way, we'll just take that as a given.What I'm curious about is that you are many timezones away from their very nice office here in San Francisco. What's it like working remote in a company that is not fully distributed? Which is funny, we talk about distributed applications as if they're a given but distributed teams are still something we're wrangling with.Mike: Yeah, it's something that I've dealt with for quite a while, for maybe seven or eight years is worked with a few different organizations that are not based in my timezone. There's been a couple, primarily based in San Francisco area, so Pacific Time. An eight-hour time difference for the UK is challenging, it has its own challenges, but it also has a lot of benefits, too. So typically, I get to really have a lot of focus time on a morning. That means that I can start my day, look through whatever I think is appropriate for that morning, and not get interrupted very easily.I get a lot of time to think and plan and I think that's helped me at, like, the tech lead level because I can really focus on something and think it through without that level of interruption that I think some people do if you're working in the same timezone or even in the same office as someone. That approachability is just not naturally there. But the other side of that is that I have a very limited amount of natural overlap with people I work with on a day-to-day basis, so it's typically meetings from 2 till 5 p.m. most days to try and make sure that I build those social relationships, I'm talking to the right people, giving status updates, planning and that sort of thing. But it works for me. I really enjoy that balance of some ty—like, having a lot of focus time and having, like, then dedicated time to spend with people.And I think that's really important, as well is that a distributed team naturally means that you don't get to spend a lot of time with people and a lot of, like, one-on-one time with people, so that's something that I definitely focus on is doing a lot of social interaction as well. So, it's not just I have a meeting, we've got to stand up, we've got 15 minutes, and then everyone goes and does their own thing. I like to make sure that we have time so we can talk, we can connect to each other, we know each other, things that would—[unintelligible 00:16:35] that allow a space for conversations to happen that would naturally happen if you were sat next to somebody at a desk, or like, the more traditional, like, water cooler conversations. You hear somebody having a conversation, you go talk to them, that naturally evolves.Corey: That was where I ran into a lot of trouble with it myself. My first outing as a manager, I had—most of the people on my team were in the same room as I was, and then we had someone who was in Europe. And as much as we tried to include this person in all of our meetings, there was an intrinsic, “Let's go get a cup of coffee,” or, “Let's have a discussion and figure things out.” And sometimes it's four in the afternoon, we're going to figure something out, and they have long since gone to bed or have a life, hopefully. And it was one of those areas where despite a conscious effort to avoid this problem, it was very clear that they did not have an equal voice in the team dynamic, in the team functioning, in the team culture, and in many cases, some of the decisions we ultimately reached as an outgrowth of those sidebar conversations. This led to something of an almost religious belief for me, for at least a while, was that either everyone's distributed or no one is because otherwise you wind up with the unequal access problem. But it's clearly worked for you folks. How have you gotten around that?Mike: For Honeycomb, it was a conscious decision not long before the Covid pandemic that the team would be distributed first; the whole organization will be distributed first. So, a number of months before that happened, the intention was that anybody across the organization—which at the time, was only North America-based staff—would be able to do their job outside of the office. Because I think around the end of 2019 to the beginning of 2020, a lot of the staff were based in the San Francisco area and that was starting to grow, and want more staff to come into the business. And there were more opportunities for people outside of that area to join the business, so the business decided that if we're going to do this, if we're going to hire people outside of the local area, then we do want to make sure that, as you said, that everybody has an equal access, everyone has equal opportunity, they can participate, and everybody has the same opportunity to do those things. And that has definitely fed through pandemic, and then even when the office reopened and people can go back into the office. More than—I think there's only… maybe 25% of the company now is even in Pacific Time Zone. And then the office space itself is not very large considering the size of the company, so we couldn't fit everybody into our office space if we wanted to.Corey: Yeah, that's one of the constant growing challenges, too, that I understand that a lot of companies do see value in the idea of getting everyone together in a room. I know that I, for example, I'm a lot more effective and productive when I'm around other people. But I'm really expensive to their productivity because I am Captain Interrupter, which, you know, we have to recognize our limitations as we encounter them. But that also means that the office expense exceeds the AWS bill past a certain point of scale, and that is not a small thing. Like, I try not to take too much of a public opinion on should we be migrating everyone back to return-to-office as a mandate, yes, no, et cetera.I can see a bunch of different perspectives on this that are nuanced and I don't think it lends itself to my usual reactionary take on the Twitters, as it were, but it's a hard problem with no easy answer to it. Frankly, I also think it's a big mistake to do full-remote only for junior employees, just because so much of learning how the workforce works is through observation. You don't learn a lot about those unspoken dynamics in any other way than observing it directly.Mike: Yes, I fully agree. I think the stage that Honeycomb was at when I joined and has continued to be is that I think a very junior person joining an organization that is fully distributed is more challenging. It has different challenges, but it has more challenges because it doesn't have those… you can't just see something happening and know that that's the norm or that that's the expectation. You've got to push yourself into those in those different arenas, those different conversations, and it can be quite daunting when you're new to an organization, especially if you are not experienced in that organization or experienced in the role that you're currently occupying. Yeah, I think the distributed organizations is—fully distributed has its challenges and I think that's something that we do at Honeycomb is that we intentionally do that twice a year, maybe three times a year, bring in the people that do work very closely, bringing them together so they have that opportunity to work together, build those social interactions like I mentioned earlier, and then do some work together as well.And it builds a stronger trust relationship because of that, as well because you're reinforcing the social side with the work side in a face-to-face context. And there's just, there's no direct replacement for face-to-face. If you worked for somebody and never met them for over a year, it'd be very difficult to then just be in a room together and have a normal conversation.Corey: It takes a lot of effort because there's so much to a company culture that is not meetings or agenda-driven or talking about the work. I mean, companies get this wrong with community all the time where they think that a community is either a terrible option of people we can sell things to or more correctly, a place where users of our product or service or offering or platform can gather together to solve common challenges and share knowledge with each other. But where they fall flat often is it also has to have a social element. Like ohh, having a conversation about your lives is not on topic for this community Slack team is, great, that strangles community before it can even form, in many cases. And work is no different.Mike: Yeah, I fully agree. We see that with the Honeycomb Pollinators Slack channel. So, we use that as a primary way of community members to participate, talk to each other, share their experiences, and we can definitely see that there is a high level of social interaction alongside of that. They connect because they've got a shared interest or a shared tool or a shared problem that they're trying to solve, but we do see, like, people, the same people, reconnecting or re-communicating with each other because they have built that social connection there as well.And I think that's something that as organizations—like, OpenTelemetry is a community is more welcoming to that. And then you can participate with something that then transcends different organizations that you may work for as well because you're already part of this community. So, if that community then reaches to another organization, there's an opportunity to go, to move between organizations and then maintain a level of connection.Corey: That seems like one of the better approaches that people can have to this stuff. It's just a—the hard part, of course, is how do you change culture? I think the easy way to do it—the only easy way to do it—is you have to build the culture from the beginning. Every time I see companies bringing in outsiders to change the corporate culture, I can't help but feel that they're setting giant piles of money on fire. Culture is one of those things that's organic and just changing it by fiat doesn't work. If I knew how to actually change culture, I would have a much more lucrative target for my consultancy than I do today. You think AWS bills are a big problem? Everyone has a problem with company cultures.Mike: Yeah, I fully agree. I think that culture is something that you're right is very organic, it naturally happens. I think the value when organizations go through, like, a retrospective, like, what is our culture? How would we define it? What are the core values of that and how do we articulate that to people that might be coming into the organization, that's very valuable, too, because those core values are very useful to communicate to people.So, one of the bigger core values that we've got at Honeycomb is that—we refer to as, “We hire adults,” meaning that when somebody needs to do something, they just can go and do it. You don't have to report to somebody, you don't have to go and tell somebody, “I need a doctor appointment,” or, “I've got to go and pick up the kids from school,” or something like that. You're trusted to do your job to the highest level, and if you need additional help, you can ask for it. If somebody requires something of you they ask for it. They do it in a humane way and they expect to be treated like a human and an adult all of the time.Corey: On some level, I've always found, for better or worse, that people will largely respond to how you treat them and live up or down to the expectation placed upon them. You want a bunch of cogs who are going to have to raise their hand to go to the bathroom? Okay, you can staff that way if you want, but don't be surprised when those teams don't volunteer to come up with creative solutions to things either. You can micromanage people to death.Mike: Yeah. Yeah, definitely. I've been in organizations, like, fresh out of college and had to go to work at a particular place and it was very time-managed. And I had inbound sales calls and things like that and it was very, like, you've spent more than three minutes on a wrap-up call from having a previous call, and if you don't finish that call within three minutes, your manager will call your phone to say, “You need to go on to the next call.” And it's… you could have had a really important call or you could have had a very long call. They didn't care. They just wanted—you've had your time now move on to the next one and they didn't care.Corey: One last question I want to ask you about before we wind up calling this an episode, and it distills down to I guess, effectively, your history, for lack of a better term. You have done an awful lot of Go maintenance work—Go meaning the language, not the imperative command, to be clear—but you also historically were the .NET SDK maintainer for something or other. Do you find those languages to be similar or… how did that come to be? I mean, to be clear, my programming languages of choice are twofold: both brute force and enthusiasm. Most people take a slightly different path.Mike: Yeah, I worked with .NET for a very long time, so that was, like, the place—the first place that I joined as a real organization after finishing college was .NET and it just sort of stuck. I enjoyed the language. At the time, sort of, what 15 year—12, 15 years ago, the language itself was moving pretty well, there was things being added to it, it was enjoyable to use.Over the last maybe four or five years, I've had the opportunity to work a lot more in Go. And they are very different. So, Go is much more focused on simplicity and not hiding anything from anybody and just being very efficient at what you can see it does. .NET and many other languages such as Java, Ruby, JavaScript, Python, all have a level of magic to them, so if you're not part of the ecosystem or if you don't know particular really common packages that can do things for you, not knowing something about the ecosystem causes pain.I think Go takes away some of that because if you don't know those ecosystems or if you don't know those tools, you can still solve the problem fairly quickly and fairly simply. Tools will help but they're not required. .NET is probably on the boundary for me. It's still very easy to use, I enjoy using it, but it just… I found that it's not that long ago, I would say that I've switched from thinking like a .NET developer, so whenever I'm forming code in my head, like, how I would solve a problem, for a very long time, it was in .NET and C#.I'd probably say in the last 12 months or so, it's definitely moved more to Go just because of the simplicity. And it's also the tool that is most used within Honeycomb, especially, so if you're talking about Go code, you've got a wider audience to bounce ideas off, to talk to, communicate, get ideas from. .NET is not a very well used language within Honeycomb and probably even, like… even maybe West Coast-based organizations, it seems to be very high-level organizations that are willing to pay their money up for, like, Microsoft support. Like, Go is something that a lot of developers use because it's very simple, very quick, can move quick.Corey: I found that it was very easy for me to pick up Go to build out something ridiculous a few years back when I need to control my video camera through its ‘API' to use the term charitably. And it just works in a way that made an awful lot of sense. But I still find myself reaching for Python or for—God help me—TypeScript if I'm doing some CDK work these days. And honestly, they all tend to achieve more or less the same outcome. It's just different approaches to—well, to be unkind—dependency management in some cases, and also the ecosystem around it and what is done for you.I don't think there's a bad language to learn. I don't want this to be interpreted as language snobbery, but I haven't touched anything in the Microsoft ecosystem for a long time in production, so .NET was just never on my radar. But it's clear they have an absolutely massive community ecosystem built around it and that is no small thing. I'd say it rivals Java.Mike: Yeah definitely. I think over the last ten years or so, the popularity of .NET as a language to be built from enterprise, especially at larger-scale organizations have taken it on, and then, like, six, seven years ago, they introduced the .NET Core Framework, which allowed it to run on non-Windows platforms, and that accelerated the language dramatically, so they have a consistent API that can be used on Windows, on Linux, Mac, and that makes a huge difference for creating a larger audience for people to interact with it. And then also, with Azure becoming much more popular, they can have all of these—this language that people are typically used to using Linux as an operating system that runs infrastructure, but not being forced to use Windows is probably quite a big thing for Azure as well.Corey: I really want to thank you for taking the time to talk about what you're up to over there. If people want to learn more, where's the best place for them to go find you?Mike: Typically, I use Twitter, so it's Mike_Goldsmith. I create blogs on the Honeycomb blog website, which I've done a few different things; I've got a new one coming up soon to talk about different ways of collecting data. So yeah, those are the two main places. LinkedIn is usual as ever, but that's a little bit more work-focused.Corey: It does seem to be. And we'll put links to all of that in the [show notes 00:31:11]. Thank you so much for being so generous with your time, and of course, thank you Honeycomb for sponsoring this episode of my ridiculous podcast.Mike: Yeah, thank you very much for having me on.Corey: Mike Goldsmith, staff software engineer at Honeycomb. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an insulting comment that we will then have instrumented across the board with a unified observability platform to keep our days eventful.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

O são-bentista Bruno se interessou por tecnologia desde cedo e, após o curso técnico em informática em São José dos Campos e o curso superior de Engenharia da Computação na Universidade Federal de Itajubá, trabalhou durante seis anos na WildLife, onde chegou a uma posição de gestão. Após um convite no LinkedIn e um longo processo seletivo, ele mudou-se para Zurique onde trabalha hoje como Staff Engineer em projetos imersivos da Meta. Neste episódio, o Bruno conta com detalhes como foi o processo seletivo, por que escolheu Zurique ao invés de Londres, e o dia a dia pessoal e profissional na terra da raclette. Fabrício Carraro, o seu viajante poliglota Bruno Lopes, Staff Software Engineer na Meta em Zurique, Suíça Links: LeetCode Numbeo Formação Desenvolvimento de Jogos com Unity na Alura Unreal Engine TechGuide.sh, um mapeamento das principais tecnologias demandadas pelo mercado para diferentes carreiras, com nossas sugestões e opiniões. #7DaysOfCode: Coloque em prática os seus conhecimentos de programação em desafios diários e gratuitos. Acesse https://7daysofcode.io/ Ouvintes do podcast Dev Sem Fronteiras têm 10% de desconto em todos os planos da Alura Língua. Basta ir a https://www.aluralingua.com.br/promocao/devsemfronteiras/e começar a aprender inglês e espanhol hoje mesmo!  Produção e conteúdo: Alura Língua Cursos online de Idiomas – https://www.aluralingua.com.br/ Alura Cursos online de Tecnologia – https://www.alura.com.br/ Edição e sonorização: Rede Gigahertz de Podcasts

LinkedIn is a case study in terms of how its newsfeed has evolved over the years. LinkedIn's feed has come a long way since the early days of assembling the machine learning infrastructure that powers it. Recently, a major update to this infrastructure was released. We caught up with the people behind it to discuss how the principle of being people-centric translates to technical terms and implementation. Article published on Orchestrate all the Things

Elise Shaffer is a trans woman and Staff Software Engineer who loves Ruby and Ruby on Rails. She is also the new host of this podcast! Brittany announces her retirement from the show after a five year run as the host. In this special episode, the pair discuss Brittany's favorite moments from her run, get to know Elise and discuss any upcoming changes for the show. Show Notes: The Ruby on Rails Podcast | 228: From the ashes... (https://www.therubyonrailspodcast.com/228) The Ruby on Rails Podcast | 379: MEGA Crossover Episode (The Bike Shed x Rails with Jason x Remote Ruby x The Ruby on Rails Podcast) (https://www.therubyonrailspodcast.com/379) The Ruby on Rails Podcast | 454: Rubyconf @ Home: Hanami Core Team (https://www.therubyonrailspodcast.com/454) The Ruby on Rails Podcast | 469: Railsconf 2023: A Ruby Community Podcast Live! (https://www.therubyonrailspodcast.com/469) Connect with Elise on Linkedin (https://www.linkedin.com/in/eliseshaffer/) Elise's Personal Site (https://eliseshaffer.com/) Contact Brittany at brittany.jill.martin@gmail.com Sponsored By: Honeybadger (https://www.honeybadger.io/) As an Engineering Manager or an engineer, too much of your time gets sucked up with downtime issues, troubleshooting, and error tracking. How can you spend more time shipping code and less time putting out fires? Honeybadger is how. It's a suite of monitoring tools specifically for devs. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free!

After years in the tech game, senior developers know that it's important to find a balance between innovation and stability in engineering. How can developers strike the balance between embracing new tools and ensuring the steadfastness of their applications over the long haul? Chris Thoburn (Runspired), Staff Software Engineer at AuditBoard, is a big deal in the open-source community, particularly within the Ember community. He explains how his journey has been a unique blend of teamwork and adapting and elaborates on the philosophy behind Ember Data. Chris mentions that the framework is like a solid foundation, built to provide a consistent and stable data layer while allowing developers to evolve their apps over the years. His vision is for Ember Data to be a trusted companion for developers creating web apps. In this episode, Runspired talks to Robbie and Chuck about his views on controversial tech topics like HTMX, the power of Ember Data and its role in creating stable, scalable, and evolving applications, and the pivotal role that open-source plays in shaping technology. Key Takeaways [00:50] - Intro to Runspired. [02:04] - A whiskey review: Hibiki Blended Japanese Whiskey. [10:52] - Tech hot takes. [30:26] - How Runspired would rename Ember Data. [39:40] - Runspired's success pitching open source. [47:35] - The career Runspired would be in if he wasn't in tech. [50:09] - Runspired shares whether HTMX will change the way web apps are built. [01:00:21] - Runspired's first choice karaoke song. Quotes [27:25] - “I've been around enough, seen enough to realize that getting really caught up in one approach is just an exercise in long-term frustration that I don't need.” ~ Runspired [35:35] - “How do you get a company to invest in open-source? It's not about open-source, it's about value to a company.” ~ Runspired [51:07] - “I think we are approaching a very different era in the maturity of Javascript development.” ~ Runspired Links Runspired Chris Thoburn LinkedIn Ember Hibiki Blended Japanese Whiskey EmberConf Kool-Aid Crush Soda Portland Coffee Roasters Twitter Threads Svelte Tailwind CSS YAML JSON NPM GitHub Microsoft LinkedIn Remix Next.js Nuxt React Angular Vue.js RedwoodJS Solid.js Svelte GraphQL Rust Active Record JSON tRPC gRPC Protocol Buffers Connect with our hosts Robbie Wagner Chuck Carpenter Ship Shape Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Top-Tier, Full-Stack Software Consultants This show is brought to you by Ship Shape. Ship Shape's software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io. --- Send in a voice message: https://podcasters.spotify.com/pod/show/whiskey-web-and-whatnot/message

In this show we're not focusing on the scientists or their discoveries, but instead we talk to some of the unsung heroes, the pillars of support behind the scenes who play an integral role in the lives of dementia researchers? We focus on the husbands, partners, and significant others of dementia researchers – who generously share their insights. Getting a glimpse into the lives of those who stand shoulder to shoulder with researchers, offering unwavering encouragement, love, and understanding. For our special family and careers week, we discuss how they support the researchers in their lives, and have a fun quiz to see just how well they know them. -- Adam Smith, Programme Director for Dementia Researcher hosts this discussion with: Andrew Lashley, self-employed Architect, father of three, and husband to Tammaryn Lashley, Professor of Neuroscience at University College London. Michael O'Reilly, Scenic Artist at the Royal Opera House, father of one, and husband to Dr Zanna Voysey, Neurologist and PhD Student, University of Cambridge. João Moreira, Staff Software Engineer and husband to Dr Isabel Castanho, Postdoctoral Research Fellow at the Beth Israel Deaconess Medical Center (BIDMC), Harvard Medical School. -- Hear from Professor Lashley sharing more about life as a working academic, mother, and wife in this one-to-one interview and as a guest on our managing family life and a research career podcast: Interview – https://bit.ly/44BkSSA Podcast - https://bit.ly/3sJUYPn -- Full biographies on all our guests and a transcript can be found on our website https://www.dementiaresearcher.nihr.ac.uk -- Like what you hear? Please review, like, and share our podcast - and don't forget to subscribe to ensure you never miss an episode – and if you prefer to watch rather than listen, you'll find a video version of this podcast with full captions on our YouTube Channel -- This podcast is brought to you by University College London / UCLH NIHR Biomedical Research Centre in association with Alzheimer's Association, Alzheimer's Research UK, Alzheimer's Society and Race Against Dementia who we thank for their ongoing support.

Trond Snekvik spoke with us about developing VSCode extensions and Bluetooth meshes. Trond is a Staff Software Engineer at Nordic Semiconductor. Nordic's Visual Studio Code Extensions include device tree and kconfig support for the Zephyr project as well as tools for nRF Connect.  Trond's github page: github.com/trond-snekvik In 329: At Least 32-Bits, Thank You, Kate Stewart of the Linux Foundation spoke with us about Zephyr in 2020  Transcript Thank you to Christopher for providing a picture of what may (or may not) be a troll.

In episode 82 of The Gradient Podcast, Daniel Bashir speaks to Ryan Drapeau.Ryan is a Staff Software Engineer at Stripe and technical lead for Stripe's Payment Fraud organization, which uses machine learning to help prevent billions of dollars of credit card and payments fraud for business every year.Have suggestions for future podcast guests (or other feedback)? Let us know here or reach us at editor@thegradient.pubSubscribe to The Gradient Podcast:  Apple Podcasts  | Spotify | Pocket Casts | RSSFollow The Gradient on TwitterOutline:* (00:00) Intro* (02:15) Ryan's background* (05:28) Differences between adversarial problems (fraud, content moderation, etc.)* (08:50) How fraud manifests for businesses* (11:07) Types of fraud* (15:49) Fraud as an industry* (19:05) Information asymmetries between fraudsters and defenders* (22:40) Fraud as an ML problem and Stripe Radar* (25:45) Evolution of Stripe Radar* (31:38) Architectural evolution* (41:38) Why ResNets for Stripe Radar?* (44:15) Future architectures for Stripe Radar and the explainability/performance tradeoff* (48:58) War stories* (52:55) Federated learning opportunities for Stripe Radar* (55:50) Vectors for improvement in Stripe's fraud detection systems* (59:22) More ways of thinking about the fraud problem, multiclass models* (1:03:30) Lessons Ryan has picked up from working on fraud* (1:05:44) OutroLinks:* How We Built It: Stripe Radar* Stripe 2022 Update Get full access to The Gradient at thegradientpub.substack.com/subscribe

Bailey & Jesse chat with Horace Williams, a member of the first proto-Turing program called Hungry Academy in 2012. Horace was one of the first instructors at Turing and is a current Staff Software Engineer at Medallion. The discuss the early days of code schools and Turing, Horace's work on political campaigns, Clojure, Ann Arbor, and other topics. If you or someone you know are code curious, we encourage you to attend a Turing Try Coding Event. You can register for a free Try Coding class at turing.edu/try-coding.

What if AI could revolutionize healthcare with advanced language learning models? Sarah and Elad welcome Karan Singhal, Staff Software Engineer at Google Research, who specializes in medical AI and the development of MedPaLM2. On this episode, Karan emphasizes the importance of safety in medical AI applications and how language models like MedPaLM2 have the potential to augment scientific workflows and transform the standard of care. Other topics include the best workflows for AI integration, the potential impact of AI on drug discoveries, how AI can serve as a physician's assistant, and how privacy-preserving machine learning and federated learning can protect patient data, while pushing the boundaries of medical innovation. No Priors is now on YouTube! Subscribe to the channel on YouTube and like this episode. Show Links: May 10, 2023: PaLM 2 Announcement April 13, 2023: A Responsible Path to Generative AI in Healthcare March 31, 2023: Scientific American article on Med-PaLM February 28, 2023: The Economist article on Med-PaLM KaranSinghal.com Sign up for new podcasts every week. Email feedback to show@no-priors.com Follow us on Twitter: @NoPriorsPod | @Saranormous | @EladGil | @thekaransinghal Show Notes: [00:22] - Google's Medical AI Development [08:57] - Medical Language Model and MedPaLM 2 Improvements [18:18] - Safety, cost/benefit decisions, drug discovery, health information, AI applications, and AI as a physician's assistant. [24:51] - Privacy Concerns - HIPAA's implications, privacy-preserving machine learning, and advances in GPT-4 and MedPOM2. [37:43] - Large Language Models in Healthcare and short/long term use.

Patrick and Jacob sit down with Mike Conover, Staff Software Engineer at Databricks and Co-Creator of Databricks Dolly, the world's first truly open instruction-tuned LLM, to discuss the magic behind Dolly, Alpaca and other instruction-tuned LLMs, the unreasonable effectiveness of fine-tuning, how they got all Databricks employees to help them curate the Dolly dataset (hint: google forms), and more. (0:00) - Intro(5:54) - The birth of Dolly(12:03) - Data curation at Databricks(15:34) - Advice for building LLMs(24:10) - The future of instruction-tuning datasets(30:43) - UI innovation(38:16) - The future of machine learning infrastructure(42:05) - How SkipFlag would be different with the tools we have today(47:01) - What Mike has learned since Dolly With your co-hosts:@jasoncwarner- Former CTO GitHub, VP Eng Heroku & Canonical@ericabrescia- Former COO Github, Founder Bitnami (acq'd by VMWare)@patrickachase- Partner at Redpoint, Former ML Engineer LinkedIn@jacobeffron- Partner at Redpoint, Former PM Flatiron Health

No episódio de hoje, Luan Moreno e Mateus Oliveira entrevistaram Tatiana Al-Chueyr Martins, atualmente como Engenheira de Software na Astronomer. O Astro Python SDK é um SDK desenvolvido em Python Open-Source criado pela Astronomer, empresa que acelera o Apache Airflow, para tornar simples o processo de ETL. Astro Python SDK oferece os seguintes benefícios:Operações de ETL com Operadores para Abstração de ComplexidadeCarga de Dados de Forma Escalável e Eficiente (Native Transfers)Transformações Utilizando SQL & DataFramesEntrega dos Dados nos Principais Data Warehouses ModernosOperações Dinâmicas e EscaláveisFalamos também nesse bate-papo sobre os seguintes temas:Apache AirflowAstronomerAstro CloudAprenda como o Astro Python SDK pode de fato mudar a forma com que seu time cria e desenvolve pipelines de ETL dentro do Apache Airflow.Tatiana Al-Chueyr MartinsAstro Python SDKAstronomer Luan Moreno = https://www.linkedin.com/in/luanmoreno/

How does leader election work in Apache Kafka®? For the past 2 ½ years, Adithya Chandra, Staff Software Engineer at Confluent, has been working on Kafka scalability and performance, specifically partition leader election. In this episode, he gives Kris Jenkins a deep dive into the power of leader election in Kafka replication, why we need it, how it works, what can go wrong, and how it's being improved.Adithya explains that you can configure a certain number of replicas to be distributed across Kafka brokers and then set one of them as the elected leader - the others become followers. This leader-based model proves efficient because clients only have to write to the leader, who handles the replication process internally.But what happens when a broker goes offline, when a replica reassignment occurs, or when a broker shuts down? Adithya explains that when these triggers occur, one of the followers becomes the elected leader, and all the other replicas take their cue from the new leader. This failover reassignment ensures that messages are replicated effectively and efficiently with multiple copies across different brokers.Adithya explains how you can select a broker as the preferred election leader. The preferred leader then becomes the new leader in failure events. This reduces latency and ensures messages consistently write to the same broker for easier tracking and debugging.Leader failover cannot cover all failures, Adithya says. If a broker can't be reached externally but can talk to other brokers in the cluster, leader failover won't be triggered. If a broker experiences transient disk or network issues, the leader election process might fail, and the broker will not be elected as a leader. In both cases, manual intervention is required.Leadership priority is an important feature of Confluent Cloud that allows you to prioritize certain brokers over others and specify which broker is most likely to become the leader in case of a failover. This way, we can prioritize certain brokers to ensure that the most reliable broker handles more important and sensitive replication tasks. Additionally, this feature ensures that replication remains consistent and available even in an unexpected failure event.Improvements to this component of Kafka will enable it to be applied to a wide variety of scenarios. On-call engineers can use it to mitigate single-broker performance issues while debugging. Network and storage health solutions can use it to prioritize brokers. Adithya explains that preferred leader election and leadership failover ensure data is available and consistent during failure scenarios so that Kafka replication can run smoothly and efficiently.EPISODE LINKSData Plane: Replication ProtocolOptimizing Cloud-Native Apache Kafka Performance ft. Alok Nikhil and Adithya ChandraWatch the videoKris Jenkins' TwitterJoin the Confluent CommunityLearn more with Kafka tutorials, resources, and guides at Confluent DeveloperLive demo: Intro to Event-Driven Microservices with ConfluentUse PODCAST100 to get an additional $100 of free Confluent Cloud usage (details)

Guest Dustin Ingram Panelists Richard Littauer | Justin Dorfman Show Notes Hello and welcome to Sustain! The podcast where we talk about sustaining open source for the long haul. Joining us today is Dustin Ingram, who's a Staff Software Engineer on Google's Open Source Security Team, where he works on improving the security of open source software that Google and the rest of the world relies on. He's also the director of the Python Software Foundation and maintainer of the Python Package Index. Today, we'll learn about the Open Source Security Team at Google, what they do, the bill they've contributed to for Securing Open Source Software Act of 2022, a rewards program they have to pay maintainers called SOS rewards, and Google's role in the Sigstore project. Also, Dustin talks about the Python Package Index, he shares his opinion on the difference between security and sustainability, and what he's most excited about with work going on in the next year or two. Download this episode now to find out more! [00:01:10] Dustin fills us in on the Open Source Security Team at Google, what they do there, how they prioritize which packages to work on, and which security bugs to work on. [00:03:25] We hear about the team at Google working on the bill 4913 Securing Open Source Software Act of 2022. [00:04:18] Justin brings up Dan Lorenc and Sigstore, and we learn Google's role in this project and making sure it's adopted more heavily in the supply chain. [00:06:05] Dustin explains the model on how Google is working to make sure these projects stick together, and he tells us how an open source maintainer can make their code more reliable by going to Sigstore and other sites to talk to people. [00:09:26] How does Google prioritize and choose which projects are the most important and where they're going to dedicate developer time to do that work? [00:11:02] Dustin works on the Python Package Index, and he explains what it is, and with the PSF, how many directors they have, and how much he interfaces with other people there. [00:12:17] We hear how Dustin dealt with the fallout from the backlash that happened during the mandatory multifactor authentication for the critical projects. [00:16:52] When it comes to security, Richard wonders if Dustin has put a lot of thought into different grades of where it exists and who it's for, as well as if there's a ten to fifty year plan for the maintainers who move on to do other things and people are not going to be developing at all. [00:19:13] Are there plans around educations for maintainers and communities on how to onboard new maintainers and how to increase security without increasing load time for the maintainers working on their projects? [00:20:21] We hear what the Securing Open Source Software Act is all about. [00:22:21] Now that open source is the dominant distribution, Dustin shares his thoughts on if open source will stop working and explains the real strength of open source. [00:24:09] Richard brings up the US government trying to secure their supply chain, working with future maintainers, code packages, working with foundations to figure out how we secure the ecosystem at a large, and wonders if Dustin sees a way for the government to try and secure open source and not regulate it, but try to figure how to manage it without the help of foundations or package managers. [00:26:56] Dustin shares his opinion on the difference between security and sustainability and what he thinks about that and what he's most excited about with work going on in the next year or two. [00:30:28] Find out where you can follow Dustin and his work on the web. Quotes [00:03:34] “After Log4j, the government got really spooked because they really didn't know what software they were consuming, and President Biden did an executive order on securing a nation's cybersecurity, which was about setting a policy for how the government should consume open source.” [00:08:11] “We also do some other things to make that a little easier for open source maintainers to adopt these technologies.” [00:08:17] “One thing we have is a rewards program called SOS.dev, and that's a way that maintainers can get paid for doing what we feel is relevant security work.” [00:21:01] “The US government consumes a lot of open source software. They have a dependency on a lot more than most large companies that you can think of.” [00:21:11] “The answer to Log4j is not to stop using open source, it's to get better practices around determining what you have and just do industry best practices for finding and fixing vulnerabilities.” Spotlight [00:31:17] Justin's spotlight is some awesome software called Rewind.ai. [00:32:32] Richard's spotlight is Geoff Huntley. [00:33:36] Dustin's spotlight is the Mozilla Open Source Support Program. Links SustainOSS (https://sustainoss.org/) SustainOSS Twitter (https://twitter.com/SustainOSS?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) SustainOSS Discourse (https://discourse.sustainoss.org/) podcast@sustainoss.org (mailto:podcast@sustainoss.org) Richard Littauer Twitter (https://twitter.com/richlitt?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Justin Dorfman Twitter (https://twitter.com/jdorfman?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Dustin Ingram Twitter (https://twitter.com/di_codes) Dustin Ingram LinkedIn (https://www.linkedin.com/authwall?trk=gf&trkInfo=AQFx--arUWM32wAAAYVVP7pwcaKJmtv_xwAO_dyvHEdFxj0JMheal1V_PnvzCU1Fo_b5mai0jP51x2cucIULaN2C_6Hw_WNXexVVFtrbaamCLoGTNV3KU0oNc8E_cJD2AWGXUZA=&original_referer=https://www.google.com/&sessionRedirect=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fdustingram%2F) Dustin Ingram Website (https://dustingram.com/) Open Source Vulnerability (OSV) (https://osv.dev/) Sustain Podcast-Episode 93: Dan Lorenc and OSS Supply Chain Security at Google (https://podcast.sustainoss.org/guests/dan-lorenc) Sigstore (https://www.sigstore.dev/) SOS Rewards (https://sos.dev/) Python Package Index (PyPI) (https://pypi.org/) Sustain Podcast-Episode 75: Deb Nicholson on the OSI, the future of open source, and SeaGL (https://podcast.sustainoss.org/75) Open Technology Fund (https://www.opentech.fund/) Rewind (https://www.rewind.ai/) Geoff Huntley Twitter (https://twitter.com/GeoffreyHuntley) Explaining NFTs: Geoffrey Huntley interviewed by Coffeezilla about his NFT Bay Heist (YouTube) (https://www.youtube.com/watch?v=iLDOSnqN9-I) Mozilla Open Source Support Program (https://www.mozilla.org/en-US/moss/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Dustin Ingram.

I am joined by Will Johns, Staff Software Engineer at The Butterfly Network, to talk about his journey! Like what you hear? Connect with me - Website: www.vaco.com/taylorLinkedIn: Taylor Desseyn Tweet me: @tdesseyn Pics of the life, wife, daughter & dog: @tdesseyn

In part two of my interview with Jason Wodicka, Staff Software Engineer at Karat, we dig deeper into the process of creating predictive, fair, and efficient interview loops. In this episode we start with culture - how do you identify the cultural attributes important to help someone thrive in your environment and how do you interview for culture fit/culture add. We then discuss approaches to blending cultural and functional tests into an interview loop. We then take a little time to discuss how and when to provide hints for candidates during an interview and the surprising value of allowing candidates a redo. PARTNERThanks to our partner CloudZero — Cloud Cost Intelligence Platform. Control cost and drive better decisions with CloudZero cloud cost intelligence. The CloudZero platform provides visibility into cloud spend without the typical pitfalls of legacy cloud cost management tools, like endless tagging or clunky Kubernetes support. Optimize unit economics, decentralize cost data to engineering, and create a shared language between finance and technical teams. CloudZero helps you organize cloud spending better than anyone else. Join companies like Drift, Rapid7, and SeatGeek by visiting cloudzero.com/ctoconnection to get started.

Especially in the early days, too many companies still have ad-hoc interview processes or over index on things like resumes which aren't super predictive of likely performance and tend to exclude many great candidates. In this episode, I get to chat with Jason Wodicka, Staff Software Engineer at Karat about their experiences in structured interviewing for engineering roles. We talk about ways to do an inexpensive but predictive initial technical screen, avoiding “pedigree bias”, structuring tests for functional competence and how best to build a lightweight, quick but predictive loop with independent assessments and clear rubrics for everyone involved.PARTNERThanks to our partner CloudZero — Cloud Cost Intelligence Platform. Control cost and drive better decisions with CloudZero cloud cost intelligence. The CloudZero platform provides visibility into cloud spend without the typical pitfalls of legacy cloud cost management tools, like endless tagging or clunky Kubernetes support. Optimize unit economics, decentralize cost data to engineering, and create a shared language between finance and technical teams. CloudZero helps you organize cloud spending better than anyone else. Join companies like Drift, Rapid7, and SeatGeek by visiting cloudzero.com/ctoconnection to get started.

I am joined by Jordan Kohl, Staff Software Engineer at Twilio. Jordan recently went through the job search and had some amazing insights on how he navigated it and how he ended up at Twilio! Like what you hear? Connect with me - Website: www.vaco.com/taylorLinkedIn: Taylor Desseyn Tweet me: @tdesseyn Pics of the life, wife, daughter & dog: @tdesseyn

Originally published on February 8, 2022 We are taking some time off from production. We will be back with new episodes on July 6th. Paige Niedringhaus, Staff Software Engineer at Blues Wireless and author of the Modernizing React Apps course, joins us to talk about keeping your React application up to date, challenges React developers are experiencing, VS Code extensions that you should try, career changes, and more. Links https://twitter.com/pniedri https://blues.io https://reactroundup.com https://prettier.io https://eslint.org https://marketplace.visualstudio.com/items?itemName=pnp.polacode https://marketplace.visualstudio.com/items?itemName=aaron-bond.better-comments https://marketplace.visualstudio.com/items?itemName=humao.rest-client https://www.digitalcrafts.com https://www.paigeniedringhaus.com/courses https://www.paigeniedringhaus.com https://www.youtube.com/watch?v=zpCf6H8mMMU https://www.youtube.com/watch?v=zUuyJ8mayEw Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form, (https://podrocket.logrocket.com/get-podrocket-stickers) and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today (https://logrocket.com/signup/?pdr). Special Guest: Paige Niedringhaus.

In this episode, Dave and Jamison answer these questions: I've been a Staff Software Engineer at my company for 1 1/2 years. We have about 120 engineers company-wide. I've had 4 different bosses during the last year and our team has moved around a few times on the org chart. I lead a team of 2 engineers. My boss told me I shouldn't be doing any of the coding but should spending my time working with the product manager, doing research for upcoming features, doing code reviews, managing the Jira board, mastering jellyfish metrics, reviewing architecture documents, setting up measurement in our logging tool and coordinating deployments of our features. Because my team is small and our product roadmap is pretty well defined, these tasks do not take 40 hours per week. I feel like I have nothing to do. I've tried to improve the velocity of the team by doing some coding and triaging on bugs. I miss doing the technical work and feel like I could do more but I also want the other 2 engineers on the team to own most of the big, bulky tasks. What do you suggest I do? Should I enjoy my light load or should I be looking for other ways to add value? I am the lead developer on a few projects with developers that have 20+ years of experience compared to my eight years. I have been made lead of the projects, but I've never actually had management tell the team that I am the lead or that I have any control whatsoever on the members of the team (typical ‘all of the responsibility, none of the power' scenario). One of my teammates is tough. He writes unreadable but working spaghetti code. He also works in the field and will often times push to master and then leave to perform fieldwork, leaving the team in the lurch for several days before he can come back and fix his broken code. He habitually fails to push code, often holding the source on his own computer for months before pushing. I have mandated using pre-commit hooks to guard against breaking the build, but as IT has control over the repositories, these become “optional” and appear to be disregarded. I have brought this up with management, to no avail; the behavior continues. I have also expressed my concerns with management, and provided data on the impact this has to the project via tickets and time spent between the remaining team members. How do I rein in this unwieldy developer? What else can I do? Show Notes https://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php?page=4