What does it take to shift from fear to flow when reading and refactoring code? In this episode of the Mob Mentality Show, we dive deep into **"Paradigms of Code Reading"**, exploring the mindsets and techniques that shape how developers approach software understanding. Whether you're navigating legacy code or striving for clean, maintainable designs, this discussion offers actionable insights for individuals, pairs, and mobs alike.   ### What You’ll Learn in This Episode:   - **Code Reading Paradigms**: Discover the two ends of the spectrum:     - **Understand Every Line**: Keeping every detail in your head.     - **Extreme Abstraction Zen**: Focusing only on the current module or method.   - **AB Testing in Code Reading**: Insights from live experiments on how pairs and mobs read and understand code.   - **The Role of Trust**: How levels of trust in variable names, methods, and classes influence reading strategies.   - **Overcoming Fear and Skepticism**: What causes developers to ignore method names or distrust the knowledge baked into the code?   - **Cognitive Load and Flow Efficiency**: Learn how reducing cognitive load through small, fast tests can lead to more effective coding sessions.   - **Code Reading Clubs**   - **Coaching Toward Abstraction Zen**: Practical strategies to influence and support others in adopting better reading and refactoring paradigms.   - **Embracing Skeptics**: The value of radical candor, genuine curiosity, and visual aids like diagrams in addressing fear and building trust.   ### Key Takeaways:   - Refactoring starts with trust - Genuine curiosity can replace complaints, transforming how teams collaborate and learn.   - Drawing pictures and visualizing code can unlock new perspectives and improve comprehension.   - Skeptics are not obstacles—they're opportunities for deeper conversations and better design.   Whether you're a seasoned software engineer, a pair programming enthusiast, or new to mob programming, this episode will provide you with practical tools and thought-provoking questions to enhance your coding practice.   💡 **Want to stay ahead in your software journey?** Don't miss this deep dive into the cognitive, emotional, and technical aspects of reading code.   🔗 **Subscribe to the Mob Mentality Show**:   Get notified as soon as this episode drops! Available on all major platforms:   👉 https://www.mobmentalityshow.com/   🎧 Tune in to unlock new paradigms for code reading and refactoring. Let’s move from fear to flow together! Video and Show Notes: https://youtu.be/pXEp6jBeycs 

In this episode of the Mob Mentality Show, we dive into our Software Professional Resources Board, a dynamic Trello-based hub designed for software professionals looking to enhance their learning and collaboration in the industry. Join us as we share the board’s origin story and our journey in creating a comprehensive resource for everything from Extreme Programming (XP), mobbing, and leadership to cloud infrastructure, agile retrospectives, lean principles, and much more. ### What Makes Our Board Unique? We start by exploring why we chose **Trello** for our resource board and how it has become a cornerstone for organizing, sharing, and discovering knowledge. With its flexibility, Trello enables us to create an easily navigable environment, where resources are not only organized but can also be searched, linked, and explored across various software domains. Our conversation touches on other similar boards we’ve seen, like our popular "Retrospective Techniques for Coaches, Scrum Masters, and Facilitators" board, as well as spin-offs we’ve created for specific topics. ### A Variety of Topics Our board covers a broad spectrum of topics that are essential for modern software professionals, including **mobbing**, **refactoring**, **leadership**, **Infrastructure as Code (IaC)**, **agile** practices, and more. With resources curated for both technical and strategic learning, the board has become a go-to reference for articles, blog posts, videos, academic papers, book links, and quotes on various disciplines within software development. ### How We Use the Board for Continuous Learning Discover how we leverage the board not only to organize information but to foster continuous learning. We discuss Chris’ “community-supported learning binges” and our process for capturing insightful book quotes and key takeaways, turning the board into a knowledge-sharing powerhouse for software teams and individual contributors alike. ### Refactoring the Mind: Evolving the Board to Stay Relevant Our discussion also delves into the concept of "refactoring my mind by refactoring the board"—an idea about how reorganizing knowledge can improve our mental clarity and adaptability in complex projects. This involves regularly revisiting, reshaping, and expanding board content to reflect the latest insights and trends in software development, keeping it a living, breathing resource for our community. ### The Impact of Public Knowledge Sharing One of the most inspiring aspects of this board is its role in **public knowledge sharing**. We highlight feedback from the community, stories of how others have used the board in their professional journeys, and our own experiences with learning in public. By sharing this resource openly, we invite others to benefit from it, create connections, and add to the body of knowledge that supports software development excellence. Whether you’re a developer, coach, Scrum Master, or technical leader, this episode offers valuable insights into how to create and use a resources board to drive personal and team growth. Listen in for tips on organizing knowledge, capturing valuable insights, and using community feedback to make a resource board that truly enhances your software development journey. ### Topics Discussed: - The board's origin story and why we chose Trello - Organizing, searching, and sharing resources in Trello - Similar boards, including "Retrospective Techniques for Coaches, Scrum Masters, and Facilitators" - Variety of topics: mobbing, XP, leadership, IaC, agile, cloud, business, tech, retrospectives, and more - Types of media: articles, blogs, videos, book quotes, academic papers, and beyond - Spin-off boards and community learning sessions - Feedback from the community and lessons for public knowledge sharing **Subscribe on YouTube or your favorite podcast platform to catch this episode and more!** Video and Show Notes: https://youtu.be/GmfWWiIeaVY 

