Podcasts about Pair programming

What if your team didn't need branches at all?

Matt and Ben explore the new world of AI-assisted coding: is it like pairing with junior developer? Matt gets the recording working the second time, Ben worries about what happens when your business depends on code you don't understand.

On this episode of the Modern Web Podcast, Rob Ocel and Adam Rackis talk with Noah Harris, Senior Engineering Manager at Launch, to discuss the impact of mob programming and how it can transform engineering teams. Noah shares how pairing and mobbing helped him rapidly level up in his early career, how it fosters stronger communication, and why it's particularly valuable for remote teams.The conversation also explores engineering leadership, breaking past career plateaus, and the importance of soft skills in advancing your career. Noah shares insights on servant leadership, how engineers can take ownership without waiting for permission, and the role of code reviews in shaping strong technical leaders.Key Points Mob Programming for Team Growth – Noah explains how mob programming enhances collaboration, speeds up knowledge sharing, and improves code quality, especially in remote teams. The Role of Pair Programming in Skill Development – Pairing with experienced engineers helped Noah rapidly learn JavaScript and asynchronous programming, reinforcing the importance of hands-on mentorship. Breaking the Engineering Career Ceiling – Engineers looking to step into leadership roles need to be proactive, take ownership, and engage in code reviews to build influence and credibility. Servant Leadership & Soft Skills Matter – Leadership isn't about authority—it's about removing blockers, supporting the team, and improving communication. Engineers who master this mindset naturally transition into leadership roles.Follow Noah Harris on Social MediaLinkedIn: https://www.linkedin.com/in/nharris31/BlueSky: https://bsky.app/profile/nharris31.bsky.social

Artificial intelligence is radically transforming software development. AI-assisted coding tools are generating billions in investment, promising faster development cycles, and shifting engineering roles from code authors to code editors. But how does this impact software quality, security, and team dynamics? How can product teams embrace AI without falling into the hype? In this episode, AI assisted Agile expert Mike Gehard shares his hands-on experiments with AI in software development. From his deep background at Pivotal Labs to his current work pushing the boundaries of AI-assisted coding, Mike reveals how AI tools can amplify quality practices, speed up prototyping, and even challenge the way we think about source code. He discusses the future of pair programming, the evolving role of test-driven development, and how engineers can better focus on delivering user value. Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Inside the episode... Mike's background at Pivotal Labs and why he kept returning How AI is changing the way we think about source code as a liability Why test-driven development still matters in an AI-assisted world The future of pair programming with AI copilots The importance of designing better software in an AI-driven development process Using AI to prototype faster and build user-facing value sooner Lessons learned from real-world experiments with AI-driven development The risks of AI-assisted software, from hallucinations to security Mentioned in this episode Mike's Substack: https://aiassistedagiledevelopment.substack.com/ Mike's Github repo: https://github.com/mikegehard/ai-assisted-agile-development Pivotal Labs: https://en.wikipedia.org/wiki/Pivotal_Labs 12-Factor Apps: https://12factor.net/  GitHub Copilot: https://github.com/features/copilot Cloud Foundry: https://en.wikipedia.org/wiki/Cloud_Foundry Lean Startup by Eric Ries: https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898 Refactoring by Martin Fowler and Kent Beck https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599 Dependabot: https://github.com/dependabot Tessl CEO Guy Podjarny's talk: https://youtu.be/e1a3WuxTY-k  Aider AI Pair programming terminal: https://aider.chat/ Gemini LLM: https://gemini.google.com/app Perplexity AI: https://www.perplexity.ai/ DeepSeek: https://www.deepseek.com/ Ian Cooper's talk on TDD: https://www.youtube.com/watch?v=IN9lftH0cJc Mike's newest Mountain Bike IBIS Ripmo V2S: https://www.ibiscycles.com/bikes/past-models/ripmo-v2s Mike's recommended house slippers: https://us.giesswein.com/collections/mens-wool-slippers/products/wool-slippers-dannheim Sorba Chattanooga Mountain Biking Trails: https://www.sorbachattanooga.org/localtrails Subscribe to the Convergence podcast wherever you get podcasts, including video episodes on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5-star review and like the podcast on YouTube. It's how we grow.

In dieser Episode des Podcasts geht es um die wesentlichen Kompetenzen, die moderne Softwareentwickler benötigen, um erfolgreich in agilen Umgebungen zu arbeiten. Ich spreche über die Bedeutung von Testautomatisierung, DevOps-Kenntnissen, agilem Arbeiten, Pair- und Mob Programming, Kommunikation, kontinuierlichem Lernen und Innovationskompetenz. Diese Fähigkeiten sind entscheidend, um in der heutigen Softwareentwicklung erfolgreich zu sein und agile Transformationen in Unternehmen voranzutreiben. Viel Spaß beim Reinhören

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereAdrienne Braganza Tacke - Senior Developer Advocate at Cisco & Author of "Looks Good To Me: Constructive Code Reviews"Paul Slaughter - Staff Fullstack Engineer at GitLab & Creator of Conventional CommentsRESOURCESAdriennehttps://x.com/AdrienneTackehttps://github.com/AdrienneTackehttps://www.linkedin.com/in/adriennetackehttps://www.instagram.com/adriennetackehttps://www.adrienne.iohttps://blog.adrienne.ioPaulhttps://x.com/souldzinhttps://github.com/souldzinhttps://gitlab.com/pslaughterhttps://gitlab.com/souldzinhttps://souldzin.comDESCRIPTIONPaul Slaughter and Adrienne Braganza Tacke delve into the critical role of communication in code reviews, emphasizing how soft skills can significantly enhance the engineering process. Adrienne, drawing insights from her upcoming book, explores the expectations for software engineers in code reviews, offers practical tips for improving communication, and shares her unique perspective on the parallels between writing and reviewing code.Their conversation highlights the importance of fostering a positive feedback culture and leading by example to create a collaborative environment within teams.RECOMMENDED BOOKSAdrienne Braganza Tacke • "Looks Good to Me": Constructive Code ReviewsAdrienne Braganza Tacke • Coding for KidsGrace Huang • Code Reviews in TechMartin Fowler • RefactoringMatthew Skelton & Manuel Pais • Team TopologiesDave Thomas & Andy Hunt • The Pragmatic ProgrammerBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Rob Ocel and co-hosts Tracy Lee, Adam Rackis, and Danny Thompson talk with tech educator Ankita Kulkarni about her journey from engineering leader to full-time educator. Ankita shares insights on teaching Next.js, bridging practical knowledge gaps, and helping developers tackle real-world challenges. They discuss Next.js as a React-based framework, its benefits, and the challenges it presents for beginners. Chapters Introduction to the Podcast and Guests 00:01   Meet Ankita Kulkarni, Tech Educator 00:26    Ankita's Transition to Full-Time Education 01:41    Teaching Practical Knowledge in Next.js 03:19    Effective Methods for Teaching Next.js 05:27   Challenges of Being a Full-Time Educator 07:48   Balancing Broad and Specific Examples 09:54    Embracing Mistakes as a Teaching Tool 12:13   Pair Programming and Mentorship 14:00    Discussion on Next.js and Framework Adoption 16:48    Advantages and Challenges of Next.js 18:12   Choosing the Right Framework for Your Needs 20:35    Impact of Next.js in React Documentation 22:26    Learning Paths for New Developers 23:24    The Rise of Full-Stack Web Development 25:09    Benefits of Frameworks Abstracting Complexity 26:27    OpenNext and Deployment Flexibility 28:06  Ankita's Excitement for New Next.js Features 30:35   The Future of Next.js Without Vercel 32:16   Final Thoughts and Where to Find Everyone Online 34:21 Follow Ankita Kulkarni on Social Media  Twitter: https://x.com/kulkarniankita9 YouTube: https://www.youtube.com/@kulkarniankita Sponsored by This Dot: thisdot.co

In this episode of the Modern Web Podcast, host Rob Ocel is joined by Adam Rackis, Danny Thompson, and guest Braydon Coyer, Senior Front-End Developer at LogicGate to talk about using Angular Signals for improved state management and DOM performance. Braydon explains how Signals simplify Angular development and offer better readability and efficiency compared to traditional methods like RxJS. The conversation also touches on hiring in the AI era, discussing challenges around take-home tests and live coding, and how AI tools like ChatGPT are changing the interview process. Chapters 00:00 - Introduction   00:57 - The Angular Renaissance   02:24 - Signals in Angular   03:27 - Transitioning to Signals   04:19 - Signals in Utility Development   05:09 - RxJS and Signals   07:52 - Signals vs Other State Management Solutions   09:34 - Testing Signals   10:29 - Control Flow and Standalone Components in Angular   12:02 - Angular's Evolution and Accessibility   13:28 - Angular's Framework Governance   17:10 - Hiring in the Age of AI   19:15 - Pair Programming and Real-Time Problem Solving   22:24 - The Role of AI in Interviews   27:58 - Wrapping Up Follow Braydon Coyer on Social Media Twitter: https://x.com/BraydonCoyer Linkedin: https://www.linkedin.com/in/braydon-coyer/ Github: https://github.com/braydoncoyer

Ein Code Retreat ist eine ganztägige Veranstaltung für Entwickler:innen mit einem speziellen Format, um Code-Design-Praktiken, Pair Programming und Refactoring zu üben. In dieser Episode sprechen Marco Emrich und Eberhard über diesen Ansatz - und führen ihn auch live vor, um einen praktischen Eindruck zu vermitteln, wie ein Code Retreat tatsächlich funktioniert. Wer Lust auf mehr hat: Am 2024-11-08 und 2024-11-09 ist der Global Day of Code Retreat mit vielen öffentlichen Code Retreats. Mehr Informationen und eine Liste von Veranstaltungen gibt es hier. Links Code Retreat Website Game of Life Life in Life Game of Life Erklärungsposter CodeRetreat Intro Episoden zu Refactoring Episoden zu Tidy First Crew Ressource Management - Wie geht die Luftfahrt mit dem Faktor Mensch um?

In this episode, we cover "Pair Programming" written by the inimitable Matt Hamlin. We talk about what pair programming is, why you might do it, and when you maybe shouldn't. In other news, Joe forgets how to intro the show and Evan drank too much coffee before recording.

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereGojko Adzic - Software Delivery Consultant & Author of "Lizard Optimization" and many more BooksDave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.RESOURCESGojkohttps://twitter.com/gojkoadzichttps://www.linkedin.com/in/gojkohttps://github.com/gojkohttps://gojko.netDavehttps://twitter.com/davefarley77https://linkedin.com/in/dave-farley-a67927http://www.continuous-delivery.co.ukhttp://www.davefarley.netDESCRIPTIONDave Farley and Gojko Adzic discuss Gojko's latest book “Llizard Optimization”, which involves identifying and leveraging unconventional uses and misuses of products to improve them for all users. Gojko shares insights and examples from his experiences with Narakeet and MindMup, highlighting how addressing the needs of outlier users led to significant product enhancements and growth.They also touch on broader themes of user retention, the joy of building and solving problems, and the balance between solo work and collaborative efforts in software development and writing.RECOMMENDED BOOKSGojko Adzic • Lizard OptimizationGojko Adzic • Impact MappingAdzic, Evans & Roden • Fifty Quick Ideas To Improve Your TestsAdzic, Evans & Korac • Fifty Quick Ideas to Improve Your User StoriesAdzic & Korac • Humans vs ComputersGojko Adzic • Specification by ExampleAdzic, Marcetic & Bisset • Bridging the Communication GapAdzic & Korac • Running ServerlessKat Holmes • MismatchDavid Farley • Modern Software EngineeringDave Farley • Continuous Delivery PipelinesDave Farley & Jez Humble • Continuous DeliveryTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

