The Bikeshed Pod

By Matt Hamlin, Dillon Curry & Scott Kaye

The Bikeshed Pod is a weekly show where developers dive deep into the small but important details of software development that we all love to debate.... more

· Technology

Download on the App Store

Download on the App Store

Get it on Google Play

FAQs about The Bikeshed Pod:

How many episodes does The Bikeshed Pod have?

The podcast currently has 9 episodes available.

The Bikeshed Pod episodes:

June 16, 2025Are React Server Components Risky?!?
The gang interviews Matt on this episode, talking about all things React Server Components (RSCs), exploring their benefits, trade-offs, and adoption strategies. The hosts draw on their experiences at Wayfair, Fireworks, and Whoop to provide practical insights for learning and adopting RSCs.
Why React Server Components
Benefits:
Improved Time to First Byte (TTFB) via streaming.
More cohesive view of data dependencies (tighter front-end/back-end coupling).
Potential for smaller client-side bundles (automatic code splitting).
Trade-offs:
Requires a server layer (which might be a new concept for some React developers).
Migrating to React Server Components
Adoption Strategy:
Start page by page (easiest entry point).
Flip the mental model: Start from the server and work towards the client.
Need to consider the bundler support for RSCs.
Challenges:
You cannot easily swap out a small subsection of your page with an RSC.
Ensuring the bundler supports RSCs.
Key Considerations:
Think about two environments: server and client.
Understanding RSC Concepts
Two Environments: The importance of understanding server (server components, server actions) and client (client components) environments when using RSCs. Front-end engineers new to server-side development need to be aware of security implications and potential caching issues.
Frameworks: Highlighted the importance of understanding the core RSC principles separate from framework implementations like Next.js.
Not Necessarily Server Rendered: Clarifying that client components can be server-rendered, avoiding the assumption that client components are solely client-side rendered.
Resources: Blog post "React for Two Computers" by Dan Abramov is a great resource to learn about the mental model. Also start to look at the other framework implementations to understand that there's next features and there are RSC features
Standup Updates
Dillon: Using a Dexcom continuous glucose monitor to manage blood sugar levels and migraines.
Scott: Getting wedding suits, migrating from Datadog to Grafana monitors.
Matt: Working on lyaml translation migration. Experimenting with Parcel's RSC integration and Redwood SDK.
Links / References:
React for Two Computers by Dan Abramov
An excellent introduction to the concepts behind React Server Components
The Bookkeeping Pattern
A little look at how Scott and Matt leveraged Server Components and Server Functions at Fireworks
Waku RSC Todo App
Parcel RSC Todo App
RedwoodSDK RSC Todo App
...more
1h 17min
June 09, 2025Monorepo Madness
The Bikeshed podcast returns after a brief hiatus with hosts Scott Kaye, Matt Hamlin, and Dillon Curry. Tune in to hear the gang talk about keyboards, Scott's Italy trip, monorepos, and our hot takes on CSS!
Stand-up Updates
Dillon is dealing with disruptive construction at his house and is taking time off to combat burnout after a large launch at Woop. He has volunteered to be the guild lead of web, but is finding it difficult to motivate others and get things done.
Scott recaps his recent trip to Italy, highlighting Rome, Florence, Venice, Milan, and Lake Como. He is working on a project at his new job to rebuild GitHub. His project involves visually displaying changes when someone pushes to live. He's also rebuilt an open-source keyboard navigation project using useSyncExternalStore, adding new use cases like a command K search palette.
Matt is migrating translations in Webpack apps to a "postmodern" variant. He rebuilt his website using Waku and is debugging cold start issues on Cloudflare. He also got a new keyboard, the Nuphy Air V2 75, but a V3 model is coming out soon.
Monorepos Discussion
The main topic shifts to monorepos:
Definition: A monorepo is a single repository containing multiple projects, packages, or workspaces.
Popularity: Monorepos are popular at large companies like Google and Meta and are gaining traction in companies of various sizes.
Experiences: The hosts discuss their experiences with monorepos at Wayfair, HubSpot, and their current companies. They talk about the shift from monoliths to microservices and back to monorepos at Wayfair, the benefits of shared code, and the importance of culture and expectations.
Key Considerations:
Company size and number of contributors.
Deployment speed vs. stability.
Whether teams need to collaborate across problem spaces.
The existence of good documentation and onboarding processes.
The balance between consistency, speed, and safety.
Tooling: They mention tools like Lerna, Turborepo, and PMPM that support monorepo management.
Potential Downsides:
Monorepos can slow down development if not properly managed (e.g., long CI times).
Developers creating a dependency chain instead of simply reusing code.
Consistency is hard to maintain.
Monorepo vs. Technical Solution: Adopting a monorepo is often a technical solution to an organizational problem (e.g., aligning teams on coding standards).
The discussion shifts to how to deal with problems across the board, with more or less monorepos, more or less repos per projects, and things to consider when deciding what approach to use.
Team Structure and Code Ownership
The discussion pivots to team structure, code ownership, and velocity.
The hosts discuss the importance of discoverability of dependencies in monorepos.
Siloed Ownership in the monorepo can lead to faster development and is better for teams.
Speed in the form of high velocity, along with the proper North Star is critical for success.
Spicy Takes: CSS
The hosts share some spicy takes, primarily focused on CSS, tune in to the episode to hear them!
...more
1h 10min
May 20, 2025Ditch the Career Ladder
Summary
The Bikeshed Podcast introduces its hosts: Scott Kaye (UI guy, coffee curator, powerlifter) and Matt Hamlin (principal engineer, senior engineering lead) and Dillon (Spicy Take) Curry. They cover software engineering, tech events, and Discord emojis.
Keyboard Discussion
Dillon discusses his new Nuphy keyboard with silent red clear top switches, featuring RGB lighting. Matt reveals he recently ordered a Nuphy Air 75 v2 after being influenced by Dillon. This leads to a brief discussion about potentially dedicating an entire episode to keyboards.
Engineering Levels Discussion
Introduction: The main topic shifts to engineering levels and promotions. They discuss the convoluted process of getting promoted and the often vague nature of career ladders.
Promotions: Dillon suggests openly communicating promotion goals to managers early on and highlights finding a new job as another way to move up.
Level Alignment: They acknowledge that engineering levels are not uniform across companies. A "senior" at one company might be a "junior" or "staff" at another. More competitive companies may make it harder to get higher-level titles.
Fast Growth: They discuss the pros and cons of moving up the career ladder quickly and the importance of confidence and continuous learning. It’s also good to feel confident that you could interview and find a new job.
Company Growth: The podcast touches on companies growing quickly can provide opportunity for advancement in titles.
Lateral Growth: The hosts discuss the importance of lateral growth within a level to increase skillset. Seeking opportunities to grow and learn new things will make you more hireable in the future.
Company Needs: The hosts emphasize identifying and solving company-wide problems as a way to stand out and grow within an organization.
Leverage: Leverage is built through information and relationships. Leverage builds up over time in an organization and you begin to be able to better deliver results.
Building Connections
Networking: The hosts discuss the importance of building a strong network across the company. Dillon recommends setting up one-on-ones with team members to understand their roles better.
Be Nice: Genuine excitement about connections lead to great relationships.
Authenticity: It's important to create genuine friendships at work and enjoy the time spent with colleagues.
Teach: Teach people selflessly.
Conclusion
The hosts wrap up the discussion, emphasizing that levels matter differently to different people and depending on what their professional goals are. It's important to pursue constant growth and balance career aspirations with personal satisfaction.
Stand-up Updates
Scott discusses his laid-back onboarding experience at Airbnb and his excitement about the new role.
Dillon shares his success with morning workouts after adjusting his sleep schedule.
Matt discusses his on-site event, tinkering with Obsidian and TinyBase, and his anticipation for his new keyboard.
...more
45min
April 11, 2025Scratching the Surface on Design Systems
Summary:
This episode of The Bikeshed Podcast covers design systems, including their benefits, trade-offs, and whether your company needs one. The hosts also share experiences from their time working on a design system team at Wayfair. Segments include stand-up updates, "Two Takes and a Fake," and "Spicy Takes with Curry."
Stand-up Updates
Dillon: Shifted to a new project requiring more help. He is listening to the audiobook "Sapiens."
Matt: Exploring the Cloudflare Vite plugin, which allows building a worker and a client-side app. Also experimenting with TinyBase, a sync engine for web applications.
Scott: Took time off before starting a new job. He completed home improvement projects such as re-grouting tiles and fixing a couch leg. Updated the Bikeshed Podcast logo and metadata. Started working on an incremental Bun compiler and playing around with a Moon monorepo.
Design Systems Discussion
Benefits: Design systems are helpful, especially in larger corporations, as they standardize UI, increase speed, create brand consistency, and ease rebranding. They establish a UI contract between designers, engineers, and product teams.
Considerations: Smaller companies might benefit more from solutions like Shadcn, where components are consumed into the application. The team should also be responsible for contributing back. Design systems should be flexible and adapt to user needs. It is important to take an empathetic approach to use cases.
Wayfair Experience: The team discusses their experience working on a design system at Wayfair, highlighting the importance of a single source of truth for design. They also discussed the value of patterns and collaborative environment for creativity and continuous improvement. The team started rigid and inflexible, but matured to provide more flexibility for the teams they were supporting.
Component Libraries vs. Design Systems: A component library is one piece of a design system. Component libraries are more of a starting point, less rigid, and more flexible, whereas design systems are more opinionated and include non-tangible elements like guidelines and documentation.
Organization Size: Organization size impacts the design system. Large companies benefit from large investments in platform tooling. Design systems require dedicated people to think about them and the best way to set them up.
Selling the Value: It is often hard to quantify and sell the value of what the team is doing. Tools that show adoption can help leaders see the value of a design system.
Spicy Takes
Tune in to hear the takes that Dillon and Matt share to make Scott react like Mr Krabs:
Two Takes and a Fake
The hosts play a game where they identify the fake tech-related news among two real ones. This week's topics were Bun, Vercel changelog, and Next.js.
Tune in to hear who wins this week!
...more
55min
April 02, 2025Testing - Is It Worth It?!?
Summary:
This episode of the Bikeshed Podcast features a discussion about software testing, with a focus on automated testing in frontend development. The hosts, Scott Kaye, Matt Hamlin, and Dillon Curry, explore various testing methodologies, tools, and their value in different contexts. They delve into the nuances of unit, integration, and end-to-end testing, and the trade-offs involved in choosing one over the other. The discussion also touches on the role of mocking, dependency injection, and the importance of balancing test coverage with development speed. They each share personal experiences from their development career on testing, and their favorite tools.
Key Discussion Points:
Value of Testing: Testing is often not enjoyable in the short term, but provides significant long-term value by preventing bugs and providing confidence in code changes.
Unit Testing vs. Integration/End-to-End: Unit testing is valuable for specific functions, while integration and end-to-end tests are better for critical user flows. However, end-to-end tests can be flaky.
Mocking: The overuse of mocking can reduce the value of tests. Dependency injection is viewed more favorably than mocking, though they serve similar purposes.
Test Coverage: Aiming for 100% test coverage may not be efficient; focus on testing essential product features. Consider the time and effort spent on tests versus the value they provide.
Testing in Production: The hosts explore the concept of testing in production, with tools like Datadog synthetics. This allows the team to assess the experience for end-users in production.
The "midwit" meme reference that Matt made during the episode
Test-Driven Development (TDD): TDD may not always be practical, especially when developing new features with unknown outputs. Writing tests after the feature is more common in these scenarios.
Proof of Concept (POC): Developing a proof of concept outside the main application to validate an idea before integrating it is valuable.
Accessibility Testing: The importance of accessibility testing is discussed, but integrating it into the development process is important.
Component Tests: A discussion of testing in isolation to ensure true browser experience. Component testing will ensure the system will run in the browser as expected.
Code and Test Half-Life: Tests lose value over time as codebase patterns change. It's important to re-evaluate their relevance.
Referenced blog post on the half-life of code and tests
Spicy Takes:
Tune in to the episode to hear all our spicy takes on testing!
Misc. References:
Scott shared a few Neovim related projects that he has been working with:
Folke Snacks.nvim
Folke Lazy.nvim
Folke Flash.nvim
Avante.nvim
...more
1h 9min
March 31, 2025Perfecting The Pull Request
Summary:
This episode of the Bikeshed Podcast features Scott Kaye, Matt Hamlin, and Dillon Curry discussing best practices for code review, with a focus on creating effective pull requests (PRs) and how to approach reviewing code.
Creating Great Pull Requests
Context is Key: Highlight the problem being solved, the goal of the PR, and the solution chosen. Explain why this solution was selected over alternatives.
Scope: PRs should be isolated to a single problem or feature.
Rollback: Consider and outline the rollback procedure for changes.
Templates: Minimal templates with "context" and "details" sections are generally preferred. "Alternatives Considered" can be a useful addition.
Self-Review: Conduct a self-review of the code, ideally within the GitHub PR interface, to identify potential issues.
Draft Mode: Utilizing draft PRs is helpful for iterative development and early feedback.
Visual Aids: Include screenshots, screen recordings, and preview deploys to contextualize changes, especially for UI-related PRs. Dev tool screenshots can be helpful.
How to capture full-size screenshots within Chrome Devtools
Matt's replacement for Dropbox Capture
Tests: Defer writing tests until a solid solution and some initial feedback have been received to avoid wasted effort due to significant code changes.
Reviewing Code Effectively
Understand the Big Picture: Start by understanding the problem being solved and the overall goal of the PR.
Use Available Context: Utilize videos, screenshots, and preview deploys to understand the changes.
Prioritize: Focus on major changes and save minor issues for a second pass.
"What, Why, How" Approach: Consider what the change does, why it's being made, and how it's implemented.
Live Reviews/Pairing: For complex changes, consider live reviews or pair programming to accelerate feedback and build shared understanding. However, acknowledge that this is not always feasible due to time constraints.
Knowledge Sharing: Use code reviews as an opportunity to onboard team members and share knowledge.
Spicy Takes (and Not-So-Spicy Takes)
Code review maybe is not needed: It was suggested in certain situations, code review may not be necessary. This take was received as extremely situational.
You should almost never have to do two code reviews This take was received as neither mild or spicy, more so cold and lukewarm.
What's Up With You? (Stand-up Updates)
Dillon: Was looking into something called embargoed assets in Contentful.
Scott: Learned about animating on scroll videos and pictures in React using the Canvas tag, bypassing React's re-rendering limitations.
Matt: Investigating Content Security Policy (CSP) and durable objects on Cloudflare.
...more
53min
March 26, 2025A Day In The Life: Coding, Coffee, and Commit Messages
Summary:
In this episode of the Bikeshed Podcast, the gang dives into their daily routine exploring their productivity habits and workflows. They also get down and dirty on discussing their spicy takes.
Daily Routines for Productivity
Matt: Starts his day with a morning walk and uses Obsidian as a central hub for notes and task management. He reviews notes and Slack to identify action items. He also notes that he finds opportunities to make improvements on other things while doing a given task and acts on it instead of simply noting it.
Scott: Begins with coffee, checks personal and work emails and Slack, reviews his calendar, and focuses with his headphones and vibes with music.. He uses Obsidian, Notion, or Notes to track tasks and goals, breaking down complex tasks into smaller, manageable parts. He also prioritizes clear communication and task articulation to minimize disruptions.
Dillon: Prefers working from the office for increased productivity. He maps out his day with a "stand-up update" and clears his email and Slack to minimize distractions and enable focused work periods.
Follow-up on Daily Routines
Matt and Scott both use end-of-day summaries to set the stage for the next day.
Dillon prefers the office to WFH and does not perform an end-of-day summary and stated it's something he could work on.
Matt uses an "outcomes" section in his daily notes to track accomplishments and artifacts, aiding in reviews and progress tracking over time.
Spicy Takes
Dillon (Medium): React components often abuse props, violating the single responsibility principle due to a lack of care or education.
Scott (Hot): Design systems should empathetically conform to user needs and not try to influence design in a specific direction. A bolder take was that design systems shouldn't exist at all.
Matt (Hot Fire): We should not always assume good intent when reviewing code or understanding legacy systems. Sometimes, it's necessary to challenge decisions and consider alternative paths.
Two Takes and a Fake
The hosts played a round of "Two Takes and a Fake," a game where they presented three tech-related statements (two real, one fake) and challenged each other to identify the fabrication. Who will win? Tune in and find out!
What's New
Scott: Been working with UI heavy work to animate webm video files on scroll. Check out the homepage of Tollbit
Matt: Released Vndr, a CLI tool for vendoring (inlining) packages.
...more
39min
March 19, 2025Is The Web Getting Worse?!?!?
Summary:
This episode of the Bikeshed Podcast explores the concept of "enshittification," the idea that the quality of products and services deteriorates over time, often accompanied by increased monetization and decreased customer value. They further discuss how this relates to web development and the broader tech industry. They explore potential cultural factors behind this.
Key Discussion Points:
Enshittification Examples: The hosts provide examples of enshittification in popular services like Spotify (increased ads with subscription) and Netflix (higher prices for premium features). Facebook is also mentioned as a product that has seemingly declined in popularity as it has aged.
AI Integration: The hosts discussed the trend of tacking on AI to products just to say that they offer AI features, which can often be annoying and not serve the original purpose of the product.
Lost Focus on User Needs: They discuss how companies sometimes lose sight of their original mission and focus more on monetization through KPIs rather than solving customer needs. The hosts share that as measures become metrics, they become less valuable over time.
"Nobody Cares" Blog Post: They discuss the Grant Slatton blog post, interpreting it as a reflection of how engineers may be disempowered from caring about the overall product due to narrow focus and lack of agency in larger organizations.
“Shadification of the Web”: They introduce the term "shadification" to describe the growing trend of websites looking the same due to the widespread use of component libraries like Shadcn/ui (copy-paste) along with Material UI and Bootstrap.
Optimization vs. Innovation: They discuss how companies often prioritize optimization and A/B testing over true innovation, resulting in a lack of creativity and unique user experiences.
Performance Costs: Optimizations made at the expense of performance degrade the customer experience.
Blurred Ownership: In larger companies, it becomes harder to draw ownership lines when there are more people owning things and there isn't clear defined guidelines.
Impact of AI on UI Creativity: The hosts explore the potential for AI to further standardize UI patterns and stifle creativity, as AI models are trained on existing designs and may not generate truly novel solutions.
AI Dependency: Discussion of companies choosing to support new libraries based on the amount of support AI models know about them and recommend them, which can lead to everything becoming the same.
Personal Updates:
Scott has been digging into Avante, finding it helpful for learning Go. He plans to build a backend service in Node and then refactor it to Go as a learning exercise.
Matt has been experimenting with Cursor's Composer agent feature and a tool called Codename Goose, which uses AI to infer functionality on his computer.
...more
1h 5min
March 17, 2025Vibe Coding When The Vibes Are Off
Dillon, Matt & Scott record an episode with some semblance of quality.
The gang dove directly into software's hottest topic: AI. We believe in using AI in your day to day job to be more successful.
In this episode we discuss;
use cases for AI in software development,
the fun tasks AI has taken away and,
how to be successful using AI tools.
Listen to us explain navigating writing code in a world where more and more companies are increasingly advocating the usage of AI at your day job.
How do we continue to learn and grow as human while still maintaining fun, creativity and human interaction as an engineer in 2025?
AI is a powerful tool used correctly, however that AI will submit to confirmation bias and your role is to prompt AI to be as unbiased as possible to the best of your ability.
Episode Summary:
In this episode of The Bikeshed Podcast, hosts Scott Kaye, Matt Hamlin, and Dillon Curry discuss the role of AI in software development, sharing their experiences with various AI-powered tools and debating the impact of AI on engineering workflows, learning, and job satisfaction.
Key Topics Discussed:
AI in Software Development
The hosts discuss how AI has become integral to software engineering, particularly for writing code and automating tasks.
Matt introduces the main discussion: how AI is used in development today and the broader implications of its adoption.
Preferred AI Tools
Dillon shares that he used Cursor until his company restricted it, forcing him to switch to Copilot, which he finds inferior.
Scott uses NeoVim with NeoCodium and Avante, but acknowledges their limitations compared to Cursor.
Matt relies on Cursor at work, noting that his company prefers it over other AI tools.
AI's Impact on Development
AI enables developers to work faster but can remove the learning process.
Over-reliance on AI can lead to shallow understanding of code and a decrease in creativity.
AI often acts like a junior engineer whose code must be reviewed, making debugging a larger part of the job.
Using AI can lead to less collaboration with teammates, as developers tend to consult AI over their colleagues.
Concerns About AI in Software Engineering
Some engineers feel less engaged with their work as AI handles boilerplate and repetitive tasks.
AI's agreeable nature can reinforce incorrect assumptions, leading to confirmation bias.
Companies may use AI to increase efficiency and reduce hiring, raising concerns about job displacement.
AI vs. Traditional Search (Google)
Unlike Google, where users must craft precise search queries, AI allows more fluid back-and-forth conversations.
AI can provide immediate answers but might not always offer the best or most optimized solution.
The “No AI” Challenge
The hosts agree to a two-and-a-half-day challenge of coding without AI, to evaluate how it affects their work and problem-solving abilities.
Game Segment – “Two Takes and a Fake”
Scott introduces a new segment where Matt and Dillon guess which of three AI-related tweets is fake.
Matt wins this round, showing a keen eye for spotting AI discourse trends.
What's New?
Dillon is learning piano and music theory to slow down and disconnect from work.
Matt is exploring Cloudflare workers and running Deepseek R1 locally for AI experimentation.
Scott is focused on improving his Golang skills and debating Cherry Pepsi Zero vs. Cherry Coke Zero.
Closing Thoughts
The hosts discuss burnout, learning in tech, and how side projects keep programming fun.
They tease next week's episode on burnout and side projects.
The episode wraps up with some lighthearted banter and a call for listeners to like, subscribe, and share.
...more
1h

FAQs about The Bikeshed Pod:

How many episodes does The Bikeshed Pod have?

The podcast currently has 9 episodes available.