In this Mob Mentality Show episode, we dive into the journey of Jeff “Cheezy” Morgan, a coach in Continuous Delivery (CD) and lean thinking. Known for his role in advocating for CD within companies, Jeff shares how his experiences with software development and his recent shift into the café business have shaped his philosophy on people and just-in-time. This discussion explores how Jeff’s approach to Agile and CD evolved, his journey into Extreme Programming (XP), and how mob programming impacted his perspective on teamwork and Continuous Integration (CI).  **Jeff’s Agile and CD Journey** We start with Jeff’s introduction to Agile, discussing the early days of his career when dev practices didn’t include CD and the impact of adopting CD in high-stakes projects like Y2K. Jeff describes how learning from Thoughtworks influenced his views on XP and CD, and how he became an advocate, eventually taking CD to different organizations. He also shares what it was like discussing with Woody Zuill and Llewellyn Falco and reflects on the transformative role mob programming has played in his career. **From Pairing to Mobbing**   For Jeff, mob programming was not initially appealing, but over time it became his preferred approach for helping teams. We explore how mobbing enhances CI, tightens communication, and fosters collective learning. Jeff explains how mobbing enables "just-in-time" discussions that align teams on what to build and how it allows real-time feedback on other team members’ learning. Jeff also examines the transition from pairing to mobbing, the challenges of mob programming with CI/CD, and why mobbing helps him “get the whole system in the room” for tackling complex problems. **Quality Without QA?**   We dive into the controversial idea of achieving high quality without traditional Quality Assurance (QA). Jeff opens up about years spent wrestling with the role of QA in Agile/CD environments and shares experiments with “test-infected” developers—who took full ownership of quality. He reflects on the pitfalls of relying on “heavyweight” traditional QA processes and automated tests, which often create lean waste, add handoffs, and introduce brittle, flakey tests. Jeff and hosts Austin and Chris discuss whether “shift left” is merely a shift away from QA, the Deming Red Bead experiment’s relevance, and whether there’s a happy journey for QA professionals on CD teams. **Applying Lean to Cafés**   Outside the tech world, Jeff has found a second passion—running cafés. We discuss how owning two cafés influenced Jeff’s perspective on Lean thinking and Agile principles. From supply chain issues during COVID to needing backup suppliers, Jeff discusses if “just-in-time” challenges in the café world mirror software development. He shares valuable insights about hiring, managing consistent delivery, and applying Lean principles to run a resilient business. Additionally, Jeff and Chris exchange stories on chip shortages and if Lean can help address real-world supply chain issues. **More from Jeff**   Finally, we tackle some big questions: What does DevOps mean in today’s Agile world? Should “DevOps” be responsible for shielding organizations from developers? How does Test-Driven Development (TDD) factor into DevOps scripts, and can mobbing help break down silos that traditionally separated devs, ops, and QA? Join us for this wide-ranging conversation with Jeff “Cheezy” Morgan to uncover actionable insights for anyone involved in Agile, CD, DevOps, or Lean. Whether you're in software, QA, or running a small business, this episode is packed with valuable takeaways on quality, learning, and resilience.  Video and Show Notes: https://youtu.be/OJ5d6qLIQRY   