BONUS: Mastering Remote Work in Agile Teams With Antony Marcano NOTE: We want to thank the folks at Tuple.app for being so generous with their stories, and supporting the podcast. Visit tuple.app/scrum and share them if you find the app useful! Remember, sharing is caring!   In this BONUS episode, Antony, co-founder of RiverGlide and Head of Engineering at Ford Digital, joins us to share his experiences and insights from 30 years in software development, including 25 years in Agile practices. As a technical practitioner, leader, and consultant, Antony reflects on navigating remote work, overcoming challenges, and setting up successful remote software teams, while exploring future trends in the industry. The Shift to Fully Remote Work Antony reflects on his first fully remote software project, which took place during the pandemic when everyone was forced to work from home. While his team had been working together for 12 months, they struggled with traditional video conferencing tools that lacked the ability to support pair programming or mob programming effectively. This is when Antony and his team discovered Tuple, a tool that allows for seamless control sharing and a co-located pairing experience. "Switching to Tuple was a game-changer for us in making remote pairing feel as interactive as in-person collaboration." Overcoming Challenges in Remote Collaboration The biggest challenge Antony identifies in remote work is the loss of serendipitous moments—those random watercooler conversations that often lead to innovation. To address this, Antony encourages teams to create opportunities for these moments by structuring time for informal interactions and fostering a safe and open communication culture. "You can't recreate the watercooler, but you can create opportunities for innovation by encouraging open-door policies and setting up shared virtual spaces." Building Effective Remote Teams For Antony, real collaboration is critical to the success of remote teams. He grew up on XP (Extreme Programming) and believes in the power of pairing and mob programming. Antony emphasizes the importance of maintaining good practices from in-person work, such as prioritizing mental well-being, while adapting to the unique needs of remote teams. "Collaboration is not just about tools—it's about mental well-being, trust, and giving the team what they need to succeed." Keeping Teams on Track with Clear Goals Antony shares his approach to ensuring that teams remain aligned with clear goals and progress tracking. His teams focus on delivering small, incremental slices of work and using techniques like limiting Work In Progress (WIP). Rather than viewing user stories as a list of tasks, Antony encourages teams to focus on the user benefit and desired outcomes. "It's about the ‘why,' not just the ‘what.' User stories should focus on the goal, not just be a list of tasks." The Future of Remote Work in Software Development Looking ahead, Antony predicts that tools will continue to evolve, with AI playing a more significant role in software development. He discusses the possibility of having AI participants in pairing sessions and shares his concerns about the convergence of tools that may lose focus over time. Antony encourages developers to experiment with new technologies and remain open to change. "AI is the next frontier in software development, and we need to embrace how it can enhance our remote work experiences." Recommended Resources for Mastering Remote Work Antony notes that while many resources on remote work are often too generic, there are valuable tools and practices software teams can adopt. He recommends regularly rotating hosts during remote pairing sessions and setting aside time for retrospectives and discussions about the bigger 'why' behind the work. "When pairing, rotate roles, reflect regularly, and always focus on the bigger ‘why' to keep your team aligned and motivated." About Antony Marcano Antony is the co-founder of RiverGlide and Head of Engineering at Ford Digital. With 30 years of software development experience, including 25 years in Agile practices, he is a respected leader, coach, and consultant. Antony has contributed to books and journals and is a keynote speaker at global conferences and universities such as Oxford and McGill. He is also the co-creator of 'PairWith.Us,' and remains a hands-on technical practitioner, specializing in Agile development and leading teams to excel in agility. You can link with Antony on LinkedIn visit RiverGlide.com, or check out RiverGlide TV on YouTube.

BONUS: Mastering Product Management in a Remote World, Insights from Tuple's Head of Product, Eli Goodman NOTE: We want to thank the folks at Tuple.app for being so generous with their stories, and supporting the podcast. Visit tuple.app/scrum and share them if you find the app useful! Remember, sharing is caring!   In this episode, Eli Goodman, Head of Product at Tuple, shares insights from his extensive experience in software development and product management. Having transitioned from engineering management to product leadership, Eli reveals the key strategies Tuple uses to develop its remote pair programming service, which is trusted by companies like Figma and Shopify. Tune in to discover how Tuple handles remote team dynamics, customer-driven development, and balances tech debt with client needs, all while maintaining a customer-centric focus. Introduction to Tuple and Why It's Unique Tuple, a remote pair programming service designed by engineers, solves a pain point that its founders, all pairing enthusiasts, experienced firsthand. They were unsatisfied with generic screen-sharing tools that disrupted the flow of coding collaboration. Tuple's product philosophy is about staying "one inch wide, one mile deep" to ensure the tool stays focused on enhancing the pairing experience without getting in the way. "The details matter. Generic screen-sharing tools just don't cut it for productive pairing." Managing a Remote Team at Tuple Managing a distributed team across the U.S. and Europe comes with its challenges. Eli highlights the importance of alignment and ensuring everyone is on the same page, despite working remotely. He emphasizes the role of Product Owners as "connective tissue" and the power of connecting team members with key initiatives. Through personal conversations, Eli uncovers what motivates his team, allowing him to support them without micromanaging. "What makes you proud? What brings you shame? Understanding these emotions helps uncover what drives our team." Ensuring Effective Communication in a Remote Environment Effective communication is the backbone of remote work, and Eli shares some of the practices that have helped Tuple's team stay aligned and collaborative. From using spontaneous pairing sessions to fostering a culture of checking in, Tuple has created a remote work environment where conversations are naturally sparked, and collaboration is effortless. "We have more space in our schedules for spontaneous pairing, which keeps collaboration flowing." Lessons Learned from Pairing Remotely One of the key insights Eli shares is how Tuple has evolved its remote pairing process. In the past, pairing might have felt like a formal meeting, but now it happens more spontaneously. Tuple's app facilitates this by offering the metaphor of a phone call—engineers can call each other at any time, making collaboration easy, especially when someone is deep into a task and needs quick support. "At Tuple, engineers only have three meetings a week, leaving the rest of the time open for pairing and creative work." Pairing Beyond Programming Tasks While pairing is typically associated with programming, Eli explains how Tuple uses pairing for other activities, like design or planning sessions. This practice has extended beyond coding, fostering a culture where team members collaborate on various tasks that benefit from shared perspectives and live problem-solving. "We've expanded pairing beyond coding, using it for activities like design reviews and project planning." Balancing Customer Feedback with Product Vision Responding to customer feedback is vital, but it can also lead to losing focus. Eli explains how Tuple balances this by capturing as much feedback as possible, using tools like Product Board to keep track of customer requests. However, instead of building every requested feature, Eli focuses on synthesizing broader patterns and emotional triggers that align with Tuple's long-term vision. "Focus on discovery as a product person. Understand the emotional context behind customer feedback—that's what drives great products." Tuple's Ideal Customer and Core Value Tuple's ideal customers are teams that value deep collaboration through pair programming. The platform's most important offering is the ability to make remote pairing seamless and intuitive, something traditional tools fail to deliver. "Tuple is built for teams that believe in the power of collaboration and want a tool that enhances their pairing experience, not disrupts it." Roadmapping: How to Prioritize the Right Work in Product Development Looking ahead, Eli shares Tuple's plans to continue investing in quality and lowering the barriers to remote pairing. One exciting potential direction includes creating a "social layer" within the app to help users feel more connected with their teammates. Another idea is incorporating non-human pairing agents that could assist with specific tasks. "We want to see if we can make it feel like you're right there with your teammates, lowering the barriers to start pairing." Recommended Resources Eli recommends The Mom Test by Rob Fitzpatrick, a must-read for anyone working in product management. The book teaches how to talk to customers in a way that gets honest, useful feedback rather than polite responses that don't help improve the product. "I thought caring about people was enough to talk to customers, but The Mom Test taught me what not to do during customer interviews." About Eli Goodman Eli Goodman has been working on software teams for 17 years. He's been a full-stack developer and engineering manager at both large and small companies, including Etsy and Headspace. A few years ago, Eli transitioned to product management and is now the Head of Product at Tuple, a remote pair programming service used by companies such as Figma, Shopify, and many others in the software industry. You can link with Eli Goodman on LinkedIn, or email Eli at Eli@Tuple.app.

Join us in the latest episode of "The Engineering Room," a monthly series featuring long-form discussions with influential figures in software development. In this episode, Dave talks with Dragan Stepanović, a principal engineer renowned for his efforts to evolve engineering cultures and eliminate bottlenecks. Dragan shares his journey in extreme programming (XP), emphasizing its profound impact on building collaborative and efficient teams. He dives into his fascinating research on pull requests, where he analyzed over 40,000 pull requests to uncover patterns in code review processes.If you're passionate about enhancing your software development practices through proven methodologies, this discussion is a must-watch. Remember, only our Patreon supporters get access to the full video episodes of The Engineering Room - thank you for all your support!----Dragan on X/Twitter - https://x.com/d_stepanovic?lang=en Dragan's Blog Posts - https://dragan-stepanovic.github.io/Patreon: https://www.patreon.com/continuousdelivery

In this insightful episode of the Mob Mentality Show, we sit down with Michael K Sahota to dive deep into the transformative power of **Mob Programming** and **Pair Programming** in dissolving the ego and enhancing team dynamics. Michael shares his unique perspective on how mobbing/pairing can lead to profound psychological shifts, ultimately boosting team function, empathy, and humility. ### Key Highlights: **Pair/Mob to Dissolve the Ego and Increase Team Function** - Michael discusses the **primary goal** of a mob or pair session, revealing how it goes beyond just writing code or learning new techniques. It's about dissolving the individual ego and fostering a collective, empathic mindset that benefits the entire team. - We explore Michael's **personal journey** with his ego, offering a candid look at how pairing/mobbing have helped him grow both personally and professionally. - What is the most **significant outcome** of mobbing/pairing beyond the immediate code or learning? Michael explains how the real magic happens when team members listen to each other and take turns, creating a powerful forcing function for collaboration and psychological safety. - We dive into the **psychological processes** that occur during mobbing, including the death of "fear-based clinging" and how healing the ego leads to deeper empathy and humility. Michael offers anecdotes on how mobbing helps resolve internal conflicts and improve relationships—both at work and beyond. - How much time should be allocated for **production** versus focusing on **production capability**? Michael discusses how to strike the right balance between learning and output, avoiding over-indexing on either side. - A unique **"learning theft"** example highlights why juniors should be prioritized during experiments, while senior developers are encouraged to go last—except when it comes to admitting mistakes, where the inverse applies. **Pair/Mob for Production Capability and Beyond** - Michael shares his thoughts on balancing the **development of production capability** with immediate production needs. He explains how overinvesting in production at the expense of capability can destroy long-term results. - We explore how improving production capability with a solid **ROI** can often yield results within a quarter, but must be continually nurtured through retrospectives and lean thinking. - Breaking the cycle of **overinvesting in production** under intense pressure is a major challenge for many teams. Michael shares stories of how transparency in communication, both within and outside the team, can help break this cycle. - Michael introduces the concept of building **culture bubbles** and we share contrasting ideas on how much courage is needed for these bubbles.   - We also discuss the **HIPPO effect** and how mobbing can disrupt this dynamic by emphasizing experimentation and collective decision-making rather than deference to authority. - Finally, Michael ties it all together by emphasizing the role of **humility**. No one is a flawless expert, and through mobbing/pairing, teams can build a habit of asking for help and embracing the idea that everyone, regardless of experience, has something to learn and improve. ### Why You Should Watch: This episode is a must-watch for anyone involved in **software development**, team dynamics, or leadership. Whether you're interested in improving psychological safety, fostering team empathy, or enhancing production capability, Michael K Sahota's insights on mobbing and ego dissolution will help you rethink how teams work together. It's about more than code—it's about creating a culture of **trust, engagement**, and continuous improvement. Video and Show Notes: https://youtu.be/Wj2hYGMei8s 

Jake and Michael discuss all the latest Laravel releases, tutorials, and happenings in the Laravel community.This episode is sponsored by Honeybadger - move fast and fix things with application monitoring that helps developers get it done.Show linksLaravel News SwagChaperone Eloquent Models in Laravel 11.22 Chaperone, Defer, Cache::flexible, and more are now available in Laravel 11.23 Laravel raises a $57 million Series A from Accel Pest 3 is released! Laravel Herd v1.11 Adds Forge Integration, Dump Updates, and More in v1.11 Ben Holmen: Building Connections and Friendships through Pair Programming with Strangers TemPHPest PHP Extension for VSCode Eloquent Filtering Package UnoPim is a Product Information Management System Built With Laravel Prezet: Markdown Blogging for Laravel Prepare your Laravel app for the cloud Laracon AU - final early bird tickets on sale

In this episode, we discuss the critical importance of career security over job security in the changing tech landscape, highlighting strategies for sustaining and advancing one's career in 2024. Then, we explore the Innovation Framework based on the Möbius Loop for balancing discovery, delivery, and options in the software development life cycle. We also urge organisations to consider capturing structured practices with the Open Practice Library. Additionally, we discuss the value of pair programming and mob programming for strengthening collaboration, learning, and problem-solving. 00:00 Hey! 00:25 We Are Slowing Figuring Out The Show Format and Target Audience 02:09 Politics - The Morning After The Night Before - EU and Hungarian Election Results 04:21 Artistic Pairing - The Twin Peaks Soundtrack 12:30 Pair Programming and Collaboration 24:08 What's Old Is New in Tech 30:36 How to maintain career security in the 2024 tech climate? 46:22 A Framework for Innovation 50:37 Implementing Standard Practices 01:08:47 Wrapping Up

