The Bike Shed

For developers, impersonation can be a powerful tool, but with great power comes great responsibility. In today’s episode, hosts Stephanie and Joël explore the complexities of implementing impersonation features in software development, giving you the ability to take over someone’s account and act as the user. They delve into the pros and cons of impersonation, from how it can help with debugging and customer support to its prime drawbacks regarding security and auditing issues. Discover why the need for impersonation is often a sign of poor admin tooling, alternative solutions to true impersonation, and the scenarios where impersonation might be the most pragmatic approach. You’ll also learn why they advocate for understanding the root problem and considering alternative solutions before implementing impersonation. Tune in today for a deep dive into impersonation and the best ways to use it (or not use it)!
 Key Points From This Episode: What’s new in Stephanie’s world: how Notion Calendar is helping her manage her schedule. Joël’s quest to find a health plan: how he used a spreadsheet to compare his options. A client request to build an impersonation feature, and why Joël has mixed feelings about it. What an impersonation tool does: it allows you to take over someone’s account. When it’s useful to use implementation as a feature, like for debugging and support. Potential risks and responsibilities associated with impersonation. Why the need for impersonation often indicates poor admin tooling. Technical and security implications of impersonation. Solutions for logging the audit trail when you’re doing impersonation. Differentiating between the logged-in user and the user you’re rendering views for. Building an app that isn’t as tightly coupled to the “current user.” Suggested alternatives to true impersonation. The value of cross-functional teams and collaborative problem-solving. Links Mentioned in Today’s Episode: Mailtrap (https://l.rw.rw/the_bike_shed) Notion Calendar (https://www.notion.com/product/calendar) 'Implementing Impersonation' (https://jamie.ideasasylum.com/2018/09/29/implementing-impersonation) Sustainable Web Development with Ruby on Rails (https://sustainable-rails.com/) The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/) Joël Quenneville on X (https://x.com/joelquen) Support The Bike Shed (https://github.com/sponsors/thoughtbot) WorkOS (https://workos.com/)

When is it time for a rewrite? How do you justify it? If you’re tasked with one, how do you approach it? In today’s episode of The Bike Shed, we dive into the tough question of software rewrites, sharing firsthand experiences that reveal why these projects are often more complicated and risky than they first appear. We unpack critical factors that make or break a rewrite, from balancing developer satisfaction with business value to managing stakeholder expectations when costs and timelines stretch unexpectedly. You’ll hear about real-world rewrite pitfalls like downtime and reintroducing bugs, as well as strategies for achieving similar improvements through incremental changes or refactoring instead. If you’re a developer or team lead considering a rewrite, this conversation offers a pragmatic perspective that could save your team time, effort, and potential setbacks. Tune in to learn how to make the best call for your codebase and find out when a rewrite might actually be necessary! Key Points From This Episode: Accessible selectors versus test IDs: best practices in Capybara and React Testing Library. Balancing test coverage with pragmatism and risk tolerance with Good Enough Testing. Software rewrites and the tough questions around deciding when they're necessary. The importance of prioritizing business value over frustrations with the current codebase. Drawbacks of rewrites, such as downtime, data loss, and reintroducing past bugs. Risks of “grass is greener” thinking and using mocked data in demos. Unrealistic expectations of full feature parity and why an MVP approach is better. How incremental refactoring can achieve similar goals to a complete rewrite. The appeal and hubris of a “fresh start” and why it’s much more complex than that. Balancing innovation with practicality: ways to introduce new elements without rewriting. An example that illustrates when a rewrite might actually be necessary. Reasons that early prototypes and test builds are the best candidates for rewrites. Links Mentioned in Today’s Episode: Mailtrap (https://l.rw.rw/the_bike_shed) WorkOS (http://workos.com/) Matt Brictson: ‘Simplify your Capybara selectors’ (https://mattbrictson.com/blog/simplify-capybara-selectors) React Testing Library Guidelines (https://testing-library.com/docs/queries/about/#priority) Capybara Accessibility Selectors (https://github.com/citizensadvice/capybara_accessible_selectors) Good Enough Testing (https://goodenoughtesting.com/) ‘RailsConf 2023: The Math Every Programmer Needs by Joël Quenneville’ (https://youtu.be/fMetBx77vKY) ‘Testing Your Edge Cases’ (https://thoughtbot.com/blog/testing-your-edge-cases) 'Working Iteratively' (https://thoughtbot.com/blog/working-iteratively) 'Technical Considerations to Help Scale Your Product' (https://thoughtbot.com/blog/technical-considerations-when-scaling-your-application) Dan McKinley: ‘Choose Boring Technology' (https://mcfunley.com/choose-boring-technology) The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/) Joël Quenneville on X (https://x.com/joelquen) Support The Bike Shed (https://github.com/sponsors/thoughtbot)

Does having smaller, more frequent iterations help to ease your cognitive load? During this episode, we discuss the benefits and challenges of working iteratively and whether or not it can prevent costly errors. You’ll hear about juggling individual pieces effectively, factors that incentivize and de-incentivize working iteratively, and how Joël gauges whether or not a project should be broken up into smaller tasks. It can be hard to adopt small iterations, and this conversation also touches on the idea of ‘good enough code’ and discusses how agility can reduce the cost of making changes. Tuning in, you’ll hear about some of the challenges of keeping up with changes as they evolve and why it is beneficial to do so. You will also be equipped with a thought experiment involving elephant carpaccio to build your understanding of working iteratively, explore the challenge of keeping up with evolving changes, and more. Thanks for listening. Key Points From This Episode: Stephanie shares a recent mishap that happened at work and what she learned from it. Unpacking pressures and other aspects that may have contributed to the error. Joël’s recent travels and his fresh appreciation for fall. The cost of an incident occurring, how this increases, and the role of code review. Benefits and pitfalls of more regular code review. Why working with smaller chunks of work is helpful for Joël’s focus. Juggling individual pieces effectively. Factors that de-incentivize working iteratively such as waiting on 24-hour quality control processes. How working iteratively can facilitate better communication. Why Joël feels that work that spans a few days should be broken up into smaller chunks. The idea of ‘good enough code’. How agility can reduce the cost of making changes. Using the elephant carpaccio exercise to bolster your understanding of working iteratively. The challenge of keeping up with changes as they evolve and why it is beneficial to do so. Involvement from the team and the capacity to change course. Links Mentioned in Today’s Episode: WorkOS (http://workos.com/) Working Incrementally (https://bikeshed.thoughtbot.com/361) Working Iteratively (https://thoughtbot.com/blog/working-iteratively) Elephant Carpaccio Exercise (https://docs.google.com/document/u/1/d/1TCuuu-8Mm14oxsOnlk8DqfZAA1cvtYu9WGv67Yj_sSk/pub) The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/) Joël Quenneville on X (https://x.com/joelquen) Support The Bike Shed (https://github.com/sponsors/thoughtbot)

What’s the difference between solving problems and recognizing patterns, and why does it matter for developers? In this episode, Stephanie and Joël discuss transitioning from collecting solutions to identifying patterns applicable to broader contexts in software development. They explore the role of heuristics, common misconceptions among junior and intermediate developers, and strategies for leveling up from a solution-focused mindset to thinking in patterns. They also discuss their experiences of moving through this transition during their careers and share advice for upcoming software developers to navigate it successfully. They explore how learning abstraction, engaging in code reviews, and developing a strong intuition for code quality help developers grow. Uncover the issue of over-applying patterns and gain insights into the benefits of broader, reusable approaches in code development. Join us to discover how to build your own set of coding heuristics, the pitfalls of pattern misuse, and how to become a more thoughtful developer. Tune in now! Key Points From This Episode: Stephanie unpacks the differences between patterns and solutions. The role of software development experience in recognizing patterns. Why transitioning from solving problems to recognizing patterns is crucial. Joël and Stephanie talk about the challenges of learning abstraction. Hear pragmatic strategies for implementing patterns effectively. How junior developers can build their own set of heuristics for code quality. Discover valuable tools and techniques to identify patterns in your work. Find out about approaches to documenting, learning, and sharing patterns. Gain insights into the process of refactoring a solution into a pattern. Outlining the common mistakes developers make and the pitfalls to avoid. Steps for navigating disagreements and feedback in a team environment. Links Mentioned in Today’s Episode: WorkOS (http://workos.com/) RubyConf 2021 - The Intro to Abstraction I Wish I'd Received (https://www.youtube.com/watch?v=m0dC5RmxcFk) 'Ruby Science' (https://thoughtbot.com/ruby-science/introduction.html) Refactoring.Guru (https://refactoring.guru/) Thoughtbot code review guide (https://github.com/thoughtbot/guides/blob/main/code-review/README.md) The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/) Joël Quenneville on X (https://x.com/joelquen) Support The Bike Shed (https://github.com/sponsors/thoughtbot)

Learning from other developers is an important ingredient to your success. During this episode, Joël Quenneville is joined by Stefanni Brasil, Senior Developer at Thoughtbot, and core maintainer of faker-ruby. To open our conversation, she shares the details of her experience at the Rails World conference in Toronto and the projects she enjoyed seeing most. Next, we explore the challenge of Mac versus Windows and how these programs interact with Ruby on Rails and dive into Stefanni’s involvement in Open Source for Thoughtbot and beyond; what she loves about it, and how she is working to educate others and expand the current limitations that people experience. This episode is also dedicated to the upcoming Open Source Summit that Stefanni is planning on 25 October 2024, what to expect, and how you can get involved. Thanks for listening! Key Points From This Episode: Introducing and catching up with Thoughtbot Senior Developer and maintainer of faker-ruby, Stefanni Brasil. Her experience at the Rails World conference in Toronto and the projects she found most inspiring. Why accessibility remains a key topic. How Ruby on Rails translates on Mac and Windows. Stefanni’s involvement in Open Source and why she enjoys it. Her experience as core maintainer at faker-ruby. Ideas she is exploring around Jeremy Evans’ book Polished Ruby Programming and the direction of Faker. Involvement in Thoughtbot’s Open Source and how it drew her in initially. The coaching series on Open Source that she participated in earlier this year. What motivated her to create a public Google doc on Open Source maintenance. An upcoming event: the Open Source Summit. The time commitment expected from attendees. How Stefanni intends to interact with guests and the talk that she will give at the event. Why everyone is welcome to engage at any level they are comfortable with. Links Mentioned in Today’s Episode: Stefanni Brasil (https://www.stefannibrasil.me/) Stefanni Brasil on X (https://x.com/stefannibrasil) Thoughtbot Open Summit (https://thoughtbot.com/events/open-summit) Open Source Issues doc (https://docs.google.com/document/d/1zok6snap6T6f4Z1H7mP9JomNczAvPEEqCEnIg42dkU4/edit#heading=h.rq72izdz9oh6) Open Source at Thoughtbot (https://thoughtbot.com/open-source) Polished Ruby Programming (https://www.packtpub.com/en-us/product/polished-ruby-programming-9781801072724) Faker Gem (https://github.com/faker-ruby/faker) Rails World
 (https://rubyonrails.org/world/) The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/)

What is a program? Your answer to this question will determine the paradigm through which you view programming. During this episode, you’ll come to understand how things change once you develop an awareness of your paradigm, and what. To kick off this episode, Stephanie shares key insights she took from Planet Argon’s 2024 Ruby on Rails survey and dives deeper into her history with Ruby on Rails. Next, we dive into the definition of a paradigm and unpack three different paradigms you might hold as a developer: procedural, object-oriented, and functional. Considering how each of these impacts the way that you might approach your work as a developer, and what you can learn from the ones that are less familiar to you. Joël describes his scripting style and evaluates the concept of pure functions and their place in development, and we close by digging deeper into how your paradigm might impact the code that you write. Tune in to hear all this and more. Key Points From This Episode: The EPI feature that Joël has started to build out for his client. Why Stephanie is excited about the results of Planet Argon’s 2024 Ruby on Rails community survey. What a procedural program is: programming envisions a program as a series of instructions to a computer. Defining an object-oriented paradigm: programming envisions a program as the behavior that emerges from objects talking to each other. How a functional paradigm envisions a program as a series of data transformations. Alan Turing and Alonzo Church’s approach to understanding this. How a lot of the foundations of computer science came to be built before we had computers. Using Ruby to make judgments and assessing whether or not this is a procedural habit. Why Joël describes his scripting style as being very procedural. Unpacking the meaning of functional programming. Evaluating the concept of pure functions. Considering how your paradigm may impact the Ruby code that you write. Links Mentioned in Today’s Episode: 2024 Ruby on Rails Community Survey (https://railsdeveloper.com/survey/2024/) Church-Turing Thesis (https://ocw.mit.edu/courses/24-242-logic-ii-spring-2004/489f7e42fb619645158d7c21a8fb83ad_chuh_trng_thesis.pdf) Dynamic type systems are not inherently more open (https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/) What is Functional Programming? (http://blog.jenkster.com/2015/12/what-is-functional-programming.html) Blocks as an abstraction vs for loops (https://thoughtbot.com/blog/special-cases) Functional core imperative shell (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell) Testing objects with a functional mindset
 (https://thoughtbot.com/blog/functional-viewpoints-on-testing-objectoriented-code) The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/) Support The Bike Shed (https://github.com/sponsors/thoughtbot)

For a long time, Programming Ruby was the authority in the developing world. Now, a much-needed update has been published. During this conversation, we are joined by Noel Rappin, who shares how his frustration at the idea of static type in Ruby motivated him to investigate why he felt this way, as he published his findings in The Pickaxe Book. We discuss how this book differs from previous material he has published, explore a recent blog post series that explored the idea of failing fast, and address the widespread opinion that developers should take a simpler approach that is more accessible. Noel also explores the responsibility of understanding how readers consume material and the importance of providing thorough context as an author, how Programming Ruby became the most significant programming reference, and the surprising journey that led Noel to realize he was able to provide an updated version of the theory in it. Next, we dive into some of the more opinionated blog posts Noel has posted and the harshest feedback he has received in response to them. You’ll also hear about his research and learning during the act of writing the book. Join us today to hear all this and more. Key Points From This Episode: Noel Rappin’s recently published work, The Pickaxe Book, on current versions of Ruby. The inception of the book during discussions about the collision of Sorbet and Ruby. How his background made him comfortable with the idea that there are no static types. A recent blog post series and how it answered a question about failing fast. Considering whether developers pursue simpler things that are more accessible to a wider range of coders. The problem of thoroughness and longevity in writing instructional material. Developing awareness of how readers consume and contextualize theory and opinion. How Programming Ruby became the most significant programming reference. Noel’s updated version of this material in his latest book. His blog posts on real-life applications of Ruby and the feedback he receives. How he goes about framing blog posts as opinion or instruction. Determining what community consensus is. The bewilderment that often accompanies onboarding sessions. Research and learning leading up to writing and publishing the book. Feedback and reviews on the book. Links Mentioned in Today’s Episode: Noel Rappin (https://noelrappin.com/) Noel Rappin on X (https://x.com/noelrap) Programming Ruby (https://pragprog.com/titles/ruby5/programming-ruby-3-3-5th-edition/)
 How Not to Use Static Typing in Ruby (https://noelrappin.com/blog/2024/09/how-not-to-use-static-typing-in-ruby/)
 David Copeland Talk (https://www.youtube.com/watch?v=unpJ9qRjdMw)
 Better Know a Ruby Thing (https://noelrappin.com/tags/better_know/)
 How To Manage Duplicate Test Setup, Or Can I Interest You in Weird RSpec? (https://noelrappin.com/blog/2023/12/how-to-manage-duplicate-test-setup-or-can-i-interest-you-in-weird-rspec/) 
 Better Know a Ruby Thing: On The Use of Private Methods (https://noelrappin.com/blog/2024/06/better-know-access-control-part-2/) Standardrb (https://github.com/standardrb/standard) Rails Test Prescriptions (https://www.amazon.com/Rails-Test-Prescriptions-Pragmatic-Programmers/dp/1934356646) Programming Ruby: A Pragmatic Programmer’s Guide (https://amazon.com/Programming-Ruby-Pragmatic-Programmers-Guide/dp/0201710897)
 The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/) Support The Bike Shed (https://github.com/sponsors/thoughtbot)

When does it make sense to step away from Rails conventions? What are the limits of convention over configuration? While Rails conventions provide a solid foundation, there are times when customization is necessary to meet specific project needs. In this episode, Joël and Stephanie dive into the tradeoffs of breaking away from Rails defaults. They explore the limits of convention over configuration and share their experiences with customizing beyond the typical Rails setup. Joël offers insights from a recent project where the client opted for all dry-rb objects, and they unpack the benefits and potential challenges of this approach. Stephanie talks about why people tend to shy away from certain Ruby features and her lessons regarding leveraging callbacks for code development. Explore different testing frameworks, the situations when following Ruby defaults is better, the benefits of the ActiveModel ecosystem, and more! Whether you are a Rails purist or looking to bend the rules, this episode will help you understand the pros and cons of stepping outside the Ruby on Rails box. Don’t miss it! Key Points From This Episode: Joël shares details about a large-scale refactoring initiative he has been working on. Stephanie’s recent legacy-code production problem and lessons from her experience. What Joël would have done differently when building his refactoring initiative. The problems of renaming background applications during code development. Why the open-close principle is valuable for making class changes to a system. Reasons that a migration strategy is vital for navigating new and legacy code. Explore approaches for overcoming synchronization issues between systems. Learn about the concept of connascence for coupling systems together. Considerations for using asynchronous tools with a connascence approach. Practical ways to maintain naming consistency during code development. The importance of differentiating between web and business-logic layers. Situations where relying on callbacks for connascence becomes problematic. Other issues that callback problems can reveal during code development. Joël unpacks the scenarios where he deviates from the Ruby on Rails standard. Frameworks for testing code and final takeaways from Joël and Stephanie. Links Mentioned in Today’s Episode: 'Refactoring Legacy Code with the Strangler Fig Pattern' (https://shopify.engineering/refactoring-legacy-code-strangler-fig-pattern) Connascence of Name (CoN) (https://thoughtbot.com/blog/connascence-as-a-vocabulary-to-discuss-coupling#connascence-of-name-con) ActiveModel docs (https://guides.rubyonrails.org/active_model_basics.html) GitHub | activemodel (https://github.com/rails/rails/tree/main/activemodel) 'Vanilla Rails is plenty' (https://dev.37signals.com/vanilla-rails-is-plenty/) GitHub | minitest (https://github.com/seattlerb/minitest) GitHub | test-unit (https://github.com/test-unit/test-unit) Episode 435: Cohesive Code with Jared Norman (https://bikeshed.thoughtbot.com/435) Ruby on Rails
The Bike Shed (https://rubyonrails.org) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/) Support The Bike Shed (https://github.com/sponsors/thoughtbot)

How can asynchronous programming transform your Ruby on Rails applications? Today, Stephanie sits down with Hello Weather co-creator Trevor Turk to unpack asynchronous programming in Ruby on Rails. Trevor Turk is a seasoned software developer known for his work on Hello Weather, a minimalist weather app that delivers essential weather data quickly and precisely. He’s also the creator of Weather Machine, an advanced weather data platform designed to serve reliable and highly accurate forecasts via API. With a background that includes work at innovative tech companies, Trevor brings years of experience in developing intuitive, user-friendly digital tools. Trevor talks about the focus of his API work, the complexity of web-based apps, and what makes Hello Weather unique. He explains the fundamentals of asynchronous programming within the Ruby on Rails framework and why it is an approach all programmers should consider. Explore the nuances of programming for different data sources, how he leverages fibers and threads for the Hello Weather platform, and why asynchronous programming is not a silver bullet for application development. Discover how to start using asynchronous methods, the various asynchronous tools available in Ruby, and why experimenting with concurrent programming is essential. Join us to gain insights into why including asynchronous tools is vital for the Ruby on Rails ecosystem, improving platforms through open-source development, how to help improve the adoption of asynchronous tools in Ruby, and more. Tune in now! Key Points From This Episode: Introduction to Turk and his background in Ruby on Rails. Details about his companies Hello Weather and Weather Machine. The innovative features that the Hello Weather platform offers. Hear how Hello Weather transitioned from a web-based to an application. Why he needed to alter his programming approach to scale the company. How he came across the concept of asynchronous programming. Discover how using fibers is different from using threads in Ruby. Find out about the different use cases of asynchronous programming. Learn about the benefits of implementing concurrent programming. Trevor shares the challenges of working with different versions of Ruby. His role in enhancing asynchronous methods within the Ruby framework. Common misconceptions of working with Ruby on Rails. Final takeaways for those interested in asynchronous programming. Links Mentioned in Today’s Episode: Trevor Turk on LinkedIn (https://www.linkedin.com/in/trevorturk/) Trevor Turk on X (https://x.com/trevorturk) Trevor Turk on Threads (https://www.threads.net/@trevorturk) Hello Weather (https://helloweather.com/) Weather Machine (https://weathermachine.io) GitHub | async gem (https://github.com/socketry/async) GitHub | falcon gem (https://github.com/socketry/falcon) 'Async Ruby on Rails' (https://thoughtbot.com/blog/async-ruby-on-rails) load_async (https://api.rubyonrails.org/classes/ActiveRecord/Relation.html#method-i-load_async) Episode 437: Contributing to Open Source in the Midst of Daily Work with Steve Polito (https://bikeshed.thoughtbot.com/437) GitHub | Action Cable server adapter (https://github.com/rails/rails/pull/50979) ActiveRecord connection checkout caching (https://github.com/rails/rails/pull/50793) Ruby on Rails
The Bike Shed (https://rubyonrails.org/) The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/) Support The Bike Shed (https://github.com/sponsors/thoughtbot)

Writing abstractions in tests can be surprisingly similar to storytelling. The most masterful stories are those where the author has stripped away all of the extra information, and given you just enough knowledge to be immersed and aware of what is going on. But striking that balance can be tricky, both in storytelling and abstractions in tests. Too much information and you risk overwhelming the reader. Too little and they won’t understand why things are operating the way they are. Today, Stephanie and Joël get into some of the more controversial practices around testing, why people use them, and how to strike the right balance with your information. They discuss the most common motivations for introducing abstractions, from improved readability to simplifying the test’s purpose and the types of tests where they are most likely to introduce abstractions. Our hosts also reflect on how they feel about different abstractions in tests – like custom matchers and shared examples – outlining when they reach for them, and the tradeoffs and benefits that come with each. To learn more about how to find the perfect level of abstraction, be sure to tune in! Key Points From This Episode: What’s new in Joël’s world; mocking out screens for processes or a new bit of UI. The new tool Stephanie’s using for reading on the web: Reader by Readwise. Today’s topic: controversial practices around testing. How Stephanie and Joël feel about looping through arrays and having IT blocks for each. The most common motivations for introducing abstractions or helper methods into your tests. Pros and cons of factories as abstractions in testing. Types of tests where Joël and Stephanie are more likely to introduce abstractions. Using page objects in system tests to improve user experience. Finding the balance between too little and too much information with abstraction in testing. Why Stephanie has been enjoying fancier matchers like RSpecs. Top uses of custom matchers, especially for specialized error messaging. Why Stephanie prefers custom matchers over shared examples. Using helper methods as a lighter version of abstraction. Differences and similarities between abstractions in tests versus application code. A reminder to keep your goals in mind when using abstraction. Links Mentioned in Today’s Episode: Reader by Readwise (https://readwise.io/read) Why factories (https://thoughtbot.com/blog/why-factories) Why not factories (https://thoughtbot.com/blog/speed-up-tests-by-selectively-avoiding-factory-bot) Capybara at a single level of abstraction (https://thoughtbot.com/blog/acceptance-tests-at-a-single-level-of-abstraction) Writing custom RSpec matchers (https://thoughtbot.com/blog/acceptance-tests-at-a-single-level-of-abstraction) Value objects shared examples (https://thoughtbot.com/blog/value-object-semantics-in-ruby) 'DRY is about knowledge' (https://verraes.net/2014/08/dry-is-about-knowledge/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/)

Are you passionate about open source but struggling to find time amidst your daily work? Today on the podcast, Joël Quenneville sits down with Steve Polito to discuss practical strategies for making meaningful contributions to the open-source community, even when your schedule is packed. Steve is a developer with extensive experience in the open-source world seamlessly. He’s known for his ability to integrate open-source contributions into his daily workflow, all while maintaining high productivity in his professional role. In our conversation, we explore balancing professional responsibilities with open-source contributions. Steve walks us through his process, from the importance of keeping notes to leveraging Rails issue templates. Discover strategies for contributing to open-source work during work hours, the benefits of utilizing existing processes, and why extending the success of your work to the larger developer community is essential. Join us to hear recommendations for handling pull requests with Ruby on Rails, tips for using reproduction scripts, why you should release reports early and often, and much more. Tune in and learn how to seamlessly integrate open-source contributions into your daily workflow with Steve Polito! Key Points From This Episode: Joël and Steve catch up and share what they are currently working on. Transitioning synchronous processing in a web request to the background. An update on Steve’s “building in public” approach and its reception at thoughtbot. How Steve chooses to document and track his development process. Find out how he uses templates to enhance and increase productivity. Why open-source work does not need to be done during your free time. Ways you can contribute to open-source projects during normal work hours. The benefits of sharing troubleshooting solutions with the open-source community. Pull request lessons from his time working with Ruby on Rails. Reasons why issues have a lower barrier to entry with Ruby on Rails. His unique approach of using issues, pull requests, and suspenders. Identifying aspects of everyday work that are suitable for open-source projects. Links Mentioned in Today’s Episode: Steve Polito (https://stevepolito.design/) Steve Polito on X (https://x.com/stevepolitodsgn) Episode 351: Learning in Public (https://bikeshed.thoughtbot.com/351) Rails issue templates (https://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#create-an-executable-test-case) Suspenders (https://github.com/thoughtbot/suspenders) Mermaid (https://mermaid.js.org/) Ruby on Rails (https://rubyonrails.org/) WorkOS (https://workos.com/) thoughtbot (https://thoughtbot.com) Joel Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/)

How can we optimize our time and environment to do our best work as developers? In today’s episode, we are joined by Stephanie Viccari, former co-host of The Bike Shed and Senior Developer at thoughtbot, to unpack the steps for creating work conditions that enhance productivity. In this conversation, we delve into her unique communication style and approach to optimizing productivity within a team. She explains why she decided to hang up her consulting hat and join the product team at Cisco Meraki, her new role there, and how her consulting skills benefit her new position. Tuning in, you’ll discover the key to empathetic communication, how to unblock yourself, tips to help you navigate different communication styles, and why you should advocate for your needs. Stephanie also shares strategies for effective communication and recommendations for managing ‘deep work’ when your time is limited. Gain valuable insights into how to uncover what makes your skillset unique, why it takes a team to manage complex software, benchmarking performance, keeping motivated during stressful times, and more. To learn how to create the conditions for your best work and unlock your full potential as a developer, don’t miss this episode with Stephanie Viccari! Key Points From This Episode: Catch up with Stephanie: what she’s been up to since leaving thoughtbot. How she mastered optimizing workflows and enhancing productivity. Similarities and differences between working as a consultant versus on a product team. Ways Stephanie’s mindset shifted from individual thinking to team-oriented strategies. Nuances of advocating for changes as a consultant versus within a product team. What software developers need to achieve their best work. The role of trust between managers and developers in effective problem-solving. Tips and recommendations for identifying and delivering your best work. Practical advice for doing your best work, even when you feel demotivated. Why it's important not to steal from tomorrow's productivity. Links Mentioned in Today’s Episode: Stephanie Viccari (https://sviccari.github.io/) Stephanie Viccari on LinkedIn (https://www.linkedin.com/in/sviccari/) Stephanie Viccari on X (https://x.com/sviccari) Stephanie Viccari on GitHub (https://github.com/sviccari) Cisco Meraki (https://meraki.cisco.com/) thoughtbot (https://thoughtbot.com/) Stephanie Viccari’s The Bike Shed’s Episodes (https://bikeshed.thoughtbot.com/hosts/steph-viccari) ‘Generative AI is not going to build your engineering team for you’ (https://stackoverflow.blog/2024/06/10/generative-ai-is-not-going-to-build-your-engineering-team-for-you/) Joel Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/)

How easy is it for a layperson to understand your systems? Jared Norman is a software consultant, speaker, and host of the Dead Code Podcast who specializes in building e-commerce applications in Ruby on Rails. This episode follows two recent talks at RailsConf and covers a theme that emerged from both of them: coupling and cohesion. Tuning in, you’ll gain insights on how to create more cohesive components to allow for change and improve your understanding of value objects, systems, and more. You’ll also hear about navigating the complexity of domain-driven design and learn how to gauge if your code is easy to understand through a simple rule of thumb. We discuss what it might look like to improve the cohesion of individual objects, identify your systems’ seams to create simplicity, and the liminal space between inheritance and composition and the role of decorators in moving through it. Join us today to hear all this and more! Key Points From This Episode: Introducing Jared Norman recent speaker at RailsConf and Ruby on Rails specialist. Jared’s interests outside of coding: cycling. Themes that emerged from Jared and Stephanie’s talks: coupling and cohesion. A rule of thumb for achieving high cohesion. How value objects tie into the idea of cohesion. Creating more cohesive components in order to have code and systems that are easier to change. The relationships between objects in increasing cohesion and how complex nestings of objects can hinder this. Rearranging systems in order to find seams and create cohesion. Simplifying code in order to facilitate it working independently to support functionality. Improving systems by identifying opportunities for decoupling and other relationships. Inheritance, composition, and decorators and the liminal space between. The complexity of domain-driven design. A rule that indicates when a system is easy to understand. Links Mentioned in Today’s Episode: Jared Norman (https://jardo.dev/) Jared Norman on X (https://x.com/jardonamron) The Most Useful Design Pattern (https://www.youtube.com/watch?v=0bQVH2IM0Ao) Dead Code (https://shows.acast.com/dead-code) So Writing Tests Feel Painful. What Now? (https://www.youtube.com/watch?v=t5MnS20adG4) Dungeons & Dragons & Rails by Joël Quenneville (https://www.youtube.com/watch?v=T7GdshXgQZE) Building Reusable Object-Oriented Systems: Composition (https://thoughtbot.com/blog/reusable-oo-composition) Debugging at the Boundaries (https://thoughtbot.com/blog/debugging-at-the-boundaries) Working Effectively with Legacy Code (https://www.oreilly.com/library/view/working-effectively-with/0131177052/) Growing Object-Oriented Software Guided by Tests (http://www.growing-object-oriented-software.com/) What’s in a Name (https://www.youtube.com/watch?v=YOQYxgLu5ys) Joel Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/)

It's Calls for Proposals (CFP) season, and in the process of helping our friends and colleagues flesh out their CFPs, we came up with a few questions to help them frame their proposals for success. After learning about the importance of finding your audience and angle of approach for your CFP, we dive into today's main topic – our Git and GitHub workflows. Joel and Stephanie walk us through their current workflows before exploring the differences between main branch and future branch commits. Then, we explore commits editing and why it's okay to make mistakes, commit messages versus GitHub pull requests (PR), what you need to know if you're new to Git, and what you need to understand about PR sizes and Git merge strategies. To end, Joel shares the commit messages that satisfy him the most, and we discover how to make one's life easier when reviewing PRs. Key Points From This Episode: Our CFP framework of questions to help you build a winning proposal. Why it's important to understand who your audience is and who you're speaking to. Ascertaining your angle of approach - how will you tell your story? The ins and outs of Stephanie's current work life. How discipline and particularly, self-discipline relate to our Git and GitHub workflows. Understanding Joel and Stephanie's workflows - how they're similar and how they differ. The differences between main branch and future branch commits. Editing commits and editing commits history, and why it's okay to make mistakes. Commit messages versus GitHub pull requests (PR). Some advice and strategies for those who are new to Git. Discussing Git merge strategies, PR sizes, and online changes. Joel details the types of commit messages that he finds most satisfying. How to make your life easier when reviewing PRs. Links Mentioned in Today’s Episode: RubyConf Rubric 'Working Iteratively’ Good Commit Messages Shotgun Surgery 'Episode 401: Making the Right Thing Easy’ Joel Quenneville on X Joel Quenneville on LinkedIn Support The Bike Shed

Have you ever wondered how improvisation can revolutionize coding? In today’s episode, Stephanie sits down with Kasper Timm Hansen to discuss his innovative “riffing” approach to code development. Kasper is a long-time Ruby developer and former member of the Rails core team. He focuses on Ruby and domain modeling, developing various Ruby gems, and providing consulting services in the developer space. He has become renowned for his approach of “riffing” to software development, particularly in the Ruby on Rails framework. In our conversation, we delve into his unique approach to coding, how it differs from traditional methods, and the benefits of improvisation to code development. Discover the “feeling” part of riffing, the steps to uncovering relationships between models, and why it is okay not to know how to do something. Explore how riffing enhances collaboration, improves communication with and between teams, identifies alternative code, why “clever code” does not make for good solutions, and much more! Tune in to learn how to take your coding skills to the next level and uncover the magic of riffing with Kasper Timm Hansen! Key Points From This Episode: Introduction to Kasper, his background in Ruby, and experience as a consultant. An overview of his RailsConf 2024 presentation on domain modeling. His motivation behind his presentation and the overall reception of the concept. Unpack the concept of “riffing” with code as a developer. Insights into his methodology and how it differs from traditional approaches. Examples of “riffing" and how it benefits the development process. How he determines the best code to implement during his process. Kasper shares how he frames problems and builds solutions. Ways riffing highlights gaps in skillsets early in the development process. Hear about the various ways riffing fosters and improves collaboration. Unpack how riffing can help developers communicate more effectively. Balancing the demands of code review with the riffing approach. Final takeaways for listeners and how to contact Kasper to begin riffing! Links Mentioned in Today’s Episode: Kasper on Github (https://github.com/kaspth), Mastodon (https://ruby.social/@kaspth), LinkedIn (https://www.linkedin.com/in/kasper-timm-hansen-33b151314/), and X (https://twitter.com/kaspth) Riffing on Rails RailsConf talk (https://www.youtube.com/watch?v=vH-mNygyXs0) and slides (https://speakerdeck.com/kaspth/railsconf-2024-riffing-on-rails-sketch-your-way-to-better-designed-code) Riffing on Spotify’s generated mixes (https://www.youtube.com/watch?v=i1MM2EOniPg) with Jeremy Smith Modeling a Kanban board with riffing (https://buttondown.email/kaspth/archive/how-to-approach-modelling-a-kanban-board-in-rails/) Some of Kasper's open source work: * ActiveRecord Associated Object (https://github.com/kaspth/active_record-associated_object) * ActiveJob Performs (https://github.com/kaspth/active_job-performs) * Oaken (https://github.com/kaspth/oaken)

The term ‘nil’ refers to the absence of value, but we often imbue it with much more meaning than just that. Today, hosts Joël and Stephanie discuss the various ways we tend to project extra semantics onto nil and the implications of this before unpacking potential alternatives and trade-offs. Joël and Stephanie highlight some of the key ways programmers project additional meaning onto nil (and why), like when it’s used to create a guest session, and how this can lead to bugs, confusion, and poor user experiences. They discuss solutions to this problem, like introducing objects for improved readability, before taking a closer look at the implications of excessive guard clauses in code. Our hosts also explore the three-state Boolean problem, illustrating the pitfalls of using nullable Booleans, and why you should use default values in your database. Joël then shares insights from the Elm community and how it encourages rigorous checks and structured data modeling to manage nil values effectively.

They advocate for using nil only to represent truly optional data, cautioning against overloading nil with additional meanings that can compromise code clarity and reliability. Joël also shares a fun example of modeling a card deck, explaining why you might be tempted to add extra semantics onto nil, and why the joker always inevitably ends up causing chaos!
 Key Points From This Episode The project Joël is working on and why he’s concerned about bugs and readability. Potential solutions for a confusing constant definition in a nested module. A client work update from Stephanie: cleaning up code and removing dead dependencies. How she used Figjam to discover dependencies and navigate her work. Today’s topic: how programmers project extra semantics onto nil. What makes nil really tricky to use, like forcing you to go down a default path. How nil sweeps the cases you don’t want to think too hard about under the rug. Extra semantics that accompany nil (that you might not know about) like a guest session. Examples of how these semantics mean different things in different contexts. How these can lead to bugs, hard-to-find knowledge, confusion, and poor user experiences. Introducing objects to replace extra nil semantics, improve readability, and other solutions. Some of the reasons why programmers tend to project extra semantics onto nil. How to notice that nil has additional meanings, and when to model it differently. The implications of excessive guard clauses in code. An overview of the three-state Boolean problem with nullable Booleans. Connecting with the Elm community: how it can help you conduct more rigorous checks. Some of the good reasons to have nil as a value in your database. The benefits of using nil only to represent truly optional data. Links Mentioned in Today’s Episode Figjam (https://www.figma.com/figjam/) Miro (https://miro.com/) 'Working Iteratively' blog post (https://thoughtbot.com/blog/working-iteratively) Mermaid.js (https://mermaid.js.org/) Draw.io (https://draw.io/) Check your return values (web) (https://thoughtbot.com/blog/check-return-values-web) Check your return values (API) (https://thoughtbot.com/blog/check-return-values-api) Primitive obsession (https://wiki.c2.com/?PrimitiveObsession) 'Avoid the Three-state Boolean Problem' (https://thoughtbot.com/blog/avoid-the-threestate-boolean-problem) Elm Community (https://elm-lang.org/community) 'The Shape of Data': Modeling a deck of cards (https://thoughtbot.com/blog/modeling-with-union-types#the-shape-of-data) The Bike Shed (https://bikeshed.thoughtbot.com/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/)

Stephanie shares her newfound interest in naming conventions, highlighting a resource called "Classnames" that provides valuable names for programming and design. Joël, in turn, talks about using AI to generate names for D&D characters, emphasizing how AI can help provide inspiration and reasoning behind name suggestions. Then, they shift to Joël's interest in Roman history, where he discusses a blog by a Roman historian that explores distinctions between state and non-state peoples in the ancient Mediterranean. Together, the hosts delve into the importance of asking questions as consultants and developers to understand workflows, question assumptions, and build trust for better onboarding. Stephanie categorizes questions by engagement stages and their social and technical aspects, while Joël highlights how questioning reveals implicit assumptions and speeds up learning. They stress maintaining a curious mindset, using questions during PR reviews, and working with junior developers to foster collaboration. They conclude with advice on documenting answers and using questions for continuous improvement and effective decision-making in development teams. Class names inspiration (https://classnames.paulrobertlloyd.com/) How to Raise a Tribal Army in Pre-Roman Europe, Part II: Government Without States (https://acoup.blog/2024/06/14/collections-how-to-raise-a-tribal-army-in-pre-roman-europe-part-ii-government-without-states/) Diocletian, Constantine, Bedouin Sayings, and Network Defense (https://www.youtube.com/watch?v=qCUI5ryyMSE) The Power of Being New: A Proven Recipe for High Impact (https://hazelweakly.me/blog/the-power-of-being-new--a-proven-recipe-for-high-impact/#the-power-of-being-new-a-proven-recipe-for-high-impact) How to ask good questions (https://jvns.ca/blog/good-questions/) Transcript:  JOËL: Hello and welcome to another episode of the Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, if it has not been clear about just kind of the things I'm mentioning on the podcast the past few weeks, I've been obsessed with naming things lately [chuckles] and just thinking about how to name things, and, yeah, just really excited about...or even just having fun with that more than I used to be as a dev. And I found a really cool resource called "Classnames." Well, it's like just a little website that a designer and developer shared from kind of as an offshoot from his personal website. I'll link it in the show notes. But it's basically just a list of common names that are very useful for programming or even design. It's just to help you find some inspiration when you're stuck trying to find a name for something. And they're general or abstract enough that, you know, it's almost like kind of like a design pattern but a naming pattern [laughs], I suppose. JOËL: Ooh. STEPHANIE: Yeah, right? And so, there's different categories. Like, here's a bunch of words that kind of describe collections. So, if you need to find the name for a containment or a group of things, here's a bunch of kind of words in the English language that might be inspiring. And then, there's also other categories like music for describing kind of the pace or arrangement of things. Fashion, words from fashion can describe, like, the size of things. You know, we talk about T-shirt sizes when we are estimating work. And yeah, I thought it was really cool that there's both things that draw on, you know, domains that most people know in real life, and then also things that are a little more abstract. But yeah, "Classnames" by Paul Robert Lloyd — that's been a fun little resource for me lately. JOËL: Very cool. Have you ever played around at all with using AI to help you come up with the naming? STEPHANIE: I have not. But I know that you and other people in my world have been enjoying using AI for inspiration when they feel a little bit stuck on something and kind of asking like, "Oh, like, how could I name something that is, like, a group of things?" or, you know, a prompt like that. I suspect that that would also be very helpful. JOËL: I've been having fun using that to help me come up with good names for D&D characters, and sometimes they're a little bit on the nose. But if I sort of describe my character, and what's their vibe, and a little bit of, like, what they do and their background, and, like, I've built this whole, like, persona, and then, I just ask the AI, "Hey, what might be some good names for this?" And the AI will give me a bunch of names along with some reasoning for why they think that would be a good match. So, it might be like, oh, you know, the person's name is, I don't know, Starfighter because it evokes their connection to the night sky or whatever because that was a thing that I put in the background. And so, it's really interesting. And sometimes they're, like, just a little too obvious. Like, you don't want, you know, Joe Fighter because he's a fighter. STEPHANIE: And his name is Joe [laughs]. JOËL: Yeah, but some of them are pretty good. STEPHANIE: Cool. Joël, what's new in your world? JOËL: I guess in this episode of how often does Joël think about the Roman Empire... STEPHANIE: Oh my gosh [laughs]. JOËL: Yes [laughs]. STEPHANIE: Spoiler: it's every day [laughs]. JOËL: Whaaat? There's a blog that I enjoy reading from a Roman historian. It's called "A Collection of Unmitigated Pedantry", acoup.blog. He's recently been doing an article series on not the Romans, but rather some of these different societies that are around them, and talking a little bit about a distinction that he calls sort of non-state peoples versus states in the ancient Mediterranean. And what exactly is that distinction? Why does it matter? And those are terms I've heard thrown around, but I've never really, like, understood them. And so, he's, like, digging into a thing that I've had a question about for a while that I've been really appreciating. STEPHANIE: Can you give, like, the reader's digest for me? JOËL: For him, it's about who has the ability to wield violence legitimately. In a state, sort of the state has a monopoly on violence. Whereas in non-state organizations, oftentimes, it's much more personal, so you might have very different sort of nobles or big men who are able to raise, let's say, private armies and wage private war on each other, and that's not seen as, like, some, like, big breakdown of society. It's a legitimate use of force. It's just accepted that that's how society runs. As opposed to in a state, if a, you know, wealthy person decided to raise a private army, that would be seen as a big problem, and the state would either try to put you down or, like, more generally, society would, like, see you as having sort of crossed a line you shouldn't have crossed. STEPHANIE: Hmm, cool. I've been reading a lot of medieval fantasy lately, so this is kind of tickling my brain in that way when I think about, like, what drives different characters to do things, and kind of what the consequences of those things are. JOËL: Right. I think it would be really fascinating to sort of project this framework forwards and look at the European medieval period through that lens. It seems to me that, at least from a basic understanding, that the sort of feudal system seems to be very much in that sort of non-state category. So, I'd be really interested to see sort of a deeper analysis of that. And, you know, maybe he'll do an addendum to this series. Right now, he's mostly looking at the Gauls, the Celtiberians, and the Germanic tribes during the period of the Roman Republic. STEPHANIE: Cool. Okay. Well, I also await the day when you somehow figure how this relates to software [laughter] and inevitably make some mind-blowing connection and do a talk about it [laughs]. JOËL: I mean, theming is always fun. There's a talk that I saw years ago at Strange Loop that was looking at the defense policy of the Roman Emperor Diocletian and the Roman Emperor Constantine, and the ways that they sort of defended the borders of the empire and how they're very different, and then related it to how you might handle network security. STEPHANIE: Whaat? JOËL: And sort of like a, hey, are we using more of a Diocletian approach here, or are we using more of a Constantine approach here? And all of a sudden, just, like, having those labels to put on there and those stories that went with it made, like, what could be a really, like, dry security talk into something that I still remember 10 years later. STEPHANIE: Yeah. Yeah. We love stories. They're memorable. JOËL: So, I'll make sure to link that in the show notes. STEPHANIE: Very cool. JOËL: We've been talking a lot recently about my personal note system, where I keep a bunch of, like, small atomic notes that are all usually based around a single thesis statement. And I was going through that recently, and I found one that was kind of a little bit juicy. So, the thesis is that consultants are professional question-askers. And I'm curious, as a consultant yourself, how do you feel about that idea? STEPHANIE: Well, my first thought would be, how do I get paid to only ask in questions [laughs] or how to communicate in questions and not do anything else [laughs]? It's almost like I'm sure that there is some, like, fantasy character, you know, where it's like, there's some villain or just obstacle where you have this monster character who only talks in questions. And it's like a riddle that you have to solve [laughs] in order to get past. JOËL: I think it's called a three-year-old. STEPHANIE: Wow. Okay. Maybe a three-year-old can do my job then [laughter]. But I do think it's a juicy one, and it's very...I can't wait to hear how you got there, but I think my reaction is yes

Stephanie and Joël discuss the recent announcement of the call for proposals for RubyConf in November. Joël is working on his proposals and encouraging his colleagues at thoughtbot to participate, while Stephanie is excited about the conference being held in her hometown of Chicago! The conversation shifts to Stephanie's recent work, including completing a significant client project and her upcoming two-week refactoring assignment. She shares her enthusiasm for refactoring code to improve its structure and stability, even when it's not her own. Joël and Stephanie also discuss the everyday challenges of maintaining a test suite, such as slowness, flakiness, and excessive database requests. They discuss strategies to balance the test pyramid and adequately test critical paths. Finally, Joël emphasizes the importance of separating side effects from business logic to enhance testability and reduce complexity, and Stephanie highlights the need to address testing pain points and ensure tests add real value to the codebase. RubyConf CFP (https://sessionize.com/rubyconf-2024/) RubyConf CFP coaching (https://docs.google.com/forms/d/e/1FAIpQLScZxDFaHZg8ncQaOiq5tjX0IXvYmQrTfjzpKaM_Bnj5HHaNdw/viewform?pli=1) Testing pyramid (https://thoughtbot.com/blog/rails-test-types-and-the-testing-pyramid) Outside-in testing (https://thoughtbot.com/blog/testing-from-the-outsidein) Writing fewer system specs with request specs (https://thoughtbot.com/blog/faster-tests-with-capybara-and-request-specs) Unnecessary factories (https://thoughtbot.com/blog/speed-up-tests-by-selectively-avoiding-factory-bot) Your Test Suite is Making Too Many Database Calls (https://www.youtube.com/watch?v=LOlG4kqfwcg) Your flaky tests might be time dependent (https://thoughtbot.com/blog/your-flaky-tests-might-be-time-dependent) The Secret Ingredient: How To Understand and Resolve Just About Any Flaky Test (https://www.youtube.com/watch?v=De3-v54jrQo) Separating side effects to improve tests (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) Functional core, imperative shell (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell) Thoughtbot testing articles (https://thoughtbot.com/blog/tags/testing) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: Something that's new in my world is that RubyConf just announced their call for proposals for RubyConf in November. They're open for...we're currently recording in June, and it's open through early July, and they're asking people everywhere to submit talk ideas. I have a few of my own that I'm working with. And then, I'm also trying to mobilize a lot of other colleagues at thoughtbot to get excited to submit. STEPHANIE: Yes, I am personally very excited about this year's RubyConf in November because it's in Chicago, where I live, so I have very little of an excuse not to go [laughs]. I feel like so much of my conference experience is traveling to just kind of, like, other cities in the U.S. that I want to spend some time in and, you know, seeing all of my friends from...my long-distance friends. And it definitely does feel like just a bit of an immersive week, right? And so, I wonder how weird it will feel to be going to this conference and then going home at the end of the night. Yeah, that's just something that I'm a bit curious about. So, yeah, I mean, I am very excited. I hope everyone comes to Chicago. It's a great city. JOËL: I think the pitch that I'm hearing is submit a proposal to the RubyConf CFP to get a chance to get a free ticket to go to RubyConf, where you get to meet Bike Shed co-host Stephanie Minn. STEPHANIE: Yes. Ruby Central should hire me to market this conference [laughter] and that being the main value add of going [laughs], obviously. Jokes aside, I'm excited for you to be doing this initiative again because it was so successful for RailsConf kind of internally at thoughtbot. I think a lot of people submitted proposals for the first time with some of the programming you put on. Are you thinking about doing things any differently from last time, or any new thoughts about this conference cycle? JOËL: I think I'm iterating on what we did last time but trying to keep more or less the same formula. Among other things, people don't always have ideas immediately of what they want to speak about. And so, I have a brainstorming session where we're just going to get together and brainstorm a bunch of topics that are free for anyone to take. And then, either someone can grab one of those topics and pitch a talk on it, or it can be, like, inspiration where they see that it jogs their mind, and they have an idea that then they go off and write a proposal. And so, that allows, I think, a lot of colleagues as well, who are maybe not interested in speaking but might have a lot of great ideas, to participate and sort of really get a lot of that energy going. And then, from there, people who are excited to speak about something can go on to maybe draft a proposal. And then, I've got a couple of other events where we support people in drafting a proposal and reviewing and submitting, things like that. STEPHANIE: Yes, I really love how you're just involving people with, you know, just different skills and interests to be able to support each other, even if, you know, there's someone on our team who's, like, not interested in speaking at all, but they're, like, an ideas person, right? And they would love to see their idea come to life in a talk from someone else. Like, I think that's really cool, and I certainly appreciate it as a not ideas person [laughs]. JOËL: Also, I want to shout out that Ruby Central is doing CFP coaching sessions on June 24th, June 25th, and June 26th, and those are open to anyone. You can sign up. We'll put a link to the signup form in the show notes. If you've never submitted something before and you'd like some tips on what makes for a good CFP, how can you up your chances of getting accepted, or maybe you've submitted before, you just want to get better at it; I recommend joining one of those slots. So, Stephanie, what's new in your world? STEPHANIE: So, I just successfully delivered a big project on my client work last week. So, I'm kind of riding that wave and getting into the next bit of work that I have been assigned for this team, and I'm really excited to do this. But I also, I don't know, I've been just, like, thinking about it quite a bit. Basically, I'm getting to spend two dedicated weeks to just refactoring [laughs] some really, I guess, complicated code that has led to some bugs recently and just needing some love, especially because there's some whiffs of potentially, like, really investing in this area of the product, and people wanting to make sure that the foundation does feel very stable to build on top of for extending and changing that code. And I think I, like, surprised myself by how excited I was to do this because it's not even code I wrote. You know, sometimes when you are the one who wrote code, you're like, oh, like, I would love time to just go back and clean up all these things that I kind of missed the first time around or just couldn't attend to for whatever reason. But yeah, I think I was just a little bit in the peripheries of that code, and I was like, oh, like, just seeing some weird stuff. And now to kind of have the time to be like, oh, this is all I'm going to be doing for two weeks, to, like, really dive into it and get my hands dirty [laughs], I'm very excited. JOËL: I think that refactoring is a thing that can be really fun. And also, when you have a larger chunk of time, like two days, it's easy to sort of get lost in sort of grand visions or projects. How do you kind of balance the, I want to do a lot of refactoring; I want to take on some bigger things while maybe trying to keep some focus or have some prioritization? STEPHANIE: Yeah, that's a great question. I was actually the one who said, like, "I want two weeks on this." And it also helped that, like, there was already some thoughts about, like, where they wanted to go with this area of the codebase and maybe what future features they were thinking about. And there are also a few bugs that I am fixing kind of related to this domain. So, I think that is actually what I started with. And that was really helpful in just kind of orienting myself in, like, the higher impact areas and the places that the pain is felt and exploring there first to, like, get a sense of what is going on here. Because I think that information gathering is really important to be able to kind of start changing the code towards what it wants to be and what other devs want it to be. I actually also started a thread in Slack for my team. I was, like, asking for input on what's the most confusing or, like, hard to reason about files or areas in this particular domain or feature set and got a lot of really good engagement. I was pleasantly surprised [laughs], you know, because sometimes you, like, ask for feedback and just crickets. But I think, for me, it was very affirming that I was, like, exploring something that a lot of people are like, oh, we would love for someone to, you know, have just time to get into this. And they all were really excited for me, too. So, that was pretty cool. JOËL: Interesting. So, it sounds like you sort of budgeted some refactoring time and then, from there, broke it down into a series of a couple of debugging projects and then a couple of, like, more bounded refactoring projects, where, like, specifically, I want to restructure the way this object works or something like that. STEPHANIE: Yeah. I think there was that feeling of wanting

Stephanie has a newfound interest in urban foraging for serviceberries in Chicago. Joël discusses how he uses AI tools like ChatGPT to generate creative Dungeons & Dragons character concepts and backstories, which sparks a broader conversation with Stephanie about AI's role in enhancing the creative process. Together, the hosts delve into professional growth and experience, specifically how to leverage everyday work to foster growth as a software developer. They discuss the importance of self-reflection, note-taking, and synthesizing information to enhance learning and professional development. Stephanie shares her strategies for capturing weekly learnings, while Joël talks about his experiences using tools like Obsidian's mind maps to process and synthesize new information. This leads to a broader conversation on the value of active learning and how structured reflection can turn routine work experiences into meaningful professional growth. Obsidian (https://obsidian.md/) Zettelkasten (https://en.wikipedia.org/wiki/Zettelkasten) Mindmaps in Mermaid.js (https://mermaid.js.org/syntax/mindmap.html) Module Docs episode (https://bikeshed.thoughtbot.com/417) Writing Quality Method docs blog post (https://thoughtbot.com/blog/writing-quality-method-docs) Notetaking for Developers episode (https://bikeshed.thoughtbot.com/357) Learning by Helping blog post (https://thoughtbot.com/blog/learning-by-helping) Transcript:  JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, as of today, while we record this, it's early June, and I have started foraging a little bit for what's called serviceberries, which is a type of tree/shrub that is native to North America. And I feel like it's just one of those, like, things that more people should know about because it makes these little, tiny, you know, delicious fruit that you can just pick off of the tree and have a little snack. And what's really cool about this tree is that, like I said, it's native, at least to where I'm from, and it's a pretty common, like, landscaping tree. So, it has, like, really pretty white flowers in the spring and really beautiful, like, orange kind of foliage in the fall. So, they're everywhere, like, you can, at least where I'm at in Chicago, I see them a lot just out on the sidewalks. And whenever I'm taking a walk, I can just, yeah, like, grab a little fruit and have a little snack on them. It's such a delight. They are a really cool tree. They're great for birds. Birds love to eat the berries, too. And yeah, a lot of people ask my partner, who's an arborist, like, if they're kind of thinking about doing something new with the landscaping at their house, they're like, "Oh, like, what are some things that I should plant?" And serviceberry is his recommendation. And now I'm sharing it with all of our Bike Shed listeners. If you've ever wondered about [laughs] a cool and environmentally beneficial tree [laughs] to add to your front yard, highly recommend, yeah, looking out for them, looking up what they look like, and maybe you also can enjoy some June foraging. JOËL: That's interesting because it sounds like you're foraging in an urban environment, which is typically not what I associate with the idea of foraging. STEPHANIE: Yeah, that's a great point because I live in a city. I don't know, I take what I can get [laughs]. And I forget that you can actually forage for real out in, you know, nature and where there's not raccoons and garbage [laughs]. But yeah, I think I should have prefaced by kind of sharing that this is a way if you do live in a city, to practice some urban foraging, but I'm sure that these trees are also out in the world, but yeah, have proved useful in an urban environment as well. JOËL: It's really fun that you don't have to, like, go out into the countryside to do this activity. It's a thing you can do in the environment that you live in. STEPHANIE: Yeah, that was one of the really cool things that I got into the past couple of years is seeing, even though I live in a city, there's little pieces of nature around me that I can engage with and picking fruit off of people's [inaudible 03:18] [laughs], like, not people's, but, like, parkway trees. Yeah, the serviceberry is also a pretty popular one here that's planted in the Chicago parks. So, yeah, it's just been like, I don't know, a little added delight to my days [laughs], especially, you know, just when you're least expecting it and you stumble upon it. It's very fun. JOËL: That is really fun. It's great to have a, I guess, a snack available wherever you go. STEPHANIE: Anyway, Joël, what is new in your world? JOËL: I've been intersecting two, I guess, hobbies of mine: D&D and AI. I've been playing a lot of one-shot games with friends, and that means that I need to constantly come up with new characters. And I've been exploring what AI can do to help me develop more interesting or compelling character concepts and backstories. And I've been pretty satisfied with the result. STEPHANIE: Cool. Yeah. I mean, if you're playing a lot and having to generate a lot of new ideas, it can be hard if you're, you know, just feeling a little empty [laughs] in terms of, you know, coming up with a whole character. And that reminds me of a conversation that you and I had in person, like, last month as we were talking about just how you've been, you know, experimenting with AI because you had used it to generate images for your RailsConf talk. And I think I connected it to the idea of, like, randomness [laughs] and how just injecting some of that can help spark some more, I think, creativity, or just help you think of things in a new way, especially if you're just, like, having a hard time coming up with stuff on your own. And even if you don't, like, take exactly what's kind of provided to you in a generative AI, it at least, I don't know, kind of presents you with something that you didn't see before, or yeah, it's just something to react to. JOËL: Yeah, it's a great tool for getting unstuck from that kind of writer's block or that, like, blank page feeling. And oftentimes, it'll give you a thing, and you're like, that's not really exactly what I wanted. But it sparks another idea, which is what I actually want. Or sometimes you can be like, "Hey, here's an idea I have. I'm not sure what direction to take it in. Give me a few options." And then, you see that, and you're like, "Oh, that's actually pretty interesting." One thing that I think is interesting is once I've come up with a little bit of the character concept, or maybe even, like, a backstory element...so, I'm using ChatGPT, and it has that concept of memory. And so, throughout the conversation, it keeps bringing it back. So, if I tell it, "Look, this is an element that's going to be core to the character," and then later on, I'm like, "Okay, help me brainstorm some potential character flaws for this character," it'll actually find things that connect back to my, like, core concept, or maybe an element of the backstory. And it'll give me like, you know, 5 or 10 different ideas, and some of them can be actually really good. So, I've really enjoyed doing that. It's not so much to just generate me a character so much as it is like a conversation back and forth of like, "Okay, help me come up with a vibe for it. Okay, now that I have a vibe or a backstory element or, like, a concept, help me workshop this thing. And what about that?" And if I want to say, "It's going to be this character class, what are maybe some ways I could develop it that are unusual?" and just sort of step by step kind of choose your own adventure. And it kind of walking me through the process has been really fun. STEPHANIE: Nice. Yeah, the way you're talking about it makes a lot of sense to me how asking it to help you, not necessarily do all of it, like, you know, kind of just spit out something that you're like, okay, like, that's what I'm going to use, approaching it as a tool, and yeah, that's really fun. Have you had good experiences then playing with those characters [chuckles]? JOËL: I have. I think it's also really great for sort of padding out some of the content. So, I had a character I played who was a washed-up politician. And at one point, I knew that I was going to have to make a campaign speech. And I asked ChatGPT, "Can you help me, like...here are the themes I want to hit. Give me a, like, classic, very politician-sounding speech that sounds inspiring but also says nothing at the same time." And it did a really good job of that. And you can tell it, "Oh, that's too long. That's too short. I want three sentences. I want five sentences." And that was great. So, I saved that, brought it to the table, and read out my campaign speech, and it was a hit. STEPHANIE: Amazing. That's really fun. I like that because, yeah, I don't think...I am so poor at just improvising things like that, even though, like, I want to really embody the character. So, that's cool that you found a way to help you be able to do that because that just feels like kind of what playing D&D can be about. JOËL: I've never DM'd, but I could imagine a situation where, because the DMs have to improv so much, and you know what the players do, I could imagine having a tool like that available behind the DM screen being really helpful. So, all of a sudden, someone's just like, "Oh, I went to a place," and, like, all of a sudden, you have to, like, sort of generate a village and, like, ten characters on the spot for people that you didn't expect, or an organization or something like that. I could imagine having a tool like that, especially if it's already primed with elements from your world that you'

Joël explains his note-taking system, which he uses to capture his beliefs and thoughts about software development. Stephanie recalls feedback from her recent RailsConf talk, where her confidence stemmed from deeply believing in her material despite limited rehearsal. This leads to a conversation about the value of mental models in building a comprehensive understanding of a topic, which can foster confidence and adaptability during presentations and discussions. The episode then shifts focus to the practical application of enumerators in Ruby, exploring various mental models to understand their functionality better. Joël introduces several metaphors, such as enumerators as cursors, lazy collections, and sequence generators, which help demystify their use cases. Episode on note-taking (https://bikeshed.thoughtbot.com/357) What we believe about software (https://bikeshed.thoughtbot.com/172) Ruby Enumerators (https://ruby-doc.org/3.3.1/Enumerator.html) Enumerator Lazy (https://ruby-doc.org/3.3.1/Enumerator/Lazy.html) Modeling a Paginated API as a lazy stream (https://thoughtbot.com/blog/modeling-a-paginated-api-as-a-lazy-stream) Solving a memory performance issue with enumerator (https://thoughtbot.com/blog/how-we-used-a-custom-enumerator-to-fix-a-production-problem) Find in batches (https://api.rubyonrails.org/classes/ActiveRecord/Batches.html#method-i-find_in_batches) Binary tree implementation with different traversals (https://gist.github.com/JoelQ/02f3ef9f61bebc7c8e5ea67d10ed92c6) Teaching Ruby to Count (https://www.youtube.com/watch?v=PHMOsTK1jSE) Transcript:  STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville, and together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: So, what's new in my world isn't exactly a new thing. I've talked about it on the podcast here before, and it's my note-taking system. I have a system where I try to capture notes that are things I believe about software or things I think are probably true about software. They're chunked up in really small pieces, such that every note is effectively one small thesis statement and a paragraph of text, and maybe a diagram or a code snippet to support that. And then, it's highly hyperlinked to other notes. So, I sort of build out some thoughts on software that way. A thing that I've done recently that's been pretty exciting with that is introducing a sort of separate set of notes that connect to my sort of opinion notes. So, I create individual notes for public works that I've done, things like blog posts or conference talks. Because a lot of those are built on top of ideas that have been sitting in my note system for a while. Readers and listeners get to sort of see the final product, but often sort of built up over several months or even a couple of years as I added different notes that kind of circled a topic and then eventually got to a thing. What I did, though, was actually making those connections explicit. And so I use Obsidian. Obsidian has this cool graph view where it just sort of shows all of the notes, and it circles them with, like, connections between them where the notes connect. So, I can now see in a visual format how my thoughts cluster in different topics, but then also which clusters have talks and blog posts hanging off of them and also which ones don't, which ones are like, oh, I have a lot of thoughts on this topic, and I've not yet written about it in a public forum; maybe that would be a thing to explore. So, seeing that visual got me really excited. I was having a good time. STEPHANIE: Yes, I have several thoughts coming to mind in response, which is, I know you love a visual. I really like the system of, even if you have created content for it, like, you have a space for, like, thoughts about it to evolve. Because you said, like, sometimes content comes out of notes that you've been...or, like, thoughts you've been having over years, but it's like, even afterwards, I'm sure there will still be new thoughts about it, too. I always have a hard time finding a place for that thing kind of once I, I don't know, it's like some of that stuff is never really considered done, right? So, that is really cool. And I also was just thinking about an old episode of The Bike Shed back when Chris Toomey and Steph Viccari hosted the podcast called "What We Believe About Software," I think, is the title. And I was just thinking about how, like, if only we could just dump all of your notes [laughs] into some, you know, stream [laughs], and that would be really cool. If we ever do, like, an episode like that, that would be really fun. And I'm sure, you know, you already have this, like, huge bank of ideas [laughs]. JOËL: Yes. It is really fun because I build up...the thoughts are often sort of interconnected, and so they might have a topic, but they are very focused. So, I might have, like, three or four things I believe about a particular topic that cluster together. So, we could...and, actually, I have used, in the past, some of those clusters as initial food for thought for a Bikeshed episode. STEPHANIE: Yeah, that's really neat. I like this idea of a kind of just, like, a repository for putting down what you believe about software as kind of, like, guiding principles for yourself as a developer a little bit. I remember a piece of feedback I got about my RailsConf talk that I gave a few weeks ago, and someone said like, "Oh, you sounded really confident in what you were talking about." And that surprised me because I, like, didn't practice rehearsing giving the talk all that much [laughs]. It's because they had asked like, "Oh, like, did you practice a lot?" or something like that. And I think I realized that I, like, really believed in what I was sharing and kind of that, I think, was perhaps what they were picking up on. And even though, like, maybe the rehearsal of the presentation itself was not where I had spent a lot of time on, I had spent a lot of time thinking about what I wanted to share and just building up my confidence around that. So, I thought that was an interesting connection. JOËL: Yeah, you fully developed the idea. You kind of explored all the side trails, maybe a little bit on your own as well. You're on very familiar terrain. And so, that is a way of building confidence separate from just sort of memorizing a talk. STEPHANIE: Yeah, yeah. Exactly. JOËL: In a sense, I almost feel like that's a better sense of confidence because then you can sort of...you can roll with the punches. You know, if a slide is out of order or something, sure, it maybe messes up a little bit of the narrative that you're trying to say. But you're not like, "Oh no, what is this content?" You're like, "Oh yeah, this thing," and you can dive right into it. Somebody asks you a question, and you're not like, "Oh no, that was not in the script," because, again, you've sort of mastered your topic. You know the area as a whole, even sort of the blurry edges beyond the talk, and can react in a way that is pretty confident. STEPHANIE: Yeah. I still definitely fear the open Q&A. I've never done it before, but maybe one day I will be able to because I just, you know, know my topic so well inside and out [laughs] that I can roll with the punches, as you say. JOËL: Open Q&A is just...it's a roll of the dice. Sometimes, you get some really good conversation topics there, and sometimes, it's just a waste of everyone's time. STEPHANIE: I like that take [laughs]. JOËL: Maybe that should go into the things I believe about software. So, other than receiving feedback about your RailsConf talk, what is new in your world? STEPHANIE: Yeah, so I am wrapping up a pretty large project on my client work that we're hoping to release soon. And, in fact, it's actually being released along with a big announcement from the client company to their customers. Essentially, at a conference, they're going to say like, "Hey, like, we now have this new feature." And so, I think there's some hype generated around it. And this past week, we've been doing a lot of internal testing of the feature because there are a lot of employees of my client company who are, like, pretty big users of the product, which is cool because I think we're getting, you know, we have easy access to people who can give us good feedback. But I am having a hard time with being on the receiving end of the feedback and figuring out, like, what is stuff I need to attend to now before, you know, this big release? And what is stuff that is just kind of, like, general feedback like, "Oh, like, I wish it did this," but, you know, it turns out that that's not really what we were building? And how do I just kind of, like, accept that? You know, it's coming from a good place, but I can't really help them there, at least right now. And that's hard for me because I like helping people, right? And so, if someone says something like, "Oh, like, I wish it did this," or like, "Oh, that's kind of weird," I'm like, "Oh, I want to just, like, fix that for you right now [laughs]." And I suspect that a lot of other devs can relate to this, especially if, like, you know, you've been working on something for a little bit, and it feels...I'm just going to say it: it feels a little precious to me. So, what I'm trying to do today, actually, is not look at any of the feedback at all [laughs] and come at it tomorrow with a bit of a calmer vibe and be able to separate out, like, you know, I think all feedback is informative, but not all of it is useful for you at any given moment. Like, if there are bugs, then those will be my immediate priority. If there's maybe some small tweaks that we can make the feature just a little bit more polished, then I also think those are good. But then we are discoverin