Gary Cohen, an independent consultant with a wealth of experience in software development and agile methodologies, shares insights on optimizing product discovery and delivery. He discusses the challenge of identifying which features deliver true customer value, promoting flexible strategies over rigid roadmaps. The conversation delves into the impact of Generative AI on collaborative practices and product prioritization, enhancing team efficiency and customer engagement through iterative feedback and real-time insights. Discover how collective discovery methods can transform product development!

In this discussion, Kyle Griffin Aretae, a software developer specializing in maintainability and TDD, unpacks the true essence of Test-Driven Development. He reveals that TDD is more than just 'test first'; it requires fast feedback loops and regular refactoring. Kyle also tackles misconceptions around unit testing and explains how aligning team goals fosters better collaboration in Agile practices. His insights on decoupling code and integrating shared objectives present a fresh perspective on enhancing software development processes.

In this episode of the Mob Mentality Show, we explore the profound concept of "Chesterton’s Fence" and how it applies to software development and organizational culture. Chesterton’s Fence refers to the idea that before removing or changing a rule, tradition, or practice, one must first understand why it was put in place. We dive into this principle, discuss real-world coding examples, and contrast it with the famous "Five Monkeys Experiment," which explores how behavior and practices can irrationally persist even when the original purpose is forgotten. 🔑 **Key Topics Discussed**: - **Chesterton's Fence**: Learn the origin and meaning behind Chesterton's classic quote: "The more modern type of reformer goes gaily up to it and says, 'I don't see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'" Discover why this concept is critical in both software development and team culture.  - **Applying Chesterton’s Fence to Code**: We walk through a real-world example of legacy product code. Should you refactor, delete, or preserve existing code? Explore how understanding the original intent of code, especially in larger systems, can prevent costly mistakes. - **When to Delete Unit Tests**: What happens when a unit test no longer seems relevant or helpful? We explore how the Chesterton's Fence principle applies to testing, discussing whether old tests should be removed or maintained, and how to balance thoroughness with agility. - **Five Monkeys Experiment**: Chris Lucian shares insights from the famous psychological experiment that demonstrates how practices can become entrenched even when the original purpose is long forgotten. This complements the discussion of Chesterton’s Fence by examining how some habits and behaviors persist without rationale. We discuss strategies for assessing when it's time to dig deeper or when it's acceptable to move forward without full understanding. While it's important to understand why something exists, can too much time be spent analyzing before making changes?  - **Domain-Driven Design (DDD) and Behavior-Driven Development (BDD)**: We explore how principles from DDD and BDD can help teams bake the purpose and intent directly into code, making it easier to understand why a particular rule, function, or test exists in the first place. By the end of the episode, you’ll gain a deeper understanding of how Chesterton’s Fence and the Five Monkeys Experiment apply to your day-to-day decisions in software development, testing, and even team dynamics. Whether you’re dealing with legacy code, outdated tests, or long-standing team practices, this episode provides practical insights to help you make thoughtful, informed decisions. 🎥 **Subscribe and Stay Updated**: Don't miss this insightful episode! Be sure to subscribe to the Mob Mentality Show on your favorite podcast platform or YouTube.  Video and Show Notes: https://youtu.be/a2bdNOsM_r0 