Hands-On als Engineering Manager: Yay or Nei? Leute, die einmal das Handwerk des Software-Engineerings professionell ausgeübt haben und dann ins Management wechseln, haben oft den Drang, ihr Hardskills nicht zu verlieren. Doch durch den neuen Job sind die Prioritäten nun andere: People Leadership, das Team effizient halten, Strategie und Roadmaps entwickeln. Wo bleibt denn da noch die Zeit am Code mitzuarbeiten?Wir stellen uns die Frage: Warum ist das so? Muss das sein, dass Manager weiterhin technisch sind? Und wenn ja, welche Gefahren birgt das? Aber auch: Wie können wir es möglich machen, obwohl unser Kalender sagt, dass die Woche mit Meetings bereits belegt ist?Darum geht es in dieser Episode. Viel Spaß!Bonus: Auch Manager laufen auf Kaffee.Das schnelle Feedback zur Episode:

Beim Topsharing teilen sich zwei Führungskräfte eine Führungsstelle. Das klingt zunächst wie pure Verschwendung. Die Personalkosten sind höher, es gibt erhöhten Abstimmungsbedarf und das Konfliktpotential wächst. Der Vergleich mit dem Pair Programming aus der agilen Softwareentwicklung zeigt aber: der kurzfristige Invest zahlt sich mittel- und langfristig doppelt und dreifach aus. Mehr dazu erfährst du in diesem Video oder im Buch "13 inspirierende Impulse für den Führungsalltag". Inhalt 0:00 Topsharing 1:48 Pair Programming 2:50 Nachteile von Topsharing 4:00 Vorteile von Pair Programming 4:40 Topsharing und VUCA 6:00 Führung in Teilzeit 6:45 Konflikte in einer Doppelspitze 7:45 Evaluation von Führung wwww.sascha-feth.de --- Send in a voice message: https://podcasters.spotify.com/pod/show/nebenbei-produktiv/message

Ben interviews Andreas Kling, creator of SerenityOS and the Ladybird browser. They talk about the concept of lifestyle software and how it relates to the development of SerenityOS, Andreas' vision of creating a Zen garden for developers, and the benefits of using a mono repo and a unified language in the development process. They also touch on the use of AI and language models for writing code, the art of using Copilot effectively, and the future of LLMs in pair programming.Enjoy!LinksTuple.app - The best app for pair programmingAndreas' YouTube Channel - The home for Serenity, Ladybird, and other updates from AndreasSerenityOS - The operating system Andreas builtLadybird - The browser Andreas builtKey TakeawaysSerenity OS is an example of lifestyle software, where the focus is on the happiness of the developers and the joy of programming.The use of a mono repo and a unified language in Serenity OS allows for efficient development and easy cross-cutting changes.Onboarding new contributors by encouraging them to explore and find their own areas of interest leads to a diverse range of contributions.Raw coding videos and pair programming can be powerful tools for knowledge sharing and learning.Having a long-term vision and setting ambitious goals can help overcome the challenges of monumental projects.Continuous learning and improvement are essential for staying on top of new tools and technologies in the programming industry.Balancing programming and management responsibilities can be challenging, but leveraging the skills and expertise of a team can lead to greater productivity and growth. Building confidence in programming is crucial for productivity and success.Starting small and building miniature models can help understand complex concepts.Throwing away code and rebuilding with improved architecture can lead to better outcomes.Using AI and language models can significantly speed up coding tasks.Chapters(00:00) - Introduction (00:41) - Serenity OS and Lifestyle Software (03:40) - Building a Zen Garden for Developers (09:07) - Mono Repo and Unified Language (11:29) - Easy Onboarding and Contributions (13:05) - The Power of Raw Coding Videos (15:48) - Pair Programming and Knowledge Sharing (24:06) - Facing Intimidation at the Start of Projects (26:18) - Maintaining a High Clock Speed (32:34) - Continuous Learning and Improvement (36:44) - Balancing Programming and Management (39:07) - The Joys and Challenges of Company Growth (40:13) - Coaching and Mentoring (41:40) - Building Confidence in Programming (42:49) - Building Miniature Models (43:41) - Building to Throw Away (46:45) - Learning from Senior Engineers (48:09) - Using AI and LLMs for Writing Code (51:47) - The Art of Using Copilot (54:27) - The Future of LLMs in Pair Programming (57:47) - The Evolution of Open Source Projects (01:03:44) - Establishing Community Rules Organically

In Elixir Wizards Office Hours Episode 2, "Discovery Discoveries," SmartLogic's Project Manager Alicia Brindisi and VP of Delivery Bri LaVorgna join Elixir Wizards Sundi Myint and Owen Bickford on an exploratory journey through the discovery phase of the software development lifecycle. This episode highlights how collaboration and communication transform the client-project team dynamic into a customized expedition. The goal of discovery is to reveal clear business goals, understand the end user, pinpoint key project objectives, and meticulously document the path forward in a Product Requirements Document (PRD). The discussion emphasizes the importance of fostering transparency, trust, and open communication. Through a mutual exchange of ideas, we are able to create the most tailored, efficient solutions that meet the client's current goals and their vision for the future. Key topics discussed in this episode: Mastering the art of tailored, collaborative discovery Navigating business landscapes and user experiences with empathy Sculpting project objectives and architectural blueprints Continuously capturing discoveries and refining documentation Striking the perfect balance between flexibility and structured processes Steering clear of scope creep while managing expectations Tapping into collective wisdom for ongoing discovery Building and sustaining a foundation of trust and transparency Links mentioned in this episode: https://smartlogic.io/ Follow SmartLogic on social media: https://twitter.com/smartlogic Contact Bri: bri@smartlogic.io What is a PRD? https://en.wikipedia.org/wiki/Productrequirementsdocument Special Guests: Alicia Brindisi and Bri LaVorgna.

The Elixir Wizards Podcast is back with Season 12 Office Hours, where we talk with the internal SmartLogic team about the stages of the software development lifecycle. For the season premiere, "Testing 1, 2, 3," Joel Meador and Charles Suggs join us to discuss the nuances of software testing. In this episode, we discuss everything from testing philosophies to test driven development (TDD), integration, and end-user testing. Our guests share real-world experiences that highlight the benefits of thorough testing, challenges like test maintenance, and problem-solving for complex production environments. Key topics discussed in this episode: How to find a balance that's cost-effective and practical while testing Balancing test coverage and development speed The importance of clear test plans and goals So many tests: Unit testing, integration testing, acceptance testing, penetration testing, automated vs. manual testing Agile vs. Waterfall methodologies Writing readable and maintainable tests Testing edge cases and unexpected scenarios Testing as a form of documentation and communication Advice for developers looking to improve testing practices Continuous integration and deployment Links mentioned: https://smartlogic.io/ Watch this episode on YouTube! youtu.be/unx5AIvSdc Bob Martin “Clean Code” videos - “Uncle Bob”: http://cleancoder.com/ JUnit 5 Testing for Java and the JVM https://junit.org/junit5/ ExUnit Testing for Elixir https://hexdocs.pm/exunit/ExUnit.html Code-Level Testing of Smalltalk Applications https://www.cs.ubc.ca/~murphy/stworkshop/28-7.html Agile Manifesto https://agilemanifesto.org/ Old Man Yells at Cloud https://i.kym-cdn.com/entries/icons/original/000/019/304/old.jpg TDD: Test Driven Development https://www.agilealliance.org/glossary/tdd/ Perl Programming Language https://www.perl.org/ Protractor Test Framework for Angular and AngularJS protractortest.org/#/ Waterfall Project Management https://business.adobe.com/blog/basics/waterfall CodeSync Leveling up at Bleacher Report A cautionary tale - PETER HASTIE https://www.youtube.com/watch?v=P4SzZCwB8B4 Mix ecto.dump https://hexdocs.pm/ectosql/Mix.Tasks.Ecto.Dump.html Apache JMeter Load Testing in Java https://jmeter.apache.org/ Pentest Tools Collection - Penetration Testing https://github.com/arch3rPro/PentestTools The Road to 2 Million Websocket Connections in Phoenix https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections Donate to Miami Indians of Indiana https://www.miamiindians.org/take-action Joel Meador on Tumblr https://joelmeador.tumblr.com/ Special Guests: Charles Suggs and Joel Meador.

In today's episode, Andrew and Julie dive into the topic of onboarding onto new teams.  Julie discusses her latest venture of switching teams, and Andrew sheds light on the innovative “Shape Up” method by Basecamp that's shaking things up in the project management world, and why he prefers this over Agile. There's talk of the dreaded technical debt, and how to keep it in check, plus the perks of pair programming and the need for a solid support system at work. Besides tackling these workplace issues, they also touch on the challenge of maintaining personal relationships in a remote working environment, keeping old team ties strong, and why asking questions is key to professional growth. Press download now to hear more! [00:01:45] Julie gives us an update on the changes at her work, transitioning from a consumer team to a platform team. She mentions that her old team is shifting from two-week sprints to a new process called “Shape Up,” which Andrew explains it as a product/project management philosophy from Basecamp, focusing on a six-week cycle.[00:03:08] Andrew details the process of shaping a feature, setting boundaries, identifying risks, and then pitching it. [00:04:25] Julie inquires about the involvement of engineers in the shaping and betting processes, and Andrew describes how it works at Podia, and how they used Flipper. [00:06:33] Andrew discusses the “cool down” period after a project cycle, which at Podia involves monitoring for bugs and wrapping up the project details rather than no scheduled work. [00:07:42] The topic of technical debt is addressed, with Andrew acknowledging its inevitability and the importance of staying on top of it through practices like support weeks.[00:10:54] Andrew expresses preference for the Shape Up process over Agile, appreciating the longer time frames, collaborative problem-solving with designers, and a less stressful experience with more planned projects. [00:12:14] Julie shares her transition to a new team and the challenges of ramping up, contrasting it with her experience from two years ago and feeling the pressure to not ask basic questions due to her years of experience.[00:13:53] Julie discusses the pressure she feels to ramp up quickly on her new team, acknowledging its self-imposed. Andrew and Julie talks about the onboarding process, where Julie notes the benefit of scheduled pair programming sessions with teammates as a key part of her learning. [00:15:44] Andrew shares Podia's onboarding method, which involves acting like a user of the application to understand its various parts. Julie reflects on the complexity of her new team's codebase and the challenge of understanding how services interact. [00:17:51] Andrew suggest creating a service diagram to visualize service interactions, something he found useful in previous jobs.  Julie considers the idea and mentions the potential benefits of a detailed visual representation of the service interactions for her understanding. [00:19:48] Julie and Andrew discuss the social dynamics of joining a new team with established relationships and the extra challenge of doing it so remotely. Andrew shares similar experiences and the importance of being inclusive to new team members. [00:21:59] Andrew shares how he's an introvert by nature, and Julie and Andrew both agree on the importance of asking questions and having supportive seniors and leaders who encourage a culture of inquiry. [00:26:05] Julie talks about maintaining relationships with her old team and the value of keeping professional connections active, even after moving to a new team or company. Panelists:Andrew MasonJulie J.Sponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteShape UpFlipper (00:00) - Intro and Topic Overview (01:45) - Julie's Team Transition and Shape Up Method (03:08) - Andrew on Shaping a Feature in Shape Up (04:25) - Engineer Involvement in Shaping and Betting (06:33) - Podia's "Cool Down" Period After Project Cycles (07:42) - Addressing Technical Debt (10:54) - Preference for Shape Up Over Agile (12:14) - Julie's Transition and Ramping Up Challenges (13:53) - Onboarding Process and Pair Programming (15:44) - Podia's Onboarding Method (17:51) - Creating a Service Diagram for Understanding Interactions (19:48) - Social Dynamics of Joining a New Team Remotely (21:59) - Importance of Asking Questions and Supportive Culture (26:05) - Maintaining Relationships with Old Teams

In this episode of the Laravel Podcast we are packing it in! We're diving into the freshest drops, like FrankenPHP, Cashier Quickstarts, and the buzz about the upcoming Laravel Worldwide Meetup. We'll also weigh Cashier against Spark, discuss boot service providers for all your apps, pit Pest versus PHPUnit for testing, and get into the details of how we manage our teams.Taylor Otwell's Twitter - https://twitter.com/taylorotwellMatt Stauffer's Twitter - https://twitter.com/stauffermattLaravel Twitter - https://twitter.com/laravelphpLaravel Website - https://laravel.com/Tighten.co - https://tighten.com/Taylor and Ramus Tweet - https://x.com/taylorotwell/status/1732607829239116057?s=20Chris Fidao Frankenphp video - https://youtu.be/q6FQaaFZVy4?si=MU1AAi7-UNgLH-NiLaravel Worldwide Meetup - meetup.laravel.comColin DeCarlo Twitter -  https://twitter.com/colindecarloVehikl Twitter -  https://twitter.com/vehiklCashier Quick Start -  https://laravel.com/docs/10.x/billing#quickstartDries Vints Twitter - https://twitter.com/driesvintsIan Landsman Twitter - https://twitter.com/ianlandsmanIan Boot Service Tweet: https://x.com/ianlandsman/status/1744903740329443588?s=20Eric Barnes Twitter - https://twitter.com/ericlbarnesTaylor Test Runner Poll Tweet -  https://x.com/taylorotwell/status/1744729110163988949?s=20Lambo - https://github.com/tighten/lamboMatt's video Pest as a Test Runner - https://www.youtube.com/watch?v=W3tfEtbMTEIRemote - https://basecamp.com/books/remoteLastlings - https://www.lastlings.com/Harry Styles - https://www.hstyles.co.uk/Don't Worry Darling - https://www.imdb.com/title/tt10731256/Spider Man soundtracks - https://music.apple.com/us/album/spider-man-into-the-spider-verse-soundtrack-from/1453876765 & https://music.apple.com/us/album/metro-boomin-presents-spider-man-across-the-spider/1690685331Jamila Woods - https://www.jamila-woods.com/-----Editing and transcription sponsored by Tighten.

In this episode of the PowerShell Podcast, we engage in a dynamic discussion with Kevin Cefalu. Kevin shares managerial insights, valuable lessons from the Summit, and the workings of Azure Durable Functions. The conversation shifts to the power of Pair Programming and Call for Presentations (CFP) and how this involved Andrew. We explore the usage of the .vscode folder and Plaster for workspace customization and conclude with Kevin's intriguing thoughts on AI applications. A powerful blend of knowledge, experience, and technology.   Guest Bio and links:  In the heart of southern Louisiana, a DevOps Engineering Manager masters the arts of C#.NET and PowerShell, wielding over a decade of experience with a Microsoft Azure wizard's touch. Away from the techno-tangle, he's a 3D printing enthusiast, gamer, and project tinkerer, often joined by his wife Linsay, daughter Olivia, and their pups Ajax and Callie. His world is a vibrant mix of tech mastery, playful hobbies, and joyful family moments. Watch The PowerShell Podcast on YouTube: https://www.youtube.com/watch?v=5CrUWrUKtCw https://discord.gg/pdq Podcast Survey: https://forms.office.com/r/dJXs31pAd3 https://blog.ironmansoftware.com/powershell-universal-apis-cve/ https://devblogs.microsoft.com/powershell/powershell-7-4-general-availability/ https://sid-500.com/2023/11/14/powershell-search-for-empty-folders-and-delete-them/ https://mdgrs.hashnode.dev/speeding-up-powershell-module-development-with-restartablesession https://www.powershellgallery.com/packages/VSTeam/7.2.0  

Does pair programming work when it is enforced?

O Hipsters: Fora de Controle é o podcast da Alura com notícias sobre Inteligência Artificial aplicada e todo esse novo mundo no qual estamos começando a engatinhar, e que você vai poder explorar conosco! Nesse episódio, conversamos com Axel Brando, do Barcelona Supercomputer Center, sobre a área de pesquisa no mundo da inteligência artificial, e sobre o uso de modelagem de incertezas nos modelos de IA. O papo também traz as notícias da semana, incluindo a ordem executiva assinada por Joe Biden para regulamentar parte do mercado de IA. Vem ver quem participou desse papo: Marcus Mendes, host fora de controle Axel Brando, Cientista da computação e matemático no Barcelona Supercomputer Center Fabrício Carraro, PO da Alura e host do podcast Dev Sem Fronteiras Sérgio Lopes, CTO da Alura

Konstantin Ribel: Rebuilding Scrum Team Dynamics To Overcome Remote Work Anti-Patterns Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Konstantin recounts a team's struggle rooted in prioritizing individual tasks over collective effort. Daily meetings centered on status updates fostered a fragmented and siloed work environment. The team working remote made the issue even worse, making it hard to have face-to-face interaction and pair-working. All of these patterns resulted in underperformance. Konstantin advises regular team gatherings, emphasizing the importance of on-site collaboration. He underscores the human element, urging teams to function cohesively as people. Featured Book Of The Week: The Miracle Morning by Hal Erold In this segment, Konstantin delves into how his morning routine, inspired by "The Miracle Morning," by Hal Erold has profoundly influenced his role as a Scrum Master. He emphasizes the critical link between personal and professional development, crediting the book "Extreme Programming Explained" for its condensed wisdom. Konstantin highlights Kent Beck's mantra of "do more of what works" and expresses a preference for pair working, acknowledging its occasional impracticality. He consistently applies the insights gained from this book, advocating against the anti-pattern of delayed feedback in his work with teams.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Konstantin Ribel Konstantin drives organizational success through innovative thinking, simplifying processes, and building high-performing teams. With a strong track record in change management and process optimization, he leads agile transformations and applies systems thinking for adaptable, thriving businesses in dynamic industries. You can link with Konstantin Ribel on LinkedIn. 

If two parents can run a family, why shouldn't two executives run a company? We dig into the research and hear firsthand stories of both triumph and disaster. Also: lessons from computer programmers, Simon and Garfunkel, and bears versus alligators.  RESOURCES:"How Allbirds Lost Its Way," by Suzanne Kapner (The Wall Street Journal, 2023)."Is It Time to Consider Co-C.E.O.s?" by Marc A. Feigen, Michael Jenkins, and Anton Warendh (Harvard Business Review, 2022)."The Costs and Benefits of Pair Programming," by Alistair Cockburn and Laurie Williams (2000)."Strengthening the Case for Pair Programming," by Laurie Williams, Robert R. Kessler, Ward Cunningham, and Ron Jeffries (IEEE Software, 2000).EXTRAS:"The Facts Are In: Two Parents Are Better Than One," by Freakonomics Radio (2023)."The Secret Life of a C.E.O.," series by Freakonomics Radio (2018-2023).

On today's episode, Dave, William and Steven have a conversation with the esteemed Esther Derby about the various roles that we take on as Team Members and Leaders when we're responsible for the team's results ORRR for the team's growth. Plus, an update straight out of the Bronx by our very own Michael Nunez about babies, software and otherwise, and the long road to 100. Regardless if you're Pair Programming, Mentoring the team, Mob programming, or Reviewing Code, these nine roles described by Champion, Kiel & McLendon really sum up ways that we can help our teammates. The roles include: Counselor, Coach, Parther Facilitator, Teacher, Modeler Reflective Observer, Technical adviser, Hands-on Expert. ^ Growth, Results > References: 6 Rules for Change (Esther Derby) - soon to be 7 rules! https://www.youtube.com/watch?v=BDyoUdVHwbg 9 Consulting Roles (Kiel, McLendon) https://www.researchgate.net/figure/Typical-Role-Statements-from-the-Consulting-Role-Grid-Champion-Kiel-Mclendon-1990_fig3_281781473

00:00 Intro 00:22 Why write Agile Discovery and Delivery 01:54 What is agile discovery? 04:52 Self forming teams 14:25 Get close to your customers 20:25 Pair Programming and Mob Programming - DevOps is not a tool DevOps is mindset 28:10 Learning never stops 29:00 Agile Discovery and Delivery 29:53 UW-Madison CIS is looking for partners 31:30 Outro Agile Discovery and Delivery Book - https://www.amazon.com/Agile-Discovery-Delivery-Engineers-Entrepreneurs/dp/B0CDFBVM5T/ref=sr_1_1?crid=2UL8PDXQIZGWE&keywords=agile+discovery+%26+delivery&qid=1693580454&sprefix=agile+dis%2Caps%2C169&sr=8-1 Amber Field Blog - https://amberrfield.com/ Contact Amber about partnering with University of Wisconsin CIS program to build products for your company at afield@wisc.edu Connect with Amber on LinkedIn at: https://www.linkedin.com/in/amber-field-3ba796b/ ---------------------------------------------------------------- Connect with us at the following places: Wisconsin Agility Training: https://wisconsinagility.com/training Advising: https://wisconsinagility.com/advising Merch: https://wisconsinagility.com/merch Jeff Bubolz Jeff Bubolz LinkedIn: https://www.linkedin.com/in/jeffbubolz/ Jeff Bubolz Twitter: https://twitter.com/JeffBubolz Chad Beier Chad Beier LinkedIn: https://www.linkedin.com/in/chadbeier/ Agile Songs YouTube: https://www.youtube.com/@agilesongs Agile Songs Shorts: https://www.youtube.com/@agilesongs/shorts Agile Songs Twitter: https://twitter.com/AgileSongs The Agile Wire Web: https://theagilewire.com Spotify: https://open.spotify.com/show/0YKEHJtcJXZ55ohsUOvklI Apple Podcasts: https://podcasts.apple.com/us/podcast/the-agile-wire/id1455057621 Agile Wire Clips: https://www.youtube.com/playlist?list=PLLl0ryedF7y7HWTsbur4ysdpUcY7tniSG Agile Wire Twitter: https://twitter.com/AgileWire Make sure you subscribe to the channel! #Scrum #Agile #ProfessionalScrum #Kanban #BusinessAgility

Todd and Thomas introduce The Modern Software Developer Series and examine the Battle Ship codebase. Grab the repo, follow along, and learn new modern software developer techniques. Battleship Case Studies can be found here: https://github.com/proscrumdev ⏩ Join Ryan and Todd for a Scrum.org course: https://buytickets.at/agileforhumansllc Todd and Ryan also co-authored a book - Fixing Your Scrum: Practical Solutions to Common Scrum Problems.