In this Mob Mentality Show episode, Chris Lucian and Austin Chadwick dive into the complexities of modern CI/CD (Continuous Integration / Continuous Delivery) pipeline code and IaC (Infrastructure as Code), exploring why these critical components of software delivery often exhibit the same problematic attributes as classic Legacy Code. Drawing inspiration from Michael Feathers' seminal book *Working Effectively with Legacy Code*, they analyze the paradox of cutting-edge DevOps practices turning into technical debt almost as soon as they're written. ### Episode Highlights: - **CI/CD Pipeline Code and Legacy Code Parallels**: Why does so much CI/CD and IaC code resemble legacy code? Despite being crucial for continuous delivery and automation, CI/CD pipelines can become fragile, difficult to change, and filled with technical debt if not handled carefully. Austin and Chris discuss why this phenomenon is so common and what makes the codebases for CI/CD pipelines especially prone to these issues.    - **“Edit and Pray” vs. TDD Confidence**: Do your CI/CD changes feel like a roll of the dice? Chris and Austin compare how the lack of test-driven development (TDD) practices in CI/CD code leads to “edit and pray” scenarios. They discuss the confidence that TDD brings to traditional application development and how applying similar principles could reduce fragility in CI/CD code. - **The Pitfalls of YAML in IaC**: Is the problem inherent to YAML? The hosts explore whether the complexity of YAML syntax and configurations is the root cause of the brittleness often found in IaC. They provide real-world examples of IaC configurations that suffer from high cyclomatic complexity—making them feel more like full-blown applications rather than simple configuration files. - **Fear of Change in CI/CD and IaC**: Why are developers often afraid to modify CI/CD pipeline code or IaC? Chris and Austin highlight the psychological aspects of fragile infrastructure—where fear of unintended consequences and lack of fast feedback loops result in slower iterations and more bugs. They explore why these codebases are often re-written from scratch instead of extended and safely enhanced. - **Reducing Fragility through Experiments**: The episode features a recent experiment where CI/CD pipeline code was developed in Python using TDD and separation of concerns. This case study reveals the pros and cons of less YAML and a shift towards more code-based "configurations." Could this approach be a solution to reducing brittleness in IaC and pipelines? - **A World Without Brittle Pipelines?**: Imagine a world without fragile pipelines and brittle configuration files. Chris and Austin discuss strategies to move towards more resilient infrastructure and how teams can focus on improving feedback loops, reducing complexity, and enabling safer, faster CI/CD iterations. Join Chris and Austin as they explore these and other crucial topics that are impacting DevOps teams around the world. Whether you're struggling with high bug rates in your pipelines, slow feedback loops, or simply want to better understand how to manage the complexity of modern infrastructure, this episode is for you! Video and Show Notes: https://youtu.be/3Cs-j055b9g 

In this episode of the Mob Mentality Show, we explore the unintended consequences and pitfalls of relying too heavily on metrics with a dive into Goodhart’s Law. If you’ve ever wondered why well-intentioned measurements can backfire and cause harmful behaviors in software development, leadership, and beyond, then this episode is for you! **What is Goodhart’s Law?** Goodhart’s Law states that “When a measure becomes a target, it ceases to be a good measure.” This means that when metrics are used as goals, people tend to optimize for the metric itself rather than the underlying value or outcome it represents.  **How Can Metrics Destroy Collaboration?** Chris shares an intriguing story about two teams set up to compete against each other, only to find that the focus on “winning” metrics led to a breakdown in communication and collaboration. Instead of fostering teamwork, the metrics created silos and a toxic environment.  **Examples of Bad Metrics in Software Development** We go through specific metrics that have led to bad behaviors in software teams, such as: - **Test Coverage Metrics**: How a narrow focus on test coverage can lead to tests that do nothing but improve the metric, without actually asserting anything or improving software quality. - **Points-per-Person Metrics**: Why measuring productivity at an individual level (e.g., story points completed per person) damages team dynamics and led to cutting corners.  **Are There Any Good Metrics?** Is it possible to use metrics without falling into the Goodhart’s Law trap? We discuss whether certain collective measures like **DORA Metrics** can provide value without the same issues. **Metrics for Conversations, Not Evaluation** One key takeaway is the distinction between metrics that trigger healthy conversations vs. those used to make evaluative judgments of a team from a distance. When metrics become evaluative rather than formative, they risk distorting behaviors and eroding psychological safety. **Leading Measures vs. Lagging Measures** We also touch on insights from *The 4 Disciplines of Execution* and its perspective on leading measures vs. lagging measures.  **Managing Teams and Incentives at Scale** Finally, we tackle the challenge of managing people and teams at scale. Incentive structures that overemphasize metrics can lead to counterproductive behaviors, burnout, and loss of motivation. We emphasize the anti-pattern of metrics-driven management without side-by-side in-context coaching. If you’ve ever experienced the pitfalls of metrics-driven environments or are seeking ways to improve measurement practices in your teams, this episode is packed with lessons learned, cautionary tales, and actionable advice. Don’t miss it! Video and Show Notes: https://youtu.be/MiySzmDRYA8 

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 

Dave Copeland, an agile development expert with a rich background in transitioning from government waterfall projects to startup agility, dives deep into key agile principles like SRP, YAGNI, and DRY. He shares insights on the dangers of rigidly following agile aphorisms, highlighting how misunderstandings can lead to poor outcomes. The discussion emphasizes the importance of context and nuance over strict adherence and tackles the balance between over-engineering and under-engineering, drawing on real-world examples to provide clarity in agile practices.