Ist GitHub Copilot (und AI) wirklich dein fehlender Partner beim Pair-Programming?AI und speziell auf die Programmierung trainierte Modelle sind angetreten, um die Welt, wie wir programmieren, zu verändern. Doch halten diese auch die Versprechen? GitHub Copilot ist der Platzhirsch im Markt. Viele Software-Entwickler*innen haben den Service bereits ausprobiert. Manche schwören darauf und wollen nicht mehr ohne. Manche sagen "Och, ganz nett", aber nutzen es nicht regelmäßig und andere wiederum, "hatten noch nicht die Zeit rein zu schauen".Wolfgang ist einer der Early Adopter und nutzt GitHub Copilot täglich. In dieser Episode teilt er seine Erfahrungen und wir sprechen über Themen wie GitHub Copilot effektiv genutzt werden kann, Training Bias, den möglichen Produktivitäts Boost, Bugs die durch die AI generiert werden, die Auslagerung von langweiligen Arbeiten und warum die Nutzung von solchen AI Modellen die Priorität Nummer 1 für euren CTO sein sollte.Bonus: Die richtige Schnitthöhe von Rasen bei Trockenperioden und ob Shell eine Programmiersprache ist.Unser Werbepartner: Pitch ClubDas „Reverse Recruiting Event“ - die Pitch Club Developer Edition (https://pcde.io).Unternehmen pitchen ihre Softwareprojekte und Jobs vor vorselektierten Softwareentwicklern: „Arbeitgeber bewerben sich umgekehrt bei Arbeitnehmern.“Pro Event pitchen 10 Unternehmen bei 60-80 vorselektierten Entwicklern, wobei jedes Unternehmen 6 Minuten Zeit hat.Bist du Entwickler⋅in und suchst eine neue Herausforderung? Ihr wollt mit euren Unternehmen dabei sein und pitchen? Dann findet ihr alle Informationen unter https://pcde.io Das schnelle Feedback zur Episode:

Interested in trying Duet? You can get on the waitlist here.You can learn more about tuning and deploying your own version of Google's foundation models in their Generative AI studio.If tuning your own model sounds overwhelming, you can head to Model Garden, where a wide selection of open-source and third-party models are available to try.Marcos is on LinkedIn.

Phoenix core team members Chris McCord and Jason Stiebs join Elixir Wizards Sundi Myint and Owen Bickford the growth of Phoenix and LiveView, the latest updates, and what they're excited to see in the future. They express excitement for the possibilities of machine learning, AI, and distributed systems and how these emerging technologies will enhance the user experience of Elixir and LiveView applications in the next decade. Key Topics Discussed in this Episode: How community contributions and feedback help improve Phoenix LiveView The addition of function components, declarative assigns, HEEx, and streams Why Ecto changesets should be used as "fire and forget" data structures Excitement about machine learning and AI with libraries like NX The possibility of distributed systems and actors in the future Verifying and solving issues in the Phoenix and LiveView issue trackers Why marketing plays a part in the adoption and mindshare of Phoenix How streams provide a primitive for arbitrarily large dynamic lists Elixir VM's ability to scale to millions of connections A creative use of form inputs for associations with dynamic children Links Mentioned in this Episode: Fly Site https://fly.io/ Keynote: The Road To LiveView 1.0 by Chris McCord | ElixirConf EU 2023 (https://youtu.be/FADQAnq0RpA) Keynote: I Was Wrong About LiveView by Jason Stiebs | ElixirConf 2022 (https://youtu.be/INgpJ3eIKZY) Phoenix Site https://www.phoenixframework.org/ Phoenix Github https://github.com/phoenixframework Two-Story, 10-Room Purple Martin House (https://suncatcherstudio.com/uploads/birds/birdhouses/purple-martin-house-plans/images-large/purple-martin-birdhouse-plans-labeled.png) Blog: The Road to 2 Million Websocket Connections in Phoenix (https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections) Raxx Elixir Webserver Interface https://hexdocs.pm/raxx/0.4.1/readme.html Livebook Site https://livebook.dev/ Sundi's 6'x 6' Phoenix painting (https://twitter.com/sundikhin/status/1663930854928728064) Surface on Hex https://hex.pm/packages/surface Axon Deep Learning Framework https://hexdocs.pm/axon/Axon.html Nx Numerical Elixir https://hexdocs.pm/nx/intro-to-nx.html Phoenix PubSub https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html Jason Stiebs on Twitter https://twitter.com/peregrine Jason Stiebs on Mastodon https://merveilles.town/@peregrine Special Guests: Chris McCord and Jason Stiebs.

Le pair programming est-il une évidence pour tous les devs et les managers ?  Quels sont les avantages de cette pratique ? Peut-elle être un levier d'émulation pour une équipe et un facteur d'attractivité pour l'entreprise ?  Quelle est sa valeur financière ? La ligne de code coûte t-elle plus cher en pair programming ?  Quels sont les mauvais côtés si tant est qu'il y en ait ?  On parle de tout cela dans le podcast d'aujourd'hui avec Nicolas Bonnavent.  Pour découvrir le cursus Artisan Développeur  : https://ad302.fr/KmhYNl  Pour suivre Nicolas Bonnavent : https://www.linkedin.com/in/nicolas-bonnavent-21943a193/?originalSubdomain=fr 

Want to learn more? Check out our membership! http://bit.ly/3IjHMEX We designed this circuit board for beginners! Kit-On-A-Shield: https://amzn.to/3lfWClU FOLLOW US ELSEWHERE ---------------------------------------------------  Facebook: https://www.facebook.com/ProgrammingElectronicsAcademy/ Twitter: https://twitter.com/ProgElecAcademy Website: https://www.programmingelectronics.com/

Jean Lave and Étienne Wenger, Situated Learning: Legitimate Peripheral Participation, 1991. Note: I'd say this is the least readable of the books I've covered so far, especially if you're allergic to jargon-heavy academic social science. On the plus side, it's only 123 pages (excluding bibliography and index). Étienne Wenger, Communities of Practice: Learning, Meaning, and Identity, 1998"I sure as hell am not going to share my knowledge here for free!"Edwin Hutchins, Cognition in the Wild, 1996CreditsThe episode image is "Apprentice" by Louis Emile Adan (1839-1937), circa 1914, original copyrighted by Braun&Co., N.Y., but copyright not renewed. This image is available from the United States Library of Congress and Wikimedia Commons.

In this conversation Oracle's Jim Grisanzio talks with Java developer Kaya Weers at JavaOne Las Vegas 2022 on remote pair programming from the IDE. Kaya also talked about her experiences at JavaOne and as a speaker at community events around the world this year. Kaya Weers, Java Developerhttps://twitter.com/KayaWeers Jim Grisanzio, Java Developer Relationshttps://twitter.com/jimgris Duke's Corner Podcasthttps://apple.co/3BLIgS1 Images from JavaOne Las Vegas 2022https://flic.kr/s/aHBqjAdP6P Podcast Video https://youtu.be/NM8CXAkn8y0  Dev Javahttps://dev.java/ Inside Javahttps://inside.java/  

How to handle anxiety in the interview pair programming?

For the last 8 years, the DORA team at Google has compiled the State of DevOps report. In this episode, we welcome Willian Correa, the VP of Technology at Rangle, to share with us his experience and insight into software delivery performance. We'll discuss the 4 metrics that are used to measure software delivery performance and then those activities identified by high-performing organizations. Hint, while the metrics and activities are no secret, the secret sauce is executing all of the best practices simultaneously. And, for a bit of spice, we discuss Extreme Programming and Pair Programming and uncover some myths about these strategies.https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-outwww.rangle.io https://twitter.com/wgcorreaCommercial at start of show: https://try.rollbar.com/angular

In this episode, Kaushik goes solo and interviews Ben Orenstein. Ben is a prolific Ruby developer, an amazing conference speaker, an ardent vim-ster, and now the CEO of Tuple.Kaushik has been a big fan of Ben's work and was super stoked to talk to Ben and pick his brains on a host of topics: starting the company Tuple, pair programming in general, learning different programming languages and technology, giving better conference talks and more!This episode is chock full of wisdom from Ben. Enjoy!LinksPragmatic ProgrammerTweet: Best Android Studio Pair Programming Servicelearntopair.com - Tuple's Pair programming guideSpeaking for HackersTuple App - OSSBen's talks:Refactoring from Good to Great by Ben OrensteinIdea to Validation to Launch - Microconf 2019Write code faster: expert-level vimContactBen is @r00k listen to his podcast - The Art of ProductFollow @fragmentedcast or our Youtube channel@donnfelker and donnfelker (on Instagram)kau.sh's blog or @kaushikgopal (on Twitter)

It was a pleasure to sit down and chat with Oliver, a full-stack software consultant based in South Wales, in the UK. We talked about so many things which I'm sure so many developers can relate to, even those who've only been developing for a relatively short period of time.Some key takeaways are: Both working remotely and working in an office have benefits and drawbacks. It's really up to the person and the organisation as to whether it will work or not, and both have to be professional and trust each other. Pair programming is a wonderful opportunity to learn the most unexpected things and to grow as developers Being in the same room as others can often feel much "warmer" than over a video link While working remotely can be more challenging to communicate fully, it can be done, if you're prepared to engage. Links PHP South Wales OliverDaviesLtd Drupal Pair programming Bus factor Guests: Oliver Davies (@opdavies).Hosted By: Matthew Setter.Thanks for tuning in to Free the Geek. If you'd like to be a guest on the podcast or know someone who'd make a great guest, email me: matthew@matthewsetter.com. This podcast is produced by Matthew Setter. SupportIf you want to support the show, you can always buy me a coffee. I'd greatly appreciate your financial support.

You can find a great essay on AI helping students, and what that means for their teachers, here.Here's a piece on W4 Games plans to monetize the Godot engine.Snap says it now has one million subscribers for its Snapchat+ offering.There were no fresh lifeboats badges this week, so shoutout to Jemo for being awarded the Great Question badge. They asked: What's the difference between thread and coroutine in Kotlin

Chris is getting ready to travel, and of course, Sagewell started the day with an incident, a situation, if you will... Steph talks books perfect for vacations and feels sufficiently scarred regarding still working with moving fixtures over to FactoryBot. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Back to Basics: Boolean Expressions (https://thoughtbot.com/blog/back-to-basics-booleans) Sarah Drasner tweet (https://twitter.com/sarah_edo/status/1538998936933122048) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: All right, I am now officially recording as well. Let me make sure my microphone is in front of my face. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? CHRIS: What's new in my world? Today is an interesting day. We are recording on a Friday, which is not normal for us, was normal for a long time and then stopped, but now it's back to being normal. But it's the morning, which is confusing. Also, I am traveling this evening. I leave on a flight going to Europe. So I'm going to do a red-eye, that whole thing. So I got a lot to pack into today, literally packing being one of those things. And then this morning, because obviously, this is the way the world should play out, we started the day with an incident at Sagewell, a situation. Some code had gotten out there that was doing some stuff that we didn't want it to do. And so we had to sort of call in the dev team. And we all huddled together and tried to figure it out. Thankfully, it was a series of edge cases. It was sort of one of those perfect storms. So when this edge case happens in this context, then a bad thing could happen. Luckily, we were able to review the logs; nothing bad happened. While I'm unhappy that we had this situation play out... basically, it was a caching thing, just to throw that out there. Caching turns out to be very hard. And the particular way it played out could have manifested in behavior that would have been not good in our system, or an admin would have inadvertently done something that would have been incorrect. But on the positive side, we have an incident review process that we've been slowly incubating within the team. One of our team members introduced it to us, and then we've been using it on a few different cases. And it's really great to just have a structured process. I think it's one of those things that will grow over time. It's a very simple; what's the timeline of what happened? What's the story as to why it happened and why it wasn't caught earlier? What are the actions that we're going to take? And then what's the appendix? What's the data that we have around it? And so it's really great to just have that structure to work within. And then similarly, as far as I can tell, the first even observable instance of this behavior in our system was yesterday morning. We saw it, started to respond to it, saw one more. We were able to chase it down in the logs. Overall, the combination of the alerting that we have in Sentry and the way in which we respond to the alerting in Sentry, which I think is probably the most critical part. Datadog is our log metrics tool right now. So we're able to go through Datadog, and we have Lograge configured to add more detail to our log lines. And so we're able to see a very robust story of exactly what happened and ask the question, did anything actually bad happen? Or was it just possible that something bad could happen? And it turns out just possible. Nothing actually happened. We were able to determine that. We were even able to get a more detailed picture of who were all the users who potentially could have been impacted. Again, I don't think there was any impact. But all total, it was both a very stressful process, especially as I'm about to go on vacation. It's like, oh cool, start to the day where I'm trying to wrap up things, and instead, we're going to spend a couple of hours chasing down an incident. But that said, these things will happen. The way in which we were able to respond, the alerting and observability that we had in place make me feel good. STEPH: I like the incident structure that you just laid out. That sounds really nice in clarifying what happened when it happened in the logs. And the fact that you're able to go through and confirm if anything really bad happened or not is really nice. And I was also just debating this is one of those things, right? Right when you're about to go on vacation, that's when something's going to break. And that's like, is that good or bad? Is it good that I was here to take care of it right before, or is it bad? Because I'd really like to not be here to take care of it. [laughs] You may have mixed feelings. I have mixed feelings. CHRIS: I think I'm happy. Unsurprisingly, this exists in one of the most complex parts of our codebase. And it involves caching. And I remember when we introduced the caching, I looked at it, and I was like, hmm, we have a performance hotspot that involves us making a lot of requests to an external system. And so we thought about it a little bit, and we were like, well, if we do a little bit of caching here, we can actually reduce that down from seven calls down to one over external HTTP. And so okay, that seems to make sense. We had a pull request. We did a formal review. And even I looked at the pull request where this was introduced initially, and my comments on it were like, yep, this all looks good. Makes sense to me. But it's caching-related. So let's be very careful and look very closely at it and determine if there's anything, but it's so hard to know. And in fact, the code that actually was at play here was introduced a month ago. And interestingly, the observable side effect only occurred in the past two days, which we find very surprising. But again, it's this weird like, if A happens and then within a short period after that B happens...and so it's not quite a race condition. But it was something where a lot of stuff had to happen in a short span of time for this to actually manifest. And so, again, we were able to look through the logs and see all of the instances where it could have happened and then what did happen. Everything was fine, but yeah, it was interesting. I feel actually good to have seen it. And I think we've cleared everything up related to it and been very proactive in our response to it so that all feels good. And also, this is the sort of thing we've done this a few times now where we've had what I would call lesser incidents. There was no customer-facing impact to this. Similarly, previous incidents, we've had no or very minimal customer-facing impact. So at one point, we had a situation where we weren't processing our background jobs for a little while. So we eventually caught up and did everything we needed to. It just meant that something may not have happened in as timely a fashion as necessary. But there were no deep ramifications to that. But in each of those cases, we've pushed ourselves to go through the incident process to make sure that we're building the muscle as a team to like, actually, when the bad one comes, we want to be ready. We want to have done a couple of fire drills first. And so partly, I viewed this as that because again, there was smoke, but no fire is how we would describe it. STEPH: Nice. And that also makes sense to me how you were saying y'all introduced this about a month ago, but you were just now seeing that observable side effect. I feel like that's also how it goes. Like, you implement, especially with caching, some performance improvement, and then you immediately see that. And it's like, yay, this is wonderful. And then it's not til sometime passes that then you get that perfect storm of user interactions that then trigger some flow that you didn't consider or realize that could create an issue with that caching behavior. So yeah, that resonates. That seems right. All caching problems usually take about a month or two when you've just forgotten about what you've done. And then you have to go back in. CHRIS: Yep. Yep, yep, yep. So now we've done the obvious thing, which is we've removed every cache from the system whatsoever. There are no caches anymore because it turns out we just can't be trusted with caches in any form whatsoever. ActiveRecord, we turned off caching, Redis we threw it out. No, I'm kidding. We still have lots of caching in the app. But, man, caching is so hard. STEPH: I would love if that's in the project README where it says, "We can't be trusted with caches. No caches allowed." [laughs] CHRIS: Yeah, we have not gone all the way to forbid caching within the application. It's a trade-off. But this does have that you get those scars over time. You have that incident that happens, and then forever you're like, no, no, no, we can't do X. And I feel like I'm just a collection of those. Again, I think we've talked about this in previous episodes. But consulting for as long as I did, I saw a lot of stuff. And a lot of it was not great. And so I basically just look at everything, and I'm like, urgh, no, this will be hard to maintain. This is going to go wrong. That's going to blow up someday. And so, I'm having to work on trying to be a little more positive in my development work. But I do like that I have that inclination to be very cautious, be very pessimistic, assume the worst. I think it leads to safer code in general. There was actually a tweet by Sarah Drasner that was really wonderful. And it's basically a conversation between her and another developer. It's a pretend conversation. But it's like, "But why don't you like higher-order components?" And then it's Squints. "Well, in the summer of 2018, something bad happened, Takes a long drag of a cigarette. something very bad." It's just written so well and captures the ethos just perfectly. Like, sit down. Let me tell you a tale of the time in 2018. [laughs] So I'll include a link to that in the show notes because she actually wrote it so well too. It's got like scene direction within a tweet and really fantastic stuff. But yeah, we'll allow some caching to continue within the app. STEPH: That's amazing. So I was just thinking where you're talking about being more pessimistic versus optimistic. And there's an interesting nuance there for me because there's a difference in like if someone's pessimistic where if someone just brings up an idea and someone's like, "Nope, like, that's just not going to work," and they just always shoot it down, that level of being pessimistic is too much. And it's just going to prevent the team from having a collaborative and experimental environment. But always asking the question of like, well, what's the worst that could happen? And what are the things that we should mitigate for? And what are the things that are probably so unlikely that we should just wait and see if that happens and then address it? That feels like a really nice balance. So it's not just leaning into saying no to everything. But sure, let's consider all the really bad things that could happen, make a plan for those, but still move forward with trying things out. And I realized I do this in my own life, like when someone asks me a question around if there's something that we want to do that's a bit kind of risky. And the first thing I always think of is like, well, what's the worst that could happen? And I think that has confused people that I immediately go there because they think that I'm immediately saying no to the idea. And so I have to explain like, no, no, no. I'm very intrigued, very interested. I just have to think through what's the worst that can happen. And if I'm okay with that, then I feel better about accepting it. But my emotional state, I have to think through what's the worst and then go from there. CHRIS: Wow, it's a very bottom-up approach for your life planning there. [chuckles] STEPH: Yep, I think that's, you know, it's from being a developer for so long. It has impacted now how I make other decisions. Good or bad? Who knows? Yeah, it turns out being a developer has leaked into my personal life. I've got leaky abstractions over here. So, good or bad? Who knows? CHRIS: Leaky abstractions all the way down. Yeah, circling back to, like, I don't think I'm pessimistic per se. The way that I see this playing out often is there will be a discussion of an architectural approach, or there's a PR that goes up. And my reaction isn't no, or this has a known failure point; it is more of uh, this makes me uncomfortable. And it's that like; I can't even say exactly why, and that's what makes it so difficult. And I think this is a place that can be really complicated for communication, particularly between developers who have been around for a little bit longer and have done this sort of thing and have gathered these battle scars and developers who are a bit newer. Having that conversation and being like, um, I can't say exactly why. I can tell you some weird stories. I might not even remember the stories. Some of it just feeds into just like, does this code make me uncomfortable? Or does this code make me happy? And I tend towards wildly explicit code for these reasons. I want to make it as clear as possible and match as close as possible to the words that we're saying because I know that the bugs hide in the weird corners of our code. So I try and have as few corners. Make very rounded rooms of code is a weird analogy that doesn't play, but here we go. That's what I do on this show is I make weird analogies. Actually, we were working on some code that was dealing with branching conditional things. So we had a record which has a boolean value on it. So we've got true or false, and then we've got two states, and then we've gotten an enum with three states. So all total, we have six possible states. But as we were going through this conversation, I was pairing with another developer on the team. And I was like, something feels weird here. And I actually invoked the name of Joël Quenneville because much of the data structure thought that I had here I associate with work that Joël has done around Maybe and things like that. And then also, my suggestion was let's build a truth table because that seems like a fun way to manage this and look at it and see what's true. Because I know that there are spots on this two-by-three grid that should never happen. So let's name that and then put that in the code. We couldn't quite get it to map into the data type, like into that Boolean in the enum. Because it's possible to get into those states, but we never should. And therefore, we should alert and handle that and understand, like, how did this even happen? This should never happen. And so we ended up taking what was a larger method body with some of the logic in it and collapsing it down to very explicitly enumerate the branches of the conditional and then feed out to a method. Like, call a method that had a very explicit name to say, okay, if it's true and we're in this enum state, then it's bad, alert bad. And then the other case like, handle the good case. And I was very happy with what we refactored down to because this is another one of those very complex parts of our code. Critical infrastructure-y is how I would describe it. And so, in my mind, it was worth the I'm going to go with pathological refactoring that we got to there. But yes, I was channeling Joël in that moment. I'm very happy to have had many conversations with him that help me think through these things. STEPH: That's awesome. Yeah, those truth tables can be so helpful. There's a particular article that, of course, Joël has written that then describes how a truth table works and ways that you can implement it into your habits. It's called Back to Basics: Boolean Expressions. I will be sure to include a link in the show notes. CHRIS: But yeah, I think that summarizes my day and probably the next couple of days as I prepare for an adventure over to Europe and chat about developer spidey sense. But yeah, what's new in your world? STEPH: Yeah, that's a big day. There's a lot going on. Well, I actually want to circle back because you mentioned that you're packing and you're going on this trip. And I'm curious, do you have any books queued up for vacation? CHRIS: I do, yeah. I'm currently reading Elantris by Brandon Sanderson. Folks might be aware of his work from the highest-funded Kickstarter of all time, which was absurd. Did you see this happen? STEPH: I don't think so, uh-uh. CHRIS: He did this fun, cheeky little Kickstarter. The video was sort of a fake around...oh, it almost sounded like he might be retiring or something like that. And then he's like, JK, I wrote five new books. And so the Kickstarter was for those books with different tiered packages and whatnot. I think he got just the right viral coefficient going on. And apologies for the spoiler if anyone's not seen the video, but it's been out there for a while. So he wrote some books, and that's what the Kickstarter is for. You get some books. You sort of join a book club, and you'll get one a quarter. A million dollars seems like that will be a bunch for that. That'd be great. If he raised a million dollars, that'd be amazing. $40 million four-zero million dollars. [laughs] I'm just watching it play out in real-time as well. It just skyrocketed up. The video, I think, was structured just right. He got it onto the...it was on Reddit and Twitter and just bouncing around, and people were sharing it. And just everything about it seemed to go perfectly. And yes, the highest-funded Kickstarter of all time, I believe, certainly within the publishing world. But yeah, Brandon Sanderson, prolific author, and his stuff ends up just being kind of light and fun. And so I was reading Elantris for that. It's been a little bit slower to pick up than I would like. So I'm now in the latter half. I'm hoping it'll go a little bit more quickly and be...I'm just kind of looking for a fun read, some fantasy thing to go on an adventure. But as the next book, I downloaded a second one just to make sure I'm covered. I have a book by John Scalzi, who's a sci-fi, fantasy, more on the sci-fi end of the spectrum. And I've read some of his other stuff and enjoyed it. And this particular book has a very consistent set of reviews. I've read the reviews a few times. And everybody who reviews it is just like, "This isn't the greatest book I've ever read, but man was it a fun ride." Or "Yeah, no, best book? No. Fun book? Yes." And just like, "This book was a fun ride. This was great." And I was like, perfect. That is exactly what I'm looking for on a European vacation. The book is called The Kaiju Preservation Society, which also plays on monsters, Pacific Rim Godzilla. Kaiju, I think, is the word for that category of giant dinosaur-like monster. And so it's the Kaiju Preservation Society, which, I don't know, means some stuff, and I'm going to go on a fun adventure. So yeah, those are my books. STEPH: Nice. I've got one that I'm reading right now. It's called Clementine: The Life of Mrs. Winston Churchill, written by Sonia Purnell. And Sonia Purnell tends to focus on female historical figures. And so it's historical fiction, which is a sweet spot for me. The only thing I'm debating on is because I'm realizing as I'm reading through it, I'm questioning, okay, well, what's real and what's not? Because I don't want to be that person that's like, did you know? And then, I quote this fictional fact about somebody that was made up for the novel. [laughs] So I'm realizing that maybe historical fiction is fun, but then I'm having to fact-check all the things because then I'm just curious. I'm like, oh, did this really happen, or how did it go down? So it's been pretty good so far. But then it makes me wish that historical fiction novels had at the back of them they're like, these are all the events that were real versus some of the stuff that we fictionalized or added a little flair to. I'm in that interesting space. I also like how you highlighted that you chose a fun book. I was having a conversation with a colleague recently about downtime. And like, do you consume more tech during downtime? Like, are you actively looking for technical blog posts or technical books to read or podcasts, things like that? And I was like, I don't. My downtime is for fun. Like, I want it to be all the things that are not tech. Maybe some tech sneaks in there here and there, but for the most part, I definitely prioritize stuff that's fun over more technical content in my spare time, which has taken me a little while to not feel guilty about. Earlier in my career, I definitely felt like I should be crunching technical content all the time. And now I'm just like, nope, this is a job. I'm very thankful that I really enjoy my job, but it's still a job. CHRIS: It is an interesting aspect of the world that we work in where that's even a question. In my previous life as a mechanical engineer, the idea that I would go home and read about mechanical engineering...I could attend a conference, but I would do that for very particular reasons and not because, like, oh, it's fun. I'll go meet my friends. For me, this was a big reason that I moved into tech because I am one of those folks who will, like, I will probably watch a video about Remix in particular because that's my new thing that I like to play around with and think about. But it needs to be a particular shape of thing I've found. It needs to be exploratory, puzzle-y. Fun code, reading, learning work that I do needs to be separated from my work-work in a certain way. Otherwise, then it feels like work, then it is sort of a drudgery. But yeah, my brain just seems to really like the puzzle of programming and trying to build things. And being able to come into a world where people share as much as they do blogs and conference talks and all of that is utterly fantastic. But it is a double-edged sword because I 100% agree that the ability to disconnect to, like, work a nine-to-five and then go home at the end of the day. Yeah, go home, you know, because you remember when we went to an office and then we would go home afterwards? I have to commute every once in a while into the city and -- STEPH: You mean go downstairs or go to another room? That's what you mean? [laughs] CHRIS: I used to commute every day, and it took a lot of time. And now when I do it, I feel that so viscerally because I'm like, it's just a lot easier to just walk to my office in my house. But yes, I 100% I'm aligned to that like, yeah, no, you're done with work for the day, walk away. That's that. And learning a new technology or things like that, that's part of the job. There shouldn't be the expectation that that just happens. There's continuing education in every other field. It's like, oh, we'll pay for your master's degree so you can go learn a thing. That's the norm in every other...not in every other industry but many, many, many industries. And yet the nature of our world the accessibility of it is one of the most wonderful things about it. But it can be a double-edged sword in that if there are the expectations that, oh yeah, and then, of course, you're going to go home and have side projects and be learning things. Like, no, that is an unreasonable expectation, and we got to cut that off. But then again, I do do that. So I'm saying two things at the same time, and that's always complicated. STEPH: But I agree with what you're saying because you're basically respecting both sides. If people enjoy this as a hobby, more power to you.; that's great. This is what you enjoy doing. If you don't want to do this as a hobby and respect it as a job, then that's also great too. There can be both sides, and no side should feel guilty or judged for whichever path that they pursue. And I absolutely agree, if there are new skills that you need to learn for a job, then there should be time that's carved out during your work hours that then you get to focus on those new skills. It shouldn't be an expectation that then you're going to work all day and then spend your evening hours learning something else. And same for interviews; there shouldn't be a field that says, "Hey, what are your side projects?" Or at least that should not be an important part of the interview. There should be an alternative to be like, "Or what work code do you want to talk about?" Or something else that's more in that nine-to-five window that you want to talk about. That way, there's a balance between like, sure, if you have something that you want to talk about on the side, great, but if not, then let's focus on something that you've done during your actual work hours because that's more realistic. CHRIS: I do think there's an interesting aspect at play because the world of development moves so rapidly and because it's constantly changing. And to frame it differently, I don't think we've got this thing figured out. And so many people lament how quickly it changes and that there's a new framework every other week. And there's a bit of churn that is perhaps unnecessary. But at the same time, I do not feel like as a community, as a working population, that we're like, yeah, got it, crushed it. We know how to make great software, no question about it. It's going to be awesome. We're going to be able to maintain it for forever, don't even worry about it. New feature? We can get that in there. They're actually still pretty rare. So we need to be learning, and evolving, and exploring new techniques. I think the amount of thinking is probably good mostly in the development world. But organizations have to make space for that with their teams. And thoughtbot obviously does that with investment days. That's just such a wonderful structure that embraces that reality and also brings happiness, and it's just a pleasant way to work. And frankly, my team does not have that right now. We do the crispy Brussels snack hour, which also now has a corresponding crispy Brussels work lunch, which is one week we think about it, and the next week we do the thing. We're trying to make space for that. But even that is still more intentional and purposeful and less exploratory and learning. And so it's an interesting trade-off. I deeply believe in this thing, and also, the team that I'm leading isn't doing it right now. Granted, we're an early-stage startup. We got to build a bunch of stuff. I think that's fine for right now. But it is a thing that...again, I'm saying two things at the same time, always fun. STEPH: Well, and there might be a nice incremental approach to this as well. So thoughtbot has the entire day, and maybe it's less than a full day. So perhaps it's just there's an hour or two hours or something like that where you start to introduce some of that self-improvement time and then blossom out from there. Because yeah, I understand that not all teams may feel like they have the space for that. But then I agree with everything else you said that it really does improve team morale and gives people a space to then be able to get to explore some of those questions that they had earlier. So then they don't feel like they have to then dedicate some weekend time or off hours' time to then look into a question. And I admit, I'm totally guilty too. I am that person that then I've worked extra hours, but it's because, like you said, if there's a puzzle that my brain is stuck on and I just feel the need to get through it. But then I look at that as am I doing this because I want to? Yes. Okay, then as long as I'm happy and I don't feel like this is increasing any concern around burnout, then I don't worry about it. MIDROLL AD: Debugging errors can be a developer's worst nightmare… but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! Circling back to your original question about what's going on in my world, and you mentioned scarring earlier. I feel sufficiently scarred [laughs] in regards to still working with moving fixtures over to FactoryBot. This week has really confirmed that fixtures don't trigger a lot of the callbacks, the model callbacks that exist. And so this really means that you can just create bad data that your application doesn't actually allow your application to create. So there are tests that are exercising behavior that should never exist. And then porting that over to FactoryBot then highlights that because then as soon as I move that record over and then try to create it or do something with it, then the app, the test, do the right thing and let me know saying no, no, no, we've added validations. You can't do that anymore. That has been grinding my gears in terms of trying to then translate. Because then I have to really dive into the code to understand it. And the goal here is to stay as high level as possible and not have to dive in too much. But then that means that I do have to dive in and understand more. So this has frankly just been one of those times in my career where you just kind of have to slog through the work. It's important work to be done. It'll be great once it's done. But it's a painful process. And the best way that I've found to make it more enjoyable is to be in heavy communication with Joël, who's on the project with me, just so if we get stuck on something, then we can chat with each other. And then also there's one file that's particularly gnarly. And so we moved over one test. We were successful, and which felt great because then we could at least document like, okay, when we come back to this, at least we have one example that highlights the wonkiness that we ran into. But we've decided, okay, we're done with that file. We're going to take a break. There's a lot there, but we're going to move on and give ourselves a break and do some of the easier ones, and then we'll circle back to the harder one. Which was, I think, just a bit of bad luck in terms of, like, as we're going down the list, that happened to be like the gnarliest one, and it was like the first one that Joël picked up. And so I'm going through a couple of files, and Joël is like, "What? [laughs] How are you making progress?" And we realize it's just because that file, in particular, is very hard to find all the mystery guests and then to move everything over. Finding a positive note through all of the cruft, I will say this is helping with some of my code sleuthing skills. So as I am running into these problems and then looking for mystery guests, I'm noticing ways that I can then, as quickly as possible, try to triage and identify as to why one test doesn't match another test. Some of it is more specific to the application setup, so it won't be as applicable to future projects. But then some other areas have been really helpful. Like, I'm using caller a lot more to understand, like, I know this is getting called, but I don't know who's calling you. So I can put in a line that basically outputs like, show me your stack traces to how you got here. So that's been really nice as well. So it has improved some of my code sleuthing skills and also my spidey sense in terms of it's typically mystery guests. Like when a test isn't passing, it's because fixtures are creating extra data that are getting pulled in when there are queries that are being run. But they're not explicitly referenced in the test setup itself. So that's typically then where I start is looking for what record looks relevant to this test that I haven't pulled over to my test setup. CHRIS: I appreciate you finding the silver lining, the positive bit of this. Because as you're describing, the work that you're doing sounds like I think you use the word slog, which seems like a very accurate term. But sometimes we have to do that sometimes for a variety of reasons. We end up either having to introduce new code or fix old code, but this is sometimes the work. And this is something that I think you and I share about this show is we get to show all sides of the work. And the work can be glamorous and new. And oh, I've got this greenfield app that I'm building, and it's wonderful. Look at the architecture. And I know in the moment that I'm building someone else's legacy code three years from now. [laughs] And so telling the other side of the story and providing that rounded point of view, because like, yeah, this is all part of it. Again, I don't believe that this is a solved problem, building robust software that we can maintain. And so yeah, you're doing the good work in there. And I thank you for sharing it with us. STEPH: Thanks. Just don't use fixtures in your test, I beg of you. Please don't do that to the legacy code that you're writing for future developers. [laughs] That is my one request. CHRIS: And I will maybe add on to that, sparingly use callbacks. Maybe don't use them at all, and certainly don't use the combination because, my goodness, that'll lead you into some fun times. But yeah, just two small recommendations there. STEPH: Oh, there's something else I wanted to share. I saw that Slack added a new audio feature that allows you to record the pronunciation of your name, which is the feature that I was so excited about when we added it to our internal tool called Hub at thoughtbot. And now Slack has it on their profile so that way you can upload the pronunciation. And then anyone looking at your profile can then listen to how to pronounce your name. There are a couple of other features that they released, I think just in June, so about a month ago from the recording of today. [laughs] That's weird to say, but here we are. So I'll include a link in the show notes so folks can see that feature in addition to others, but I'm super excited. CHRIS: Oh, that is nice. I also like all right, so Slack now has it. Hub now has it. But I don't have access to Hub anymore. And I don't have access to every Slack in the world yet. But here's my suggestion. All right, everybody, stick with me here. I want you to own a domain. I want you to have a personal site on it. And I want the personal site to include the pronunciation of your name. I get that that's a big ask. And I get that there are other platforms that are calling to you, and you may be writing on those. But you know what? Just stand up a little site, just a little place on the internet that you own. And if it includes the pronunciation of your name, I will be forever grateful. STEPH: I like this idea. I initially was taking your idea and immediately running with it as you were speaking it because then I wondered if everyone had their own YouTube channel. But I don't know how hard it is to create a YouTube channel. I am not a YouTube channeler, so I don't know what that looks like. [laughs] But not everybody will know how to purchase a domain. So that might be another approach. CHRIS: I think it's pretty easy to do a YouTube channel. I'm conflating a couple of things. This is my basket of beliefs about people on the internet, but I kind of think everybody should own their own little slice of the internet. And so totally, YouTube is a place where the people make some stuff, make videos, put them on YouTube, absolutely. But ideally, you own something. I see a lot of people that are on YouTube, and that's it, and so their entire audience lives on YouTube. And if YouTube someday decides to change or remove them or say Medium as an example, Medium actually, I think, does a more interesting version of this where your identity kind of gets subsumed into Medium. And I really think everybody should just have their own little, tiny slice of the internet that's there. It has their name that they own that no platform can decide; hey, we've shifted, and now your stuff is gone. Cool URIs don't change as they say, and that's what I want. And then yeah, if you can have the pronunciation of your name on there, that's extra nice. Although I say that, and I don't know that I would do it because my name feels very obvious. One day someone was like, "Oh, how do you pronounce your last name?" I forget if I actually replied with the pronunciation. Or if I was like, "I need to know what options you're considering. I'm so interested because I've really only got the one." Maybe I'm anchored. Maybe I'm biased. [chuckles] I've been doing this for a while. But I really cannot think of another pronunciation of my name. STEPH: You might hear another one that you really like, and you need to pivot. CHRIS: Oh gosh. STEPH: That's the point where you start pronouncing your name differently. CHRIS: Wow, that would be a lot. And then, I could have a change log on my personal site where people can see this is the pronunciation, and this is what the pronunciation used to be. STEPH: [laughs] I like this idea. I also like this idea that everybody has their own slice of internet land. I like this encouragement that you're providing for everyone. On a slightly different note, there's a blog post that I'm really excited to talk about. It's written by Eric Bailey, who's a former thoughtboter. It's called The Optics of Pair Programming. And given how much pair programming that I'm doing, especially with Joël on the current project, it was a really wonderful read. And it also helped me think about pairing from a different perspective because we do have a very strong pairing culture at thoughtbot. So there's a lot of nuance, especially social nuances that can go along with when you invite someone to pair with you that I had not considered until I read this wonderful post by Eric. And we'll be sure to include a link in the show notes. But to provide an overview, essentially, Eric shares that given coming from thoughtbot where we do have a very open approach to pairing where pairing sessions are voluntary and then also last as long as the problem will last...but then when you're at a new company, you could experience pushback if you're inviting someone to pair and then to consider why that pushback may exist. And some of the high-level areas that Eric highlighted are power dynamics, assessment, privacy, and learning styles. So to dive into each of some of those, there's a power dynamics of it's important to consider who's offering to pair. So if I've joined a team as a consultant, there may be a power dynamic there that someone is feeling where their team is paying for my time. So they may feel like they can't say no if I offered to pair. They feel like they need to say yes to the invitation, even if they don't really want to. Or probably a more classic example would be like, what if your boss wants to pair or someone that's just more senior than you? Then it could leave you feeling like, well, I can't say no to this person, can I? Which yes, you totally can say no to that person, but it may leave you in a place where you feel like you can't. And so, it puts you in this sort of uncomfortable and powerless position. The other one is assessment, so offering to pair with someone could feel like you are implying that you want to assess their skills or that you're implying that they're not up to the task and therefore they need your help. So then that could also place someone in an uncomfortable position. There's also privacy. So someone who isn't confident may not want someone to observe their behavior or observe how they're working. It could make them feel really anxious, which then I love that Eric points this out. Ironically, pairing is really good at addressing that lack of confidence because then you get to see how other people work through their problems or how they think, or they may also have some anxiety. Or it just helps you become more comfortable in talking and thinking through with other people. So that one is a tough one where it's hard to get over that initial hurdle. But actually, the more you pair, then the less anxious you'll feel when you pair. And then there's also learning styles because pairing really involves a lot of deep thinking but in our personal time. And it can be hard to balance both of those, and it's just not as effective for some people. So I know that even as much as I really enjoy pairing, I just need to sit with code on my own sometimes. I need to think about it. I need to run it; I need to look at it. So it's really nice to talk with someone. But then I also need that alone time to then just think through it on my own because I can't have that same deep focus if I'm also worried about how the other person is experiencing that session because then my mental energy is going towards them. So that covers a number of the social nuances that can be included or running through someone's mind when you extend an invitation to them to pair. And it really resonated with me the areas that Eric highlights in this blog post. He also talks about a couple of strategies, which I'd love to dive into as well. But I'm going to pause here and see what thoughts you have. CHRIS: Yeah, I love this post. And it got me thinking about pairing and the broader human backdrop of all of the processes and workflows that we have. Everything he highlighted about pairing feels true. Although similar to you and to Eric, I've worked in a context where pairing was a very natural, very regular part of the work and sort of from the very top-down. And so everyone pairing between developers of any different level or developers and designers or really anyone in the...it was just such a part of how we worked that no one really questioned it or at least not after the first couple of weeks. I imagine joining thoughtbot those first weeks; you're like, oh God. As I shared, I think in the previous episode that we recorded, my pairing interview was with Joe Ferris, the CTO of thoughtbot, [laughs] writing a book about good and bad code. And I was like, I don't know what anything is here but very quickly getting over that hurdle. And having that normalizing experience was actually really great, and then have been comfortable with it since. But the idea that there are so many different social dynamics at play feels true. And then as I think about other things, like stand-up is one that I think of as this very simple this is a way to communicate where we're at. And where necessary or where useful, allow people to interject or step in to say, "Oh, let me help you get unblocked there or whatever it is." But so often, I see stand-up being a ritual about demonstrating that you are, in fact, doing work, which is like, here's what I did yesterday. I don't know if it's useful. Then mention that you're working on this project. But the enumeration of look, obviously, work was done by me. You can see it; here are the receipts. It's very much this social dynamic at play. And retro is another one where like, if retro is very much owned by one voice and not a place that change actually happens where people feel safe airing their opinions or their concerns, then it's going to be a terrible experience. But if you can structure it and enforce that it is a space that we can have a conversation, that everyone's voice is welcome and that real change happens as a result of, then it's a magical tool for making sure we're doing the right things. But always behind these are the people, and feelings, and the psychology at play. And so this was just such an interesting post to read and ruminate on that a little bit more. STEPH: Yeah, I agree, especially with a comment that you made about those daily syncs where I really just want to focus on today and what you have that you're blocked on. So it's a really nice update in case there are any cross-collaboration opportunities. That's really what I'm looking for in a daily update. And so I appreciate when people don't go through a laundry list of what they did yesterday because it's like, that's great. But then, like you said, it's just like you're trying to prove here's what I've done, and I trust you; you're working. So just let me know what you're doing today, friend. So Eric does a wonderful job of also including some strategies for ways that then you can address some of these concerns and then how there may be some extra anxiety that's increased when you're inviting somebody to pair. There are some wonderful strategies. I'll let folks read through the blog post itself. There are a couple in particular that came to mind for me because I was then self-assessing how do I tend to approach pairing with someone? And some ways that I want them to feel very comfortable with that experience. And there's a couple. There's one where I recognize that I need to build trust with each person. I can't just go on to a team and expect everyone to know that I have good intentions and that I'm going to do my best to be a fun, helpful pairing partner, and that it's not a zone of judgment. And that has to be cultivated with each person. Because especially as a consultant, if I'm joining a team, the people who hired me are not necessarily the people that I'm working with. It's someone that's probably in leadership or management that has then brought on thoughtbot. And so then the people that I'm working with they don't know me, and they don't know what my pairing style is going to be. So looking for ways to build trust with each person and then also inviting them or asking for help myself. So there's a bit of vulnerability that has to be shown to build trust with someone to say," Hey, I'm stuck on a problem. I would love a second set of eyes. Would you be willing to help me out with this?" So then that way, they're coming in to help me initially versus I'm going in and saying, "Hey, can I help you?" I have found that to be an effective strategy. And there's one that I do really want to talk about, and that's not everyone is going to pair well together. Like, you may find someone who always leaves you feeling just stressed or demoralized. And while it's important to consider your role and why that's true, that does not mean it's your fault and necessarily your problem to fix. So similar to having to manage up, you may need to coach the person that you're pairing with in ways that help you feel comfortable pairing. But if they don't listen to your requests and implement any of that feedback, then just don't pair with that person. That is a very fine option to recognize people that are not receptive to your needs and, therefore, not someone that you need to then force into being a great pairing buddy. And I emphasize that last one because it took me a little while to become comfortable with that and accepting that it wasn't my fault that I wasn't having a great pairing session with people. Similar to when I'm learning from someone that if someone is explaining something to me and they're making me feel inadequate while they're explaining it to me, that's not necessarily my fault. Like, I used to internalize that as like, oh, I just can't get this. But I am now a very staunch believer in if you can't explain it to me in a way that I understand, then that's probably more on you than on me. And that has also taken me time to just really accept and embrace. But once you do, it is so freeing to realize that if someone's explaining a concept and you're still not getting it, it's like, hey, how can we try harder together versus you just making me try harder? CHRIS: I like that right there of like, if I don't understand this, it may actually be you, not me, or something to that effect. Let's get that on a bumper sticker and put that in The Bike Shed store so that everybody can buy it and put it on their cars or at least just us. But yeah, that starting from the bottom sometimes it's just not going to work great. There are even...I think what you're describing sounds a little more complicated, individuals who are personally not great at communicating or pairing or things like that. And that's going to happen. We're going to run into folks that...pairing is communication. That's just the core of it, and some folks, that may not be their strongest suit. But I think there's another category of just like different working styles. And whereas I might...judge is such a heavy word, but I'm going to use it. I might judge someone who is not doing a great job at communicating to someone else, or understanding their point of view, or striving to do that, or taking feedback. Like, those are not great things. Whereas there may just be two different development styles or backgrounds, or there are other reasons that actually they may be not an ideal fit. That said, I have definitely found that in almost every variation of pairing, I've seen work at some point. Like, when I was very early on in my career pairing with folks that are very senior, I didn't get most of it, but I got some stuff. And then folks that are very much on the same level or folks that have a deep knowledge in framework, code base language, whatever and folks that are new to it but have a different set of experiences. Basically, every version of that, I found that pairing is actually an incredibly powerful technique for knowledge sharing, for collaboration, for all of that. So although there are rare cases where there might be some misalignment, in general, I think pairing can work. I do think you hit on something earlier of there are certain folks that are more private thinkers, is how I would describe it, where thinking out loud is complicated for them. I'm very much someone who talks. That's how I figure out what I think is I say stuff. And I'm like, oh, I agree with what I just said. That's good. But I find I actually struggle. There's something I think of...maybe I'm just a loudmouth is what I'm hearing as I say it, but that is how I process things. Other folks, that is not true. Other folks, it's quite internal, and actually trying to vocalize that or trying to share the thought process as they're going may be uncomfortable. And I think that's perfectly reasonable and something that we should recognize and make space for. And so pairing should not be forced upon a team or an individual because there are just different mindsets, different ways of thinking that we need to account for. But again, the vast majority of cases...I've seen plenty of cases where it's someone's like, "I don't like to pair. That's not my thing." And it's actually that they've had bad experiences. And then when they find a space that feels safe or they see the pattern demonstrated in a way that is collegial, and useful, and friendly, then they're like, oh, actually, I thought I didn't like pairing. I thought I didn't like retro. I thought I didn't like stand-up. But actually, all of these things can be good. STEPH: Yeah, absolutely. It's a skill like anything else. You need to see value in it. And if you haven't seen value in it yet or if it's always made you anxious and uncomfortable, then it's something that you're going to avoid as much as possible until someone can provide a valuable, positive experience around how it can go. I'm going to pull back the curtains just a little bit on our recording and share because you've mentioned that you are very much you think out loud, and that's how you decide that you agree with yourself. And I think already at least twice while we've been recording this episode, I have started to say something, and I'm like, no, wait, I don't agree with that and have backed myself up. CHRIS: [laughs] STEPH: And I'm like, no, I just thought through it; I'm going to cancel it out, [laughs] and then moved in a different direction. So I, too, seem to be someone that I start to say things, and I'm like, oh, wait, I don't actually agree with what I just said [laughs], so let's remove that. CHRIS: Yep. You've described it as Michael Scott-ing on a handful of different episodes or maybe things that were cut from episodes. But where you start a sentence and then you're like, I don't know where I was going to end up there. I hoped I'd figure it out by the end, but then I did not get there. And yeah, I think we've all experienced that at various times. STEPH: That's some of my favorite advice from you is where you've been like, just lean into it, just see where it goes. Finish it out. We can always take it out later. [laughs] Because I stop myself because I immediately start editing what I'm trying to say and you're like, "No, no, just finish it, and then we'll see what happens." That's been fun. CHRIS: This is how you find out what you think. You say it out loud, and then you're like, never mind. That was ridic – STEPH: [laughs] CHRIS: I do. Actually, now I'm thinking back, and I have plenty of those where I'll say a thing, and I'm like, nope, never mind, send that one back. [chuckles] As an aside, so we do this thing where we host a podcast, and we get to talk. But we're both now describing the pattern where we'll start to say something, and we'll be like no, no, no, actually, not that. And I think, dear listeners out there, you probably don't hear any of this, the vast majority of it, because we have wonderful editors behind the scenes, Thom Obarski for many years, and now Mandy Moore, who's been with us for a while. And so once again, thank you so much to the editor team that allows us to, I think, again, feel safe in this conversation that we can say whatever feels true and then know that we'll be able to switch that around. So thank you so much to the editors who help us out and make us sound better than we are. STEPH: Yeah, that has made a big difference in my capabilities to podcast. If we were doing this live, ooh goodness, this might be a whole different, weird show. [laughs] CHRIS: I mean, the same is true for code, right? I deeply value the ability to make an absolute mess in my local editor and have nine different commits that eventually I throw two out. And then I revert that file, and then eventually, the PR that I put up that's my Instagram selfie. That's like, I carefully curated this, but what's behind the scenes it's just a pile of trash. So yeah, the ability to separate the creation and the editing that's a meaningful thing to have in life. STEPH: Oh, I can't unsee that now. [laughs] A pull request is now the equivalent of that curated Instagram selfie. That is beautiful. [laughs] CHRIS: To be clear, I don't think I've ever taken an Instagram selfie. But I get the idea, and I felt like it was an analogy that would work. Again, I try out analogies on this show, and many of them do not stick. But I think that one is all right. STEPH: It might even go back to pairing because then you've got help in taking that picture. So hey, you're making a mess with somebody until you get that right perfect thing, and then you push it up for the world to see. So safe spaces for all the activities, I think that's the takeaway. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

What are the pros and cons of pair programming? When is it valuable?

On today's episode, we are joined by special guest, Ben Orenstein, to talk about remote pair programming. Ben is a developer, who after many years of working for other people decided to strike out on his own. He is the cofounder of an app called Tuple, which is specifically for remote pair programming.

Você já ouviu falar sobre pair programming ou programação pareada? No episódio de hoje trouxemos os devs de um time aqui do Luizalabs, para falarmos sobre como que acontece essa técnica dentro de um time, as vantagens e sobre a experiência deles no dia a dia! Então chega+ e bora ouvir esse episódio, que tá muito massa! --- Edição completa por Rádiofobia Podcast e Multimídia: https://radiofobia.com.br/ --- Nos siga no Twitter e no Instagram: @luizalabs @cabecadelab Dúvidas, cabeçadas e sugestões, mande e-mail para o cabecadelab@luizalabs.com Participantes: Ariadyne Oliveira | @trescores Adimir Colen | linkedin.com/in/adimircolen/ Denis Guerra | linkedin.com/in/denisfrm/ João Fayad | linkedin.com/in/joao-fayad/

There are a lot of ways pair programming can go wrong. Thankfully, it's possible to pair well simply by avoiding pairing poorly and, by steering clear of some of the common mistakes that we outline in this episode, you'll automatically up your chances of success! Today, on The Rabbit Hole, Michael Nunez, Sophie Cruetz, and Dave Anderson talk pair programming antipatterns, from multiple disruptions to over-philosophizing, from keyboard hogging to decision fatigue. For some simple tips on how to make pair programming a great tool for knowledge sharing and team building rather than a chore, tune